[lwip-devel] [patch #9384] Partial SACK (RFC 2018) support

[Jakub Schmidtke]

Follow-up Comment #5, patch #9384 (project lwip):

The problem with SACKs in data packets is that the size of the TCP header is
calculated when the data segment is created.
By the time it's actually sent out, the number of SACKs to include may change.
It may even be different the next time the same packet gets re-transmitted...
With empty ACKs there is no such problem...

About the alignment and MACs... could you please elaborate? What's the
difference between allocating space for SACKs in advance,
versus changing it later (assuming SACK options would be padded to 4 bytes
boundary)?
Is there a difference between reserving some payload bytes at the beginning
(as it's done for regular options right now),
and changing the header size (the "transport" layer passed to pbuf
allocation)?

The other idea I had, was to always allocate TCP segments as two pbufs - one
for the header, and one for the data
(just like it's done when the "copy data" flag is not passed to tcp_write).
When sending, I could actually create a brand new
pbuf for TCP header and required number of SACKs, copy the original over, and
concat it with the data payload...

I will add the LWIP_ prefix to the define's name.
The idea was to add full support, hence the current name.
Maybe I could use the other name, and rename it once there is full support?


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?9384>

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