Subject: SV: Anomalous TCP behaviour?

From: [email-masked]
Date: Tue, 25 Jan 2000 10:26:03 +0100

Hi,

What TCP implementation are you testing? I have encountered a similar 
problem with FreeBSD (after messing it up by disabling slow start).
What happened was that the Ethernet driver dropped packets, this
because we used rather large windows. When dupacks arrived
and TCP tried to retransmit the lost packet the driver queue was still
full and the new packet was also dropped.

I dont know if this could be your problem as well, a bit more
information of how and what you are testing would help.

/Jonas Haggård Ljungquist

> ----------
> Från: 	Anupama Sundaresan[SMTP:[email-masked]]
> Skickat: 	 den 25 januari 2000 04:08
> Till: 	[email-masked]
> Angående: 	Anomalous TCP behaviour? 
> 
> Hello,
> 
> 	Is it normal for TCP to skip a certain number of bytes and send
> them later when it receives dup acks?
> 
> The following tcpdump o/p illustrates that TCP sends packets in sequence
> upto a certain point but suddenly skips a certain number of bytes and
> after receiving 5 duplicate acks transmits not 'retransmits' the missing
> bytes...
> 
> # comments inline.
> 
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1:1449(1448)
> ack
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 1449:2897(1448)
> ack
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 1449
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 5793:7241(1448)
> ack
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 7241:8689(1448)
> ack
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 8689:10137(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 10137:11585(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 11585:13033(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 2897:4345(1448)
> ack
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002: 4345:5793(1448)
> ack
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 2897
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 4345
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 13033
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 13033:14481(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 14481:15929(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 15929:17377(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 17377:18825(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 15929
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 18825
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 18825:20273(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 20273:21721(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 21721:23169(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 21721
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 23169
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 23169:24617(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 24617:26065(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 26065
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 26065:27513(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 27513:28961(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> 
> ## till now it was Txing it in sequence but now after 28961 it
> goes off to 30409 so it starts getting dup acks...
> 
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 30409:31857(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 31857:33305(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 33305:34753(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 34753:36201(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 36201:37649(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 28961
> 
> ## again after 5 dupacks (if u leave out the original ack) it transmits
> NOT
> retransmits that block between 28961 and 30409. This happens many times...
> Is this normal TCP behaviour?
> 
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 28961:30409(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 37649
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 40545:41993(1448)
> 
> ## Also it is obvious from the tcpdump o/p that the Fast retransmit
> mechanism doesnt get kicked off after 3 dup acks - is this normal
> behaviour?
> 
> Here, the segment from 53577 to 55025 is not transmitted so we start
> getting dup acks for 53577
> 
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 52129:53577(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 46337:47785(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 55025:56473(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 56473:57921(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 57921:59369(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 1
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 2
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 3
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 4
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 59369:60817(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 60817:62265(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 62265:63713(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 63713:65161(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 5
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 6
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 7
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 8
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 65161:66609(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 66609:68057(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 68057:69505(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 9
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 10
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 11
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 70953:72401(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 72401:73849(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 73849:75297(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 12
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 13
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 14
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 69505:70953(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 75297:76745(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 76745:78193(1448)
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 78193:79641(1448)
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 15
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 16
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 17
> testbed4.ittc.ukans.edu.5002 testbed5.ittc.ukans.edu.1178: ack 53577 - 18
> testbed5.ittc.ukans.edu.1178 testbed4.ittc.ukans.edu.5002:
> 53577:55025(1448)
> 
> Around 18 dup acks are received before that segment is transmitted. again
> this is a case of out of order packets
> 
> 
> tcptrace o/p for the same tcpdump o/p
>    a->b:                              b->a:
>      total packets:         22457           total packets:          7601
> 
>      ack pkts sent:         22456           ack pkts sent:          7601
> 
>      pure acks sent:            1           pure acks sent:         7599
> 
>      unique bytes sent:  30000000           unique bytes sent:         0
> 
>      actual data pkts:      22455           actual data pkts:          0
> 
>      actual data bytes:  30000000           actual data bytes:         0
> 
>      rexmt data pkts:           0           rexmt data pkts:           0
> 
>      rexmt data bytes:          0           rexmt data bytes:          0
> 
>      outoforder pkts:           9           outoforder pkts:           0
> 
>      pushed data pkts:      15067           pushed data pkts:          0
> 
> 
> Infact the outoforder packets is pretty large in some cases. 
> Is this normal?
> 
> Thanks,
> -anu.
> 
> 
> 
> 
>

---

From: Anupama Sundaresan <[email-masked]>
Date: Tue, 25 Jan 2000 11:09:52 -0600 (CST)

Hi,

	The tcpdump o/p which I sent was taken at the transmitter. I'm
testing a linux 2.2.13 implemetation. I want to observe the behaviour of
TCP under normal conditions bcoz I too want to test the behaviour of
TCP after disabling congestion control. 

> full and the new packet was also dropped.

## So, is that the reason why the receiver is sending so many Dup acks and
in the tcpdump o/p we cant see the transmitter making any effort to
transmit the missing segment?

Thanks,
-Anu.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 26 Jan 2000 14:03:42 -0500

It's possible that you're seeing measurement error.. the packet
capture subsystem may have limited buffering and may miss some output
packets if there's a burst.

Also, depending on exactly how the transport layer, ip layer, and
driver are glued together, a sufficiently large burst of packets might
get dropped in the driver if the output queue gets too large..

					- Bill