Subject: [tcpinc] Feedback on EDO?

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 11 Mar 2015 13:46:36 +0000

Hi,

TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding feature gaps or deployment problems.

In a previous discussion, TCPINC was identified as one potential user of EDO [2]. I understand that the TCPINC design is still at a early stage. Still, if there are thoughts on EDO in the TCPINC community, please feel free to share them on the TCPM list, or please talk us in the next TCPM meeting.

Thanks

Michael (TCPM co-chair)

[1] https://datatracker.ietf.org/meeting/92/agenda/tcpm/

[2] http://www.ietf.org/mail-archive/web/tcpinc/current/msg00429.html

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 22 Mar 2015 13:17:17 +0100

Michael,

>
> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming
> meeting [1]. At this stage, TCPM is really interested in feedback from
> implementers and potential users, e.g., regarding feature gaps or
> deployment problems.
>
> In a previous discussion, TCPINC was identified as one potential user of
> EDO [2]. I understand that the TCPINC design is still at a early stage.
> Still, if there are thoughts on EDO in the TCPINC community, please feel
> free to share them on the TCPM list, or please talk us in the next TCPM
> meeting.
>
>

Based on the experience in extending TCP in the mptcp working group,  I
would be really useful to collect measurements about how deployed
middleboxes interact with the EDO option as it is currently defined. The
working group should encourage such studies to understand the possible
limitations of EDO.

Olivier

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 23 Mar 2015 13:28:18 -0500

> TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the upcoming meeting [1]. At this stage, TCPM is really interested in feedback from implementers and potential users, e.g., regarding f…

Which (experimental)  TCP feature requires EDO? Does tcpcrypt require EDO?

Same question applies to proposals extending option space in SYN.

> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Mar 2015 11:51:35 -0700

> Same question applies to proposals extending option space in SYN.

The answer to both questions in the motivation section of the drafts.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 23 Mar 2015 12:46:29 -0700

On Mon, Mar 23, 2015 at 11:28 AM, Yuchung Cheng <[email-masked]> wrote:

> > TCPM has scheduled a discussion of draft-ietf-tcpm-tcp-edo in the
> upcoming meeting [1]. At this stage, TCPM is really interested in feedback
> from implementers and potential users, e.g., regarding feature gaps or
> deployment problems.
>

Well, SACK? But, I guess common cases will be a combination of extensions,
not a specific one.
--
Yoshi

> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 23 Mar 2015 15:45:23 -0500

> The answer to both questions in the motivation section of the drafts.
Where?

"""
1. Introduction

   TCP's Data Offset is a 4-bit field, which indicates the number of
   32-bit words of the entire TCP header [RFC793]. This limits the
   current total header size to 60 bytes, of which the basic header
   occupies 20, leaving 40 bytes for options. These 40 bytes are
   increasingly becoming a limitation to the development of advanced
   capabilities, such as when SACK [RFC2018][RFC6675] is combined with
   either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open
   [Ch14].

   This document specifies the TCP Extended Data Offset (EDO) option,
   and is independent of (and thus compatible with) IPv4 and IPv6. EDO
   extends the space available for TCP options, except for the initial
   SYN and SYN/ACK. This document also explains why the option space of
   the initial SYN segments cannot be extended as individual segments
   without severe impact on TCP's initial handshake and the SYN/ACK
   limitation that results from middlebox misbehavior.
"""
I also don't see how SACK+ Fast Open demands EDO. An example helps.

It's not clear to me that EDO is "required" or "nice-to-have" to use
SACK+mptcp+AO. Please clarify.

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Mar 2015 15:19:01 -0700

>> The answer to both questions in the motivation section of the drafts.

EDO:

Section 6:
   Some combinations of the above options may not fit in the existing
   SYN option space, and (as noted) that space cannot be extended.

---

EDO-SYN:

1. Introduction

   This extension is required to support
   some combinations of TCP options, notably large ones such as TCP AO
   [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with
   other options already typically used in most TCP connections.

---

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Mar 2015 15:22:59 -0700

On 3/23/2015 12:46 PM, Yoshifumi Nishida wrote:
> 
> On Mon, Mar 23, 2015 at 11:28 AM, Yuchung Cheng <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi,
>     >
> 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 ;-)

However, there are no options that *depend* on EDO yet because EDO
hasn't been available that long.

TCPCRYPT might be revised to used EDO (and EDO-SYN, or some other SYN
approach) too. Then again, that would require making it work on TCP
rather than on the reliable data stream delivered, but then could also
be extended to allow protection against header-based tampering.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 23 Mar 2015 18:39:03 -0400

> 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.

In my opinion, this alone could be worthy motivation, without
even trying to enumerate all the experimental or combinations
of options that might (or might not) find EDO useful.

-- 
Wes Eddy
MTI Systems

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 24 Mar 2015 15:47:14 -0500

> showed it was useful to be able to carry a larger number of
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.
    Here is another data point, in addition to the iperf data
presented today: (L|G)RO and (G|T)SO are critical for Google Linux
servers.

2. Salvage operation when middleboxes strip EDO randomly in the middle
of connection

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Mar 2015 13:53:02 -0700

> probably fix the SW-offload but pessimistic about changes in

All new options are incompatible with offload that doesn't properly
handle options it doesn't understand.

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

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).

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 24 Mar 2015 22:06:24 +0100

Joe,

> 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.

> decoupled from the header, defeating the purpose of most options (which

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