lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jakub Schmidtke
Subject: [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support
Date: Tue, 27 Jun 2017 14:11:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

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

Reserving space for SACKs simplifies memory management a lot. However, it
means that each data packet that does not have SACKs wastes up 36 bytes (max 4
SACKs take 8 bytes, plus 2 bytes for option header, plus 2 bytes of padding to
ensure proper alignment). Is it OK to do that?

To not violate MSS while adding SACKs to full packets would mean not sending
all of that packet's payload.
It feels like a nightmare from segment management perspective.

Another solution would be to send SACKs only in empty ACK packets (just like
this patch does right now).
I feel like this violates the RFC: "If the data receiver generates SACK
options under any circumstance,
it SHOULD generate them under all permitted circumstances."

Yet another solution would be to always limit the payload size (as if SACKs
were included in each packet),
but only add them if necessary (so packets without SACKs would be slightly
smaller, but without empty NOPs/zero padding).
This would also require moving the TCP header, but would not violate the MSS.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]