Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt

From: Joe Touch <[email-masked]>
Date: Tue, 22 Apr 2014 07:49:52 -0700

Hi, all,

Wes and I wrote the following to try to put to rest the issue of 
extending TCP's option space. Although the primary reason was to 
summarize why the SYN space cannot be extended, it is written as 
Standards-Track because it includes an extension for non-SYN segments 
that could still be useful when SACK, TS, and authentication or 
encryption options are used together.

We are seeking this as a TCPM WG doc. Feedback appreciated.

Joe and Wes

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt
Date: Fri, 18 Apr 2014 13:30:46 -0700
From: [email-masked]
To: Wesley M. Eddy <[email-masked]>,        Dr. Joseph D. Touch 
<[email-masked]>, Joe Touch <[email-masked]>,        Wesley Eddy 
<[email-masked]>

A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tcpm-tcp-edo
Revision:	00
Title:		TCP Extended Data Offset Option
Document date:	2014-04-18
Group:		Individual Submission
Pages:		9
URL: 
http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/
Htmlized:       http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00

Abstract:
    TCP segments include a Data Offset field to indicate space for TCP
    options, but the size of the field can limit the space available for
    complex options that have evolved. This document specifies an
    optional extension to that space and explains why such extensions
    (including this) cannot be used in the initial SYN.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 23 Apr 2014 01:23:10 -0700

Hi Joe, Wes,

Thanks for the draft. Yes, extending TCP's options space is an important
topic for tcp and has been discussed for long time. It would be great if we
can find once-and-for-all solution for it.
I think the draft seems to address the problems identified through the
previous approach, however, I still have concern on it.

One difficulty for extending options space is that middleboxes might
re-segments packets or discard options. In case of other options like
timestamp, SACK, this might not be a fatal issue. However, in case of this,
the result will be catastrophic.
So, I'm thinking that this approach might need some mechanisms that can
check whether the segument is re-segmented or not. This could be done
internally or externally by combining other features (AO or tcpcrypt, etc).
Please let me know if you have opinions on this or if I miss something.

Thanks,
--
Yoshi

On Tue, Apr 22, 2014 at 7:49 AM, Joe Touch <[email-masked]> wrote:

> Hi, all,
>
> Wes and I wrote the following to try to put to rest the issue of extending
> TCP's option space. Although the primary reason was to summarize why the
> SYN space cannot be extended, it is written as Standards-Track because it
> includes an extension for non-SYN segments that could still be useful when
> SACK, TS, and authentication or encryption options are used together.
>
> To: Wesley M. Eddy <[email-masked]>,        Dr. Joseph D. Touch <
> [email-masked]>, Joe Touch <[email-masked]>,        Wesley Eddy <
> [email-masked]>
>
>
> URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 23 Apr 2014 13:07:26 +0000

Hi Joe, Wes,

thanks for summing up these important points in one draft.

Some minor (some pedantic) points:

Sec 4, 3rd para: "the six reserved TCP header bits"...

After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits left. [AccECN would reuse these same three bits, hopefully]

Same para: legacy endpoints are not required to drop packets, just ignore these bits, or am I mistaken? At least the ignore 

Further, during SYN (unless this is a SYN,URG packet), there are in fact two fields (Acknowledgment Number, Urgent Pointer) that are unused; however, these fields are not useable on the SYN,ACK, or when the URG flag is set (but that use is discouraged). [AccECN would make opportunistic use of the probably available URG Pointer field, to improve resiliency]

Section 5:

The text seems to imply that EDO overrides DataOffset, thus EDO should take precedence when processing. (This is mentioned in sec 6.3)

However, I would like more specific text on that interaction, and what should be done with DataOffset.

Is DataOffset to be set to some currently invalid value (i.e. 0..4)? Or always to the maximum (15)? Or to a bounded maximum: min(15, ceil(edo/4))

(It seem to be implied in sec 6.3, that the bounded maximum variant is to be used...)

Section 6.2: The most prevalent option, MSS, has been omitted from that list. (also, MSS is often inserted early in the list of options, by intermediate devices independent of the end hosts).

Section 7: Stateful inspecting firewalls seem to be missing here; if that DPI box doesn't understand EDO, it would reassemble the stream incorrectly for inspection. That could lead to an bypass of that fence, or the failure of a stream in mid-session.

Section 8 seems to have 3 partial sentences...

Best regards,

Richard Scheffenegger

##################################################################
# To any security service agents reading my email:               #
# Please consider if any professional body code of conduct to    #
# which you subscribe requires you to follow Snowden's example.  # 
# Your professional membership, chartered or incorporated status #
# may be at risk.                                                #
##################################################################

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Dienstag, 22. April 2014 16:50
> To: [email-masked]
> Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-
> edo-00.txt
> 
> Hi, all,
> 
> A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt has been
> successfully submitted by Joe Touch and posted to the IETF repository.
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Apr 2014 10:13:22 -0400

> previous approach, however, I still have concern on it.

   I strongly support this work.

> timestamp, SACK, this might not be a fatal issue. However, in case of
> this, the result will be catastrophic.

   We will have to discuss middlebox damage; but I believe it can be
detected: thus I suggest we adopt the document, warts and all, rather
than try to fix middlebox damage before adopting it.

> So, I'm thinking that this approach might need some mechanisms that
> can check whether the segument is re-segmented or not. This could be
> done internally or externally by combining other features (AO or
> tcpcrypt, etc).

   I _really_ don't want to go into "combining other features" at this
point...

> Please let me know if you have opinions on this or if I miss something.

   I have some concerns of my own; but I see no reason to raise them
before WG adoption.

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 08:13:49 -0700

On 4/23/2014 1:23 AM, Yoshifumi Nishida wrote:
> topic for tcp and has been discussed for long time. It would be great if
> we can find once-and-for-all solution for it.

Discarding options is always dangerous. There's no good way to detect 
this other than to require that, once enabled, the option MUST appear in 
all subsequent segments. But that alone doesn't ensure it's been 
followed - resegmentation could still copy the visible options and move 
the data around, and you wouldn't know.

> Please let me know if you have opinions on this or if I miss something.

You can surely detect whether a middlebox has done something that might 
impact this option by using any sort of integrity protection. That's 
useful to mention, but I don't think it's either necessary or useful to 
*require* it.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 08:47:48 -0700

> After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits left. [AccECN would reuse these same three bits, hopefully]

Thanks - I will fix that.

> Same para: legacy endpoints are not required to drop packets, just ignore these bits, or am I mistaken? At least the ignore

RFC793 is very specific:

   Reserved:  6 bits

     Reserved for future use.  Must be zero.

It doesn't say "must be set to zero until defined, and must be ignored 
at the receiver until defined".

A compliant receiver should check these bits and drop if not zero.

If community consensus is that this is not how the text should be 
interpreted, then that needs to be fixed in an errata (it hasn't), and 
corrected in the 793 update.

(yes, this is in conflict with the redefinition of those bits).

It's easy to note that using those bits to extend the option space isn't 
particularly useful, because there's not enough bits left to make a dent 
(the 4 bits might save a total of 8 bytes for 'flag' options, but can't 
add more space). I will correct that discussion in our draft.

> Further, during SYN (unless this is a SYN,URG packet), there are in
> fact two fields (Acknowledgment Number, Urgent Pointer) that are unused;
> however, these fields are not useable on the SYN,ACK, or when the URG
> flag is set (but that use is discouraged). [AccECN would make
> opportunistic use of the probably available URG Pointer field, to
> improve resiliency]

Other controls or processing in the SYN are supposed to be queued for 
processing after the connection is established.

We can't use URG unless the URG bit is cleared; even though its use is 
discouraged, it's still possible, which means that field isn't available.

You're right about the ACK field; the ACK bit cannot be set, so that 
field would be available. I'll update the text accordingly.

> Section 5:
>
> The text seems to imply that EDO overrides DataOffset, thus EDO
> should take precedence when processing. (This is mentioned in sec
> 6.3)

It does only when present in a segment. To find the option, you need to 
look at the existing Data Offset to process the options first - only 
when you see EDO can you look further. That's why, in Section 8:

    >> When the EDO length option is present, the EDO length option
    SHOULD be the last non-null option covered by the TCP Data Offset,
    because it would be.

> However, I would like more specific text on that interaction, and what should be done with DataOffset.

It would be useful to put that text earlier, in Sec 5.

> Is DataOffset to be set to some currently invalid value (i.e. 0..4)?
> Or always to the maximum (15)? Or to a bounded maximum: min(15, ceil(edo/4))
>

Again, this would be useful to describe in total in Sec 5, but the 
summary of the rule is the one above in Sec 8 and the following in Sec 5:

    >> Because it overrides an existing TCP header field when present,
    the EDO length option MUST occur within the length of the TCP Data
    Offset. The EDO length option SHOULD occur as early as possible,
    either first or just after any authentication or encryption.

I.e., if there's no authentication/encryption, DO would be 6 (to 
accommodate the EDO option itself).

If there is auth/enc, DO would be (A-E wordlength + 6). It's worth going 
through those cases to explain.

Again, as noted, the idea is that DO works like it does now, just that 
*once you reach the EDO option* it overrides DO. DO isn't overridden on 
every segment.

> Section 6.2: The most prevalent option, MSS, has been omitted from
> that list. (also, MSS is often inserted early in the list of options, by
> intermediate devices independent of the end hosts).

It's worth adding.

Devices that insert MSS wouldn't be a problem (except in violating the 
basic E2E principle in general); in fact, using EDO ensures there's 
space for that addition.

> Section 7: Stateful inspecting firewalls seem to be missing here; if
> that DPI box doesn't understand EDO, it would reassemble the stream
> incorrectly for inspection. That could lead to an bypass of that fence,
> or the failure of a stream in mid-session.

Good point, and worth adding.

The only way to support these sort of devices would have been to put the 
additional options *after* the TCP data, rather than before - i.e., 
where the IP length would disagree with the TCP length.

That seems like it opens more cans of worms, though, in terms of 
undetectable interactions (the options wouldn't be covered by the 
checksum, etc.)

> Section 8 seems to have 3 partial sentences...

Yeah, not enough coffee during that draft. I'll fix that.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 23 Apr 2014 17:58:13 +0000

Hi Joe,

> > After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits
> > left. [AccECN would reuse these same three bits, hopefully]
> 
> > Same para: legacy endpoints are not required to drop packets, just
> > ignore these bits, or am I mistaken? At least the ignore
> 
> RFC793 is very specific:
> 
>    Reserved:  6 bits
> 
> It doesn't say "must be set to zero until defined, and must be ignored at
> the receiver until defined".
>

Well, 793 states (2.10): be conservative in what you do, be liberal 
in what you accept from others.

Factually, most TCP stacks have interpreted this pre-2119 "must" 
equivalent to an RFC2119 "SHOULD".

But lets leave out that tangent; I just wanted to point out that some
Additional bits have been defined, and

> add more space). I will correct that discussion in our draft.

That is absolutely the case!

> (yes, this is in conflict with the redefinition of those bits).

I just submitted an errata; Wes, when you continue on 793bis and do the 
2119 wording overhaul, you probably want to check these instances where
there is a "must" in 793, that is probably more a SHOULD nowadays. 

(Acknowledgment Number and Urgent Pointer do lack a "SHOULD be zero" too).

> Again, this would be useful to describe in total in Sec 5, but the summary
> of the rule is the one above in Sec 8 and the following in Sec 5:
> 

This wording would allow a variant like this:

Data Offset = 6; 24 < EDO (#1) <= 60 < EDO (#2) <= MSS

#1 - discouraged, but valid
#2 - EDO adds value

If one chooses to implement EDO with small (DataOffset would suffice)
option spaces for some reason, it appears more sane to have both EDO and DataOffset
indicate the same length, or DataOffset set to its maximum...

If these two disagree (EDO < DataOffset || (DataOffset < 15 && DataOffset < EDO))
It should be regarded as a peculiar / or even invalid combination...

> *once you reach the EDO option* it overrides DO. DO isn't overridden on

Understand; just the corner cases should be defined (IMHO, having EDO when you actually need the space, makes sense, thus DO should be at maximum, when EDO is present; if DO is between 5 and 15, having EDO indicating a similar size (excluding NOP / EOL perhaps, thus EDO <= DO) would be valid, but I'm not sure if DO=6, EDO=60 is a sensible combination...

> additional options *after* the TCP data, rather than before - i.e., where
> the IP length would disagree with the TCP length.
> 

Well, on a pure SYN, you could logically append the ACK Number at the end of the option space; that would yield a net increase of 2 bytes to the SYN option space, when EDO=enable is present. But I doubt that it would be worthwhile to special-case the SYN here - or would we gain something by going from 40 to 42 bytes option space in a SYN?

Besides, having data past the IP length would probably (and rightfully so) get truncated with most routers. I wouldn't want to see us go there...

Best regards,
  Richard

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 25 Apr 2014 15:00:35 +0000

Hi Joe, Wes,

thank you for this work. I also strongly support this work/doc.

Some comments

* Sec 1:
   - Please add a reference to RFC 793.
   - Please add one or two examples of common option combinations where we have a problem, e.g. TCP TS, SACK, and Multipath TCP

* Sec 2:
   - „A SYN may include user data …“ Please add a reference to RFC 793/TFO

* Sec 4:
   - Should we mention „draft-paasch-mptcp-control-stream“ here?
   - „The six reserved … to be ignored“ —> maybe we can required this in RFC793bis ;-)
   - While it may be not possible to extend the option in a SYN, it’s possible to reduce the space needed, e.g.
     late negotiation. Maybe we can add some text here. 

* Sec 5:
   - „For initial SYN segments (i.e., those whose ACK bit is not set)“. IMO a SYN is a segment where the SYN bit is set.
   - The explanation of the EDO option is in a different order than the figures. Please explain first figure 1 and
     then 2 (or swap the figures)
   - „An endpoint confirming EDO support MAY… in its SYN-ACK“ —> So, a receiver can extend its options space directly
     in his first segment. Right?
   - „Because it overrides an existing TCP header field when present“ -> I don’t get this. You override the data field, no?
     (After reading Sec. 6.3, I have the feeling that I understand what you mean here…)
   - Last para. Add ref to TCP-AO

* Sec 6.3
   - „Once detected, the TCP EDO length option… for all subsequent option processing OF THIS SEGMENT“. Please make it clear
     that subsequent segments may not have the EDO length option and the Data Offset field becomes valid again.
   - BTW I’m not sure if the word override is the best one in this context. Is „invalid“ not more appropriate?

General comment at this point:
   - Should we not require that the Data Offset field must be zero if TCP EDO length option is present, because it has
     no meaning in that case
   - As more I think about TCP EDO updates RFC793…

Alex

Am 22.04.2014 um 16:49 schrieb Joe Touch <[email-masked]>:

> Hi, all,
> 
> Wes and I wrote the following to try to put to rest the issue of extending TCP's option space. Although the primary reason was to summarize why the SYN space cannot be extended, it is written as Standards-Track because it includes an extension for non-SYN segments that could still be useful when SACK, TS, and authentication or encryption options are used together.
> 
> To: Wesley M. Eddy <[email-masked]>,        Dr. Joseph D. Touch <[email-masked]>, Joe Touch <[email-masked]>,        Wesley Eddy <[email-masked]>
> 
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Apr 2014 08:21:41 -0700

Hi, Alex,

Thanks for the feedback. Additional questions below...

Joe

>     - Please add one or two examples of common option combinations where we have a problem, e.g. TCP TS, SACK, and Multipath TCP

Will do.

>     - „A SYN may include user data …“ Please add a reference to RFC 793/TFO

Will do.

>     - Should we mention „draft-paasch-mptcp-control-stream“ here?

I don't think so, any more than mentioning FTP's control channel. In 
both cases, a separate data channel is used for control info. The MPTCP 
approach isn't applicable to individual TCP connections - it only works 
in MPTCP because the group of connections is co-associated.

>     - „The six reserved … to be ignored“ —> maybe we can required this in RFC793bis ;-)

It's certainly something we should address in 793bis.

>       late negotiation. Maybe we can add some text here.

Compression should be discussed (e.g., taking flag options and 
representing them as bits in a single option), but they're very uncommon 
(except that EDO in the SYN would be an example).

It might also be possible to combine options so that a single 
type/length can replace repeated ones, but that saves very little space 
overall because SYN space is consumed by a relatively small number of 
large options.

Late negotiation should be discussed, but in the context that initiating 
new capabilities after the TWHS isn't viable.

>     - „For initial SYN segments (i.e., those whose ACK bit is not set)“. IMO a SYN is a segment where the SYN bit is set.

We're both right. I was clear in explaining that "initial SYN" is SYN 
and no ACK, which is a connection initiator. SYN-ACK is a response to an 
initial SYN.

Given I explained what an initial SYN is, I don't see the issue. Can you 
clarify your concern?

>       then 2 (or swap the figures)

Sure/

>       in his first segment. Right?

Yes; I'll make it more clear that the "initial SYN" is the one that 
can't be extended, and that responses to that can.

>       (After reading Sec. 6.3, I have the feeling that I understand what you mean here…)

Others pointed that ambiguity out, and I'll both clarify, integrate in 
one place, and give an example there.

>     - Last para. Add ref to TCP-AO

OK.

>       that subsequent segments may not have the EDO length option and the Data Offset field becomes valid again.

Will do as part of the clarification and example noted above.

>     - BTW I’m not sure if the word override is the best one in this context. Is „invalid“ not more appropriate?

I'll check that throughout. The DO continues to have partial meaning in 
this method - i.e., it never really becomes useless (implied by 
invalid), it's just that once you see EDO (which you need to interpret 
DO correctly to do), EDO overrides DO for the interpretation of the rest 
of the options and data of that segment. That's why I used "override". 
Again, I'll check that, but I'm open to suggestions too.

>     - Should we not require that the Data Offset field must be zero if TCP EDO length option is present, because it has

Right - that's why this method never does that (see above regarding 
"overrides").

>     - As more I think about TCP EDO updates RFC793…

Strictly, every TCP option ought to do that IMO. However, because it's 
optional rather than mandatory, it's not clear - I've seen optional 
extensions treated both ways ("updates" and not-updates). I don't really 
care, but I agree that this issue should be determined as we move forward.

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Fri, 25 Apr 2014 15:47:12 +0000

Hi Joe,

that was quick :-)

Inline.

Am 25.04.2014 um 17:21 schrieb Joe Touch <[email-masked]>:

> I don't think so, any more than mentioning FTP's control channel. In both cases, a separate data channel is used for control info. The MPTCP approach isn't applicable to individual TCP connections - it only works in MPTCP because the group of connections is co-associated.
> 
> Compression should be discussed (e.g., taking flag options and representing them as bits in a single option), but they're very uncommon (except that EDO in the SYN would be an example).
> 
> It might also be possible to combine options so that a single type/length can replace repeated ones, but that saves very little space overall because SYN space is consumed by a relatively small number of large options.
> 
> Late negotiation should be discussed, but in the context that initiating new capabilities after the TWHS isn't viable.
> 
>> * Sec 5:
> We're both right. I was clear in explaining that "initial SYN" is SYN and no ACK, which is a connection initiator. SYN-ACK is a response to an initial SYN.
> 
> Given I explained what an initial SYN is,

and exactly this is what I miss and which confused me :-)

What do you think about the following text:

 „For initial SYN segments (i.e., the first SYN during the 3-way handshake)

> I don't see the issue. Can you clarify your concern?
> 
> Yes; I'll make it more clear that the "initial SYN" is the one that can't be extended, and that responses to that can.
> 
> Others pointed that ambiguity out, and I'll both clarify, integrate in one place, and give an example there.
> 
> I'll check that throughout. The DO continues to have partial meaning in this method - i.e., it never really becomes useless (implied by invalid), it's just that once you see EDO (which you need to interpret DO correctly to do), EDO overrides DO for the interpretation of the rest of the options and data of that segment. That's why I used "override". Again, I’ll check that, but I'm open to suggestions too.

With this explanation it becomes clearer. Before I didn’t realize that we still need to interpret DO
if EDO is present. Now, after I got your point and I think „invalid“ is not the right word and „override“
is exactly what we do. I think if we extend the processing section w/ some explanation why we still need
the DO it becomes clear.

> Right - that's why this method never does that (see above regarding "overrides").
> 
> Strictly, every TCP option ought to do that IMO.

Yes, but w/ TCP EDO we reorganize the header in that sense that we have later on options in
the data field. So we change the meaning of bits of a TCP segment. 

> However, because it's optional rather than mandatory, it's not clear - I've seen optional extensions treated both ways ("updates" and not-updates). I don't really care, but I agree that this issue should be determined as we move forward.
> 
>> Alex
>> 
>>

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Apr 2014 09:25:32 -0700

Hi, Alex,

Cutting to the open issues; I think these can be fixed in the 01 version 
easily but may be harder to confirm in email, so I'll take a shot at the 
revision ASAP.

Joe

> Inline.
...
>   „For initial SYN segments (i.e., the first SYN during the 3-way handshake)

A SYN-only can also be part of a simultaneous open; I might say:

	For initial SYN segments (SYN but not SYN-ACK, i.e., the first
	SYN in a three-way handshake or simultaneous open)

...
> is exactly what we do. I think if we extend the processing section w/ some explanation why we still need

AOK - let's leave that one for the clarification revision, and let me 
know if the result works in v01 or not...

...
> the data field. So we change the meaning of bits of a TCP segment.

Again, I've seen it handled both ways. I don't mind how we decide to do 
it, or how the ADs recommend, but I figure we don't need to decide that 
between the two of us. Either way, whatever is decided, I'm glad to 
adjust the text/doc header.

---

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 25 Apr 2014 12:53:30 -0400

> It's certainly something we should address in 793bis.

I just added it to the back of the 793bis TODO list.

At some point, I hope to get 793bis adopted as a WG document too :).

-- 
Wes Eddy
MTI Systems

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 26 Apr 2014 02:46:48 -0700

Hi Joe,

On Wed, Apr 23, 2014 at 8:13 AM, Joe Touch <[email-masked]> wrote:

> Discarding options is always dangerous. There's no good way to detect this
> other than to require that, once enabled, the option MUST appear in all
> subsequent segments. But that alone doesn't ensure it's been followed -
> resegmentation could still copy the visible options and move the data
> around, and you wouldn't know.
>
>
> impact this option by using any sort of integrity protection. That's useful
> to mention, but I don't think it's either necessary or useful to *require*
> it.

I am wondering how you want people to use this.
You are saying that this is going to be a PS, which I guess it means people
can use this in the wild anytime they want.
I know we don't have to have experimental v.s. PS discussion now, but i'm
just curious how to use this.

Thanks,
--
Yoshi

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 26 Apr 2014 10:53:17 +0000

On 2014-4-23, at 17:13, Joe Touch <[email-masked]> wrote:
> Discarding options is always dangerous. There's no good way to detect this other than to require that, once enabled, the option MUST appear in all subsequent segments.

The two ends could agree to only include the option in a subset of the segments sent (every nth, or some random sequence). If options get dropped, you would find out eventually. But not immediately, as with sending them in all options.

(Yes, I feel pedantic this morning.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Apr 2014 17:42:09 -0700

Hi, Youshifumi,

...
> You are saying that this is going to be a PS, which I guess it means
> people can use this in the wild anytime they want.
> I know we don't have to have experimental v.s. PS discussion now, but
> i'm just curious how to use this.

presented it as standards-track only because it is intended to update 
TCP; if this is considered risky, then we can consider a different track.

My view is that it isn't any more or less risky than most other new TCP 
options, though.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Apr 2014 17:50:13 -0700

On 4/26/2014 3:53 AM, Eggert, Lars wrote:
>> Discarding options is always dangerous. There's no good way to
>> detectthis other than to require that, once enabled, the option MUST appear in
>> all subsequent segments.
>
> The two ends could agree to only include the option in a subset of
> the segments sent (every nth, or some random sequence). If options
> get dropped, you would find out eventually. But not immediately, as
> with sending them in all options.

Anything that drops EDO in segments would drop the initial SYN segment, 
and the connection would never start. If the path changes during a 
connection and a device on the new path drops EDO segments, then TCP 
would be stuck at some point anyway. If you send EDO in every Nth 
segment, then you just delay that response and make it more difficult 
for the endpoints to know why the connection failed.

However, I don't think it's useful to design default protocol behavior 
solely to test for Internet bugs like this.

IMO, we can leave it where it is - as "use when needed". But we can hash 
out details like this in the WG as consensus, too. I don't care all that 
much.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 28 Apr 2014 22:17:36 -0700

Hi Joe,

On Mon, Apr 28, 2014 at 5:42 PM, Joe Touch <[email-masked]> wrote:

> presented it as standards-track only because it is intended to update TCP;
> if this is considered risky, then we can consider a different track.
>

OK. make sense to me.

> My view is that it isn't any more or less risky than most other new TCP

My view may be a bit different, but I might be wrong and I think we can
discuss later, not now.

Thanks,
--
Yoshi