[lwip-devel] [bug #28106] duplicate acknowledge for fast retransmit could have not null length

[Oleg Tyshev]

Follow-up Comment #2, bug #28106 (project lwip):

It is bad, that current implementation  of lwip is not compatible with old
one :(

Kieran, I don't understand how fast retransmit works if dup ACK should have 0
length.

suppose host A send packets:
seqno 1 ack 100
seqno 2 ack 101
seqno 3 ack 102 - X this packet lost
seqno 4 ack 103
seqno 5 ack 104

host B send packets
seqno 105 ack 1 len 1
seqno 106 ack 2 len 1
seqno 107 ack 3 len 1
seqno 108 ack 3 len 0 (send dup ack)
seqno 108 ack 3 len 1 (send own data)
seqno 109 ack 3 len 0
seqno 109 ack 3 len 1
seqno 110 ack 3 len 0
seqno 110 ack 3 len 1

Host A receives (ack 3 len 0) - variable dupack incremented
(ack 3 len 1) - dupack reseted
(ack 3 len 0) - dupack incremented
(ack 3 len 1) - dupack reseted
and so on

Without length testing it seems to work.

Stevens in TCP/IP Illustrated use 4.4BSD-Lite sources.
It is interesting what say about duplicate ACKs standard
and how it is implemented e.g. in Linux?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/