Joe,
Well, SACK? But, I guess common cases will be a combination of
extensions, not a specific one.
SACK can use as much space as it is given, AFAICT ;-)
That's right, and there have been multiple studies that even
showed it was useful to be able to carry a larger number of
SACK blocks.
Please share the studies.
After today's meeting, my concerns are
1. EDO's incompatibility with HW/SW offload. I am positive we can
probably fix the SW-offload but pessimistic about changes in
HW-offload.
All new options are incompatible with offload that doesn't properly
handle options it doesn't understand.
I'd like to point out that the Multipath TCP design shows that it is
possible to design TCP options that are unknown by the existing offload
hardware and still remain compatible with them.
In the case of GRO, the software SHOULD handle EDO without error, even
if it cannot achieve a performance improvement. The current behavior is
clearly incorrect.
2. Salvage operation when middleboxes strip EDO randomly in the middle
of connection
There is no solution to that either, except to develop a mechanism
inside the data plane of TCP. At that point, the option would be
decoupled from the header, defeating the purpose of most options (which
are segment-specific).
In Multipath TCP, this salvage operation exists thanks to the DSS
checksum which is included in the DSS option. EDO does not include this
kind of feature and would be vulnerable to strange middlebox.
Multipath TCP has been shown to work well through various types of
middleboxes, both thanks to lab measurements and through real use, see
https://tools.ietf.org/html/draft-ietf-mptcp-experience-01
for additional information and references.
Recently, an MPTCP user complained that MPTCP was started with two
subflows over a satellite link and quickly switched to a single subflow.
A closer analysis revealed that this behavior was caused by a very
strange middlebox that interferes with options, see
http://blog.multipath-tcp.org/blog/html/2015/01/30/multipath_tcp_through_a_strange_middlebox.html
Preserving the end-to-end connectivity, even in the presence of
middleboxes must be an objective for a TCP extension like EDO.
Otherwise, it won't be useable
Olivier
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
