[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/
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/21
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/21
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Joel Cunningham, 2017/06/26
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/26
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/27
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/27
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/27
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support,
Jakub Schmidtke <=
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Joel Cunningham, 2017/06/27
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/27
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Joel Cunningham, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Simon Goldschmidt, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Jakub Schmidtke, 2017/06/28
- [lwip-devel] [patch #9384] Partial SACK (RFC 2018) support, Joel Cunningham, 2017/06/28