Hi Thiadmer,
Just a few remarks about your initial post.
Firstly:
The overlapping data part. I would be really
interested in the details of the system on the
transmitter side, which seems to not repacketise the
data. This can seriously reduce bandwidth, and as i
said before, goes completely against what you'd expect
a full-fledged TCP stack to do.
But then again I might have an inkling of why this is
happening. There is this thing called TCP Fast
Retransmit, which is designed to speed up the transfer
and is effective in doing so when the receviers window
size is large. Say pkt 1,2,.....10 having sequence
numbers s1,s2....s10 were sent, but pkt 2 got dropped.
Now, what the receiver does is that for all packets
that fall inside the window but are out of order, it
sends an ACK with ( Last_in_order received pkt +
pktLen ). If pkt 1 contained 100 bytes payload , then
on rcving pkts 3,4,5...10, eight ACK s would be sent
from the rcvr side with Ack number (s1+100). At the
sender side, the sender maintains a count of the
number of duplicate ACKs received. If this count
crosses a certain threshold (typically 3),then the
sender retransmits only that pkt...in this case pkt 2.
So now the rcvr that has buffered up the pkt
1,3,4,5...10 can acknowledge that entire block with
the sender having to retransmit just pkt 2.
Now, perhaps while implementing this, the duplicate
ACK count for pkt 'i' might be incremented if the ACK
falls withing the range of sequence number 'si +
length_of_pkt2'. Because it is fast retransmit, it
does not bother to repacketise the data, just sending
all of the earlier prepared packet when the threshold
is crossed.
In your case, since you are sending "several ACKs" for
10,000 you could be crossing the fast retransmit
threshold, causing the packet to be retransmitted 'as
is', unless the new window size advertised by you in
the ack pkts is lesser than the length of the pkt that
is being sent. This can 'force' the sender to
repacketise the data.
There is one way to make certain if this is the case :
send ONLY ONE ACK when you receive overlapped
data...this will definitely NOT cause the fast
retransmit to trigger, and the normal timeout
mechanism and go-back-N procedure should kick in at
the sender, which should include the repacketisation
of data. Could you do this and let me know, if it is
not too much of a hassle....
Secondly :
The out-of-order packets part.
The sender will send data from X if you ACK with X,
and the simplest form of doing this is go-back-n.
Without this, as Dr. T- pointed out, TCP would no
longer be able to work in face of drops on the line.
And I also agree with you about the hub......
I was building a mini-stack on a network processor
with gigabit ports. I used a hub ( 10 Mbps ) to get a
packet trace. I was simulating a number of clients,
and trying to establish a TCP connection. The way I
had coded it, I should have seen 'n' SYN , 'n' SYN-ACK
and then 'n' ACKs. But, when I sniffed through the
hub, this was not the case. All the packets were
inter-mingled. Also, the the LED signifying collision
was ON for almost all the time. This being the case,
the CSMA/CD protocol that uses a random-backoff time
(which increases exponentially, i.e. doubles each time
that frame collides ) could be the explanation of the
out-of-order situation. This could also be happening
with your hub, { you using Ethernet at L2, right? },
and thus in the logs the pkt with the bigger seq. num
is perhaps seen before the right seq num; even though
they were transmitted in the right order.
Apologies for the length of the post.
Furthur comments/observations will be appreciated.
Dhruva.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
