On Sun, Dec 04, 2005 at 09:17:47PM +1100, Darren Reed wrote:
> Having looked at some packet dumps from Nick, the "OOW" problem seems
> to be caused by TCP SACK.
>
> e.g.
>
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330003176:330004636(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330003176:330004636(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330004636:330006096(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330006096:330007556(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330009016:330010476(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330010476:330011936(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330011936:330013396(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330013396:330014856(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330013396:330014856(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330009016} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330010476} > (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330014856:330016316(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330011936} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330013396} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330013396} > (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330017776:330019236(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330019236:330020696(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330014856} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330016316} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330017776} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330019236} > (DF)
> 1.1.1.1.2601 > 1.1.1.2.netbios-ssn: . ack 330004636 win 17520 <nop,nop,sack
> sack 1 {330006096:330020696} > (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330020696:330022156(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330004636:330006096(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
> OOW:
> 1.1.1.2.netbios-ssn > 1.1.1.1.2601: . 330004636:330006096(1460) ack
> 3945818187 win 62880 NBT Packet (DF)
That is strange. SACK is more a specification of excatly what part is missing
between the
ACK field and the last received sgement. It does not interfere with the generic
ACK mechanism.
A host not implementing SACK would therefor just retransmit everything from
330004636 (being the
last ACKed octet).
-Guido
