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

[Jakub Schmidtke]

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

The comment is wrong. It's because I originally kept SACKs as an u32[8] array
(with mixed left,right,left,right,...) edges,
but it was cleaner to hold an array of structs with 'left' and 'right' fields.
I will fix the comment.

I will fix the spacing.

I don't think reducing TCP_MAX_SACK_NUM based on LWIP_TCP_TIMESTAMPS define
makes sense.
Even if it is defined, we may not negotiate it use (if the other side doesn't
support or want it),
in which case the timestamps will not be included.

On the other hand, keeping more SACKs (even more than 4) may be useful.
We only include up to 4 SACKs in packets, but additional SACK entries provide
more context.
If we have 4 individual SACK ranges, and incoming data packet fills a gap
between two of them, we will have 3 SACKs.
If the size of the array is 4, we will only include up to 3 SACKs.

Now if that array had 5 entries (or more) that were valid SACKs, filling one
gap would leave us with 4 SACKs that could be included.
This is because we don't calculate them dynamically, but rather when new data
packets are received.

We could also recalculate SACKs whenever we remove some, but this would not
preserve the "more recent first" order of SACK entries.



    _______________________________________________________

Reply to this item at:

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

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