Re: congestion control, Netware 5.1 <-> IRIX 6.5

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 10/18/04 

Date: 18 Oct 2004 18:59:58 GMT

In article <yqc7jpoupi9.fsf@zonule.cl.cam.ac.uk>,
Keith Wansbrough <kw217@cl.cam.ac.uk> wrote:
:But I can't see why it would be repeatedly
:waiting for the timer, rather than ACKing every second segment as it
:should (assuming the segments are all full segments - it's allowed to
:wait longer for partial segments).

I am slightly fuzzy on the terminology. Is a 'segment' what you
get after reassembly of all fragments carried in individual packets?
If so, then in my situation, each packet carries a 1460 byte segment;
each has DF set.

Here are two iterations of the cycle. fin192 is Novell, wachsmann
is SGI IRIX.

# ... 3 packets from novell
13:40:07.101860 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 705181:706641(1460) ack 0 win 15392 (DF) (ttl 128, id 32647, len 1500)
13:40:07.101871 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 706641:708101(1460) ack 0 win 15392 (DF) (ttl 128, id 32903, len 1500)
13:40:07.101878 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 708101:709561(1460) ack 0 win 15392 (DF) (ttl 128, id 33159, len 1500)
# ... ~200 ms timeout before ACK
13:40:07.301342 wachsmann.ibd.nrc.ca.8024 > fin192.ibd.nrc.ca.1020: . [bad tcp cksum 92cc!] 0:0(0) ack 709561 win 48870 (DF) (ttl 60, id 10935, len 40)

# ... 3 more packets from Novell right after it gets the ACK
13:40:07.302419 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 709561:711021(1460) ack 0 win 15392 (DF) (ttl 128, id 34951, len 1500)
13:40:07.302429 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 711021:712481(1460) ack 0 win 15392 (DF) (ttl 128, id 35207, len 1500)
13:40:07.302435 fin192.ibd.nrc.ca.1020 > wachsmann.ibd.nrc.ca.8024: . [tcp sum ok] 712481:713941(1460) ack 0 win 15392 (DF) (ttl 128, id 35463, len 1500)
#... another ~200 ms timeout before ACK
13:40:07.502166 wachsmann.ibd.nrc.ca.8024 > fin192.ibd.nrc.ca.1020: . [bad tcp cksum 81b0!] 0:0(0) ack 713941 win 48870 (DF) (ttl 60, id 10936, len 40)

Looking at some live output, it appears to me that sometimes the Novell
network is sending 4 packets instead of 3; those instances usually
match up with a lower timeout on the delayed ACK. If the behaviour
is not -quite- as rigid as I described, that might explain why the
observed throughput, 23-24 KB/s, is higher than the throughput one would
predict from 200 ms timeouts (~21 Kb/s).

NB: I am not sure why the tcpdump 'bad tcp checksum' are occuring. It might
be an artifact of how packets get recorded [I was recording on
wachsmann itself.] tcpdump reports the same thing for nearly all tcp
packets going out of that IRIX system. I know that checking the tcp
checksum is a 'MUST', so if it were a real checksum problem rather than
an artifact, then the IRIX system would be essentially unable to
communicate with any conforming TCP host, but no such problems are
occuring. 

-- 
   "I want to make sure [a user] can't get through ... an online
   experience without hitting a Microsoft ad"
   -- Steve Ballmer [Microsoft Chief Executive]

Relevant Pages

  • Re: TCP SACK issue, hung connection, tcpdump included
    ... because the segment which never gets correctly ACKed is also the ... SACK block is DSACK information telling explicitly the address ... if this ACK doesn't reach the ... SERVER TCP, RTO is triggered and the first not yet cumulatively ACKed ...
    (Linux-Kernel)
  • Re: Sockets
    ... If you look at how TCP works, you discover that having your remote ... you send a full, hence complete segment. ... small data elements into a single segment to keep performance ... The oponent - once it will get your segment will send an ACK back to ...
    (microsoft.public.pocketpc.developer)
  • Re: congestion control, Netware 5.1 <-> IRIX 6.5
    ... >:waiting for the timer, rather than ACKing every second segment as it ... Is a 'segment' what you ... > get after reassembly of all fragments carried in individual packets? ... > is SGI IRIX. ...
    (comp.sys.sgi.misc)
  • Re: TCP SACK issue, hung connection, tcpdump included
    ... because the segment which never gets correctly ACKed is also the ... it seems that one of the directions is dropping packets for some reason ... At the end of the dump here the connection is dropped by the client side. ... nor the retransmissions of 2991:3039 from the CLIENT. ...
    (Linux-Kernel)
  • Re: some ipfw filter does not function under Release 6.3
    ... Are you saying that the packets shown below from 221.192.199.36 arrived ... Is the tcpdump shown running on the same box as ipfw, ... ack 1 win 65535 ... But the rule 330 should only allow established TCP pass through. ...
    (freebsd-questions)