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

[Oleg Tyshev]

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

Ok,

Data should be sent from unsent queue
  1. if nagle not prevent sending by send()
  2. together with acknowledge after tcp_ack_now()
  3. together with delayed acknowledge from tcp_fasttmr()

It looks like we have error in 2.:
  unsent queue has very little data,
  tcp_do_output_nagle() prevent sending data and pure acknowledge, exception
is only fast retransmit.
Pcb has TF_ACK_NOW flag but nothing is sent.

Good review of delayed acks is here:
http://kb.pert.geant.net/PERTKB/TCPAcks
---
RFC 831 first suggested a delayed acknowledgement (Delayed ACK) strategy,
where a receiver doesn't always immediately acknowledge segments as it
receives them. This recommendation was carried forth and specified in more
detail in RFC 1122 and RFC 5681 (formerly known as RFC 2581). RFC 5681
mandates that an acknowledgement be sent for at least every other full-size
segment, and that no more than 500ms expire before any segment is
acknowledged.

The resulting behavior is that, for longer transfers, acknowledgements are
only sent for every two segments received ("ack every other"). This is in
order to reduce the amount of reverse flow traffic (and in particular the
number of small packets). For transactional (request/response) traffic, the
delayed acknowledgement strategy often makes it possible to "piggy-back"
acknowledgements on response data segments.
--

In our implementaion ack sent not for each full-size segment but for each 2nd
segment (see tcp_ack()).



Now flags TF_ACK_NOW and TF_ACK_DELAY are cleared in tcp_send_empty_ack().

tcp_fasttmr() checks TF_ACK_DELAY and data won't be sent.





    _______________________________________________________

Reply to this item at:

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

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