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

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2014 17:01:27 -0700

Hi, all,

This is an updated version of the Extended Data Offset option.

The changes are, broadly:

	- more clear about the immediate potential need for
	non-SYN DO extension

	- more clear about the issue with SYN extension
	points off to a currently pending doc with the
	SYN approach Briscoe and I discussed on the list

	- includes a discussion of the issues with
	specific prior approaches

	- reorganized to get to the actual extension
	earlier

The core proposal hasn't changed.

I'd like to suggest this version be the topic of discussion for 
inclusion as a WG doc, intended for (preferably) PS or at least 
Experimental.

The SYN DO extension is intended to be considered separately, and would 
be focused at Experimental (whether in the WG or individual).

I won't be in Toronto, but will provide a slideset summarizing the 
changes as well.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcpm-tcp-edo-03.txt
Date: Wed, 02 Jul 2014 16:10:48 -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-03.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tcpm-tcp-edo
Revision:	03
Title:		TCP Extended Data Offset Option
Document date:	2014-07-02
Group:		Individual Submission
Pages:		16
URL: 
http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/
Htmlized:       http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03

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 updates RFC 793
    with an optional TCP extension to that space to support the use of
    multiple large options such as SACK with either TCP Multipath or TCP
    AO. It also explains why the initial SYN of a connection cannot be
    extending as a single segment.

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: Bob Briscoe <[email-masked]>
Date: Thu, 3 Jul 2014 15:55:21 +0100

Joe,

Thanks for updating this. EDO is a useful separation of the problem 
space into easy and hard, which I fully support.

Comments from a rapid scan:

Section 5.4
The roster of possible TCP options probably ought to include TFO.
I notice TFO was also overlooked during the timstamp options thread 
in late May / early Jun.

Section 7.7
"  Legacy endpoints are required
    to drop TCP segments where those bits are not zero, making it
    difficult to assume backward downgrade.
"
Please don't say this. The spec [793] doesn't say anything about 
drop, so please quote the spec precisely, and don't attempt to interpret it.

This is your interpretation of an ambiguous sentence written a long 
time ago, when the recognised understanding of terms could have been 
different. It is dangerous to translate it using context that has 
become common more recently. It would be unfortunate if it were 
considered as law by other developers.

Nits
S4. s/byte rder/byte order/

Bob

At 01:01 03/07/2014, Joe Touch wrote:
>inclusion as a WG doc, intended for (preferably) PS or at least Experimental.
>
>The SYN DO extension is intended to be considered separately, and 
>would be focused at Experimental (whether in the WG or individual).
>
>URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-03.txt
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 08:58:00 -0700

Hi, Bob,

On 7/3/2014 7:55 AM, Bob Briscoe wrote:
> I notice TFO was also overlooked during the timstamp options thread in
> late May / early Jun.

Sure.

> Please don't say this. The spec [793] doesn't say anything about drop,
> so please quote the spec precisely, and don't attempt to interpret it.
>
> This is your interpretation of an ambiguous sentence written a long time
> ago, when the recognised understanding of terms could have been
> different. It is dangerous to translate it using context that has become
> common more recently. It would be unfortunate if it were considered as
> law by other developers.

I'll wait to see what the WG thinks about this too. 793 says these bits 
"Must be zero." - it could easily have said "must be ignored", but it 
doesn't, so I continue to disagree it's ambiguous, but it's certainly 
useful to raise this as a consensus issue.

> S4. s/byte rder/byte order/

Thanks.

I don't think it's worth issuing a quick update based only on these 
points; I'd like to get more WG feedback, but will certainly include 
this in the summary for the WG update.

Joe

>> Status:
>> https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-03
>>
>> Abstract:

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 3 Jul 2014 17:38:51 +0000

Hi Joe,

Am 03.07.2014 um 17:58 schrieb Joe Touch <[email-masked]>:

> I’ll wait to see what the WG thinks about this too. 793 says these bits "Must be zero." - it could easily have said "must be ignored", but it doesn't, so I continue to disagree it's ambiguous, but it's certainly useful to raise this as a consensus issue.

Despite our interoperation of RFC 793, IMO, it also make sense to
check the src code of current OSes to see how they interoperate
this.

Alex

> I don't think it's worth issuing a quick update based only on these points; I'd like to get more WG feedback, but will certainly include this in the summary for the WG update.
> 
> Joe
> 
>> 
>> 
>> Bob
>>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Jul 2014 19:43:21 +0100

Joe, Alex,

> > I'll wait to see what the WG thinks about this too. 793 says 
> these bits "Must be zero." - it could easily have said "must be 
> ignored", but it doesn't, so I continue to disagree it's ambiguous, 
> but it's certainly useful to raise this as a consensus issue.
>

That's not my concern. I just don't want the IETF to publish text 
that confirms an interpretation of this sentence in RFC793 that 
prevents any future use of these flags.

All I'm asking Joe to do is repeat what the spec says verbatim, 
rather than interpreting it in any particular way. I'm not even 
asking him to interpret it in a different way.

You (Joe) are interpreting the verb to 'be' as if it is from the the 
viewpoint of an external observer anywhere on the path. The authors 
probably simply meant 'be' from the sender's perspective when 
creating the header, and didn't even consider any other perspective.

If a spec says bits must be zero, that does not allow anyone to 
unequivocally infer the action for a receiver or a forwarder to take 
if they are not zero. It could have meant any of:
- drop the packet
- clear them to zero
- ignore and forward unchanged
- ignore and mask them to zero when doing calculations over the 
header but don't change them

You and I can certainly argue in hindsight that some of these 
alternatives are more practical than others. But if this question had 
been raised at the time, the authors and Jon Postel might have simply 
changed the text, realising that they didn't actually intend to mean 
any bits "must be zero" for all time anyway.

Can you really imagine that Jon or the co-authors of RFC793 would 
have mandated that certain bits must always be zero and the packet 
should be dropped if they are not?

Bob

> > I don't think it's worth issuing a quick update based only on 
> these points; I'd like to get more WG feedback, but will certainly 
> include this in the summary for the WG update.
> >
> > Joe
> >
> >>
> >>
> >> Bob
> >>

---

From: John Leslie <[email-masked]>
Date: Thu, 3 Jul 2014 15:32:26 -0400

> asking him to interpret it in a different way.

   I'd like to support Bob here.

   It's best to say "RFC793 says..." and leave it at that.

> creating the header, and didn't even consider any other perspective.

   As I read 793, this specifies how the bits should be set by the
sending TCP stack. I find no intent that the receiving TCP stack should
be able to depend on them being zero.

   This doesn't mean, of course, that 793 authorizes middleboxes to
do anything to these bits; but IMHO it states an expectation that some
meaning might be attached to these in the future: thus a receiving
TCP stack may at some future date attach a meaning to them (to be
defined in an update to 793) without necessarily having negotiated
that meaning with the sending stack.

   (If, in fact, there is some _other_ document which says packets
must be dropped if these bits are not zero, please cite it. If you
mean that common implementations drop such packets, the wording needs
to be quite different...)
  
--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 13:13:35 -0700

Hi, all,

Regarding the reserved bits, I hope the following pending revision will 
resolve this thread:

---
The Reserved TCP header bits cannot be redefined easily, even though 
three of the six total bits have already been redefined (ECE/CWR 
[RFC3168] and NS [RFC3540]). Legacy endpoints have been known to reflect 
received values in these fields; this was safely dealt with for ECN but 
would be difficult here [RFC3168].
---

I will note that, in a general sense, the ambiguity in RFC 793 has two 
parts:

- what should an endpoint that receives non-zero Reserved bits do?
	IMO an endpoint that drops them would be compliant
	as written, though I agree the current text also allows
	them to be ignored on receipt.

	This needs to be fixed in RFC793-bis, and I'll send a
	separate note on that shortly.

- even if legacy recipients of non-zero Reserved bits ignore them, 
there's still the issue of what emitters do

	RFC3168 notes that one implementation (at the time)
	reflected those bits when creating a segment in
	response to an arrival. It notes that ECN's use
	of those bits is tolerant of that behavior, but
	using those bits to signal EDO wouldn't be as
	forgiving (thus the text above).

	I'm currently reviewing FreeBSD and Linux code,
	but so far I do not see that these bits are
	actively zeroed on transmission. That's clearly
	non-compliant, and needs to be addressed as well.
	I.e., a reflected segment (as RFC3168 notes)
	or even non-zero bits in newly-obtained buffers
	could cause a problem in that case.

Joe

---

From: Ted Faber <[email-masked]>
Date: Thu, 03 Jul 2014 13:21:31 -0700

> that meaning with the sending stack.

This is also my interpretation.  Well put.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP:
http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See
http://www.isi.edu/~faber/FAQ.html#SIG

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 13:26:34 -0700

> This is also my interpretation.  Well put.

FWIW, middleboxes shouldn't be altering these bits; although Reserved, 
they're already included in the TCP checksum as well any TCP or 'lower' 
protocol security (TCP-AO or IPsec, e.g.). Changing those bits en-route 
will currently cause the packet to be dropped as a result.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jul 2014 13:30:11 -0700

Going back to the other suggestions:

> I notice TFO was also overlooked during the timstamp options thread in

The current roster is defined as those that are currently in widespread 
use. I don't think that applies to TFO, so I'm not as convinced it's 
worth addressing this in specific.

> Please don't say this.

Fixed as of the next version, as noted in my other post.

> S4. s/byte rder/byte order/

Fixed.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Jul 2014 23:25:21 +0100

Joe,

At 21:13 03/07/2014, Joe Touch wrote:
>Hi, all,
>
>Regarding the reserved bits, I hope the following pending revision 
>will resolve this thread:
>
>---
>[RFC3168] and NS [RFC3540]). Legacy endpoints have been known to 
>reflect received values in these fields; this was safely dealt with 
>for ECN but would be difficult here [RFC3168].
>---

THat's good. Thx.

>I will note that, in a general sense, the ambiguity in RFC 793 has two parts:
>

Again, thx.

You will see in draft-kuehlewind-accurate-ecn-03 (just posted), we 
had to design the capability negotiation around this reflection 
problem, much as ECN had to:
<http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#section-3.1>

You may also be interested to note that accurate-ecn reserves bits in 
the Urgent Pointer for use when URG=0. Richard Scheffenegger has been 
testing this and his initial findings are that a non-zero Urgent 
Pointer when URG=0 is more likely to get through than a non-zero ECN 
field on the paths he tested.

He discovered that earlier versions of Windows did not actively zero 
the Urgent Pointer, so the hypothesis is that middlebox designers 
found it easiest to ignore a non-zero Urgent Pointer, which is 
fortunate for us now.

>         could cause a problem in that case.

Do you know which implementation RFC3168 was talking about that 
reflects the flags? And is there evidence that others have appeared 
since that do this?

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Jul 2014 23:51:14 +0100

Joe,

>The current roster is defined as those that are currently in 
>widespread use. I don't think that applies to TFO, so I'm not as 
>convinced it's worth addressing this in specific.

TFO was became on by default in Linux 3.13 (Jan 2014), and it is 
supported by Firefox, Chrome and probably other browsers. It has to 
be explicitly enabled from the app for each connection, so I don't 
know how frequently it is actually enabled. But I think it is safe to 
assume that it has as much right to appear in your roster as MPTCP 
(they are both experimental status at the IETF, but both starting to 
be deployed).

Bob

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2014 16:00:53 -0700

On 7/3/2014 3:25 PM, Bob Briscoe wrote:
> You will see in draft-kuehlewind-accurate-ecn-03 (just posted), we had
> to design the capability negotiation around this reflection problem,
> much as ECN had to:
> testing this and his initial findings are that a non-zero Urgent Pointer
> when URG=0 is more likely to get through than a non-zero ECN field on
> the paths he tested.
>
> He discovered that earlier versions of Windows did not actively zero the
> Urgent Pointer, so the hypothesis is that middlebox designers found it
> easiest to ignore a non-zero Urgent Pointer, which is fortunate for us now.
>
>
> Do you know which implementation RFC3168 was talking about that reflects
> the flags? And is there evidence that others have appeared since that do
> this?

No idea - just the info that's already in RFC3168.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2014 17:00:35 -0700

On 7/3/2014 3:51 PM, Bob Briscoe wrote:
> supported by Firefox, Chrome and probably other browsers.

I'm interested to know whether those apps follow the applicability 
statement in the TFO spec, e.g., turning this feature off for POSTs vs GETs.

> It has to be
> explicitly enabled from the app for each connection, so I don't know how
> frequently it is actually enabled. But I think it is safe to assume that
> it has as much right to appear in your roster as MPTCP (they are both
> experimental status at the IETF, but both starting to be deployed).

Sure. FYI, TFO doesn't appear to be all that big. It can be as large as 
16 bytes but the typical appears to be 8 bytes.

NB: TFO is only 2 bytes in the SYN, so doesn't need to be mentioned in 
the other SYN-extension variant doc under development. I did expand the 
discussion in the EDO document on this, though.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 8 Jul 2014 15:41:20 +0100

Joe,

>statement in the TFO spec, e.g., turning this feature off for POSTs vs GETs.

Dunno.

>Sure. FYI, TFO doesn't appear to be all that big. It can be as large 
>as 16 bytes but the typical appears to be 8 bytes.
>
>NB: TFO is only 2 bytes in the SYN, so doesn't need to be mentioned 
>in the other SYN-extension variant doc under development. I did 
>expand the discussion in the EDO document on this, though.

Not correct. TFO is 2B only for the cookie request on the first SYN 
between two hosts. Then 6-18B on subsequent SYNs that use the cookie.

Bob

---

From: David Borman <[email-masked]>
Date: Tue, 8 Jul 2014 14:48:30 +0000

On Jul 3, 2014, at 3:13 PM, Joe Touch <[email-masked]> wrote:

> Hi, all,
> 
> Regarding the reserved bits, I hope the following pending revision will resolve this thread:
> 
> ---
> The Reserved TCP header bits cannot be redefined easily, even though three of the six total bits have already been redefined (ECE/CWR [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to reflect received values in these fields; this was safely dealt with for ECN but would be difficult here [RFC3168].
> ---
> 

It says "Reserved for future use.  Must be zero.”  The underlying principal has always been be conservative in what you send, and liberal in what you accept.  Sending packets with garbage in the reserved bits makes them useless for future use, “Must be zero” applies to sending, so that the bits *can* be used in the future.  Being liberal in what you accept means you ignore the reserved bits on input, not drop the packet if the reserved bits are non-zero.  While RFC 793 doesn’t explicitly say the Reserved bits should be ignored on input, it also doesn’t explicitly say anywhere that you should even look at those bits on input.  Arguing that dropping packets with non-zero Reserved bits is compliant ignores the spirit of be liberal in what you accept.

> - even if legacy recipients of non-zero Reserved bits ignore them, there's still the issue of what emitters do

I see no issue for emitters, RFC 793 is quite clear on that, "Reserved for future use.  Must be zero.”  Any implementation that has not implemented future use of those bits is not in compliance with RFC 793 if it puts non-zero values into the reserved bits.

> 	actively zeroed on transmission. That's clearly

The reserved bits have always been zeroed in BSD code.  Not directly in tcp_output(), but in the template header.  In older BSD code this happened in tcp_template(), in the current FreeBSD code it’s in tcpip_fillheaders(); in both cases look for th_x2 and you’ll see where it gets cleared.  The th_x2 field is the top 4 reserved bits, the bottom 2 reserved bits get cleared when th_flags is initialized to zero.

			-David Borman

> 	could cause a problem in that case.

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 10:10:03 -0700

Changing the thread on this, because IMO it's more related to the 793bis 
than EDO...

> On Jul 3, 2014, at 3:13 PM, Joe Touch <[email-masked]> wrote:
...
> It says "Reserved for future use. Must be zero.” The underlying
> principal has always been be conservative in what you send, and liberal
> in what you accept. Sending packets with garbage in the reserved bits
> makes them useless for future use, “Must be zero” applies to sending, so
> that the bits *can* be used in the future.

I agree that's a reasonable interpretation.

> Being liberal in what you
> accept means you ignore the reserved bits on input, not drop the packet
> if the reserved bits are non-zero.

There are two interpretations of "Must be zero":
	a) current implementations should drop segments with those bits
	set

	b) current implementations should ignore those bits

> While RFC 793 doesn’t explicitly say
> the Reserved bits should be ignored on input, it also doesn’t explicitly
> say anywhere that you should even look at those bits on input.

It says "Must be zero." That can easily be interpreted as requiring that 
when the bits are set the segment is invalid.

> Arguing
> that dropping packets with non-zero Reserved bits is compliant ignores
> the spirit of be liberal in what you accept.

While I agree with the general principle, the current text is ambiguous. 
"Must be zero" can be taken as a directive to validate those bits on 
receipt.

Note that RFC793 doesn't define what to do when the Data Offset is 
smaller than 5 - so does that mean you should be liberal and process 
such segments, or drop them?

I agree that "liberal" means that, in either case, you MUST NOT generate 
a response segment, ICMP message, or user error. But it's not as clear 
*from the current text*.

The point of all this is that 793bis needs to be updated to make this 
direct and explicit, though.

> I see no issue for emitters, RFC 793 is quite clear on that,
> "Reservedfor future use. Must be zero.” Any implementation that has not
> implemented future use of those bits is not in compliance with RFC 793
> if it puts non-zero values into the reserved bits.

I agree, but we don't have evidence as to whether this is the case or not.

> The reserved bits have always been zeroed in BSD code. Not directly
> in tcp_output(), but in the template header. In older BSD code this
> happened in tcp_template(), in the current FreeBSD code it’s in
> tcpip_fillheaders(); in both cases look for th_x2 and you’ll see
> where it gets cleared. The th_x2 field is the top 4 reserved bits,
> the bottom 2 reserved bits get cleared when th_flags is initialized
> to zero.

I found that after I posted the message above; I have not been able to 
as directly find the evidence in the Linux code, though.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 10:15:29 -0700

...
>> the other SYN-extension variant doc under development. I did expand
>> the discussion in the EDO document on this, though.
>

Ahh, got it; I'll add it to the SYN-EDO draft in process.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 08 Jul 2014 13:33:53 -0400

>     b) current implementations should ignore those bits

It's worth noting that interpretation b also implies that future uses
of those bits should be done in a way that doesn't cause them to
override processing of other parts of the standard header.  In other
words, ignoring them when set limits the possible semantics that they
can be used for.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 10:47:59 -0700

> words, ignoring them when set limits the possible semantics that they

Ignoring them when set limits their semantics.

Not ignoring them when set limits their semantics.

I.e., either way something is compromised.

We have no "drop if you don't understand it" bits or fields in TCP per 
se. Nothing says to drop DO<5. We do drop sequence numbers outside the 
window, but by interpreting those fields.

NOTE: *nothing* in 793 says to ignore options you don't understand; it 
actually says that options are option in a given segment but that all 
TCPs must implement all options. That can easily be interpreted as "if 
you see an option you don't understand, drop the segment".

It wasn't until RFC1122 that we decided to declare otherwise, that both 
IP and TCP must silently ignore options not undersood.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 8 Jul 2014 17:48:57 +0000

> words, ignoring them when set limits the possible semantics that they

To some degree, yes, but only in the initial SYN packet, just like for TCP options, e.g. WSopt does change processing of the standard header, but only after both sides mutually agree to support it.  If a bit is going to change the processing of the standard header, it can’t apply to the initial SYN, and mutual support has to be negotiated via some mechanism.

			-David

---

From: John Leslie <[email-masked]>
Date: Wed, 9 Jul 2014 07:09:20 -0400

Joe Touch <[email-masked]> wrote:
>  a) current implementations should drop segments with those bits set
> 

   Indeed, we must work around endpoints which do either of these.

> when the bits are set the segment is invalid.

   But only so interpreted by an endpoint. No middlebox is entitled to
do that.

   (Of course, a middlebox _is_ entitled to drop an IP packet for any
reason whatsoever.)

   Our problem is that currently-deployed "middleboxes" do a bunch of
things which really qualify as "damage". Accept that, but don't argue
that it's a reasonable interpretation of 793.

> such segments, or drop them?

   That's a good question. Let me at least nibble around the edges.

   If the two endpoints have agreed on a meaning, of course the receiver
should process it.

   If a receiver _hasn't_ agreed on a meaning, it should own up to
having no clue whether there are any options and/or any data. If
the checksum validates, it's probably time to give up and close the
connection; otherwise it could discard the packet.

   If a middlebox sees Data Offset less than five, it similarly
should probably admit it has no clue whether there are any options
or any data. If all it wants to do is rewrite source IP and port,
it should probably do that and pass everything else unchanged,
adjusting the checksum.

   If a middlebox wants to do something with options or data, it
probably needs to drop the packet -- because it can't do what it is
designed to do.

   Now we get into the really messy area: if a middlebox sees that
something like EDO has been negotiated (which _is_ possible when
it intercepts in both directions), should it process according to
that option?

   IMHO, there's no fully satisfactory answer to that. Myself, I'd
prefer it didn't. A middlebox wanting to meddle that much should
act as an endpoint. (But of course, we can't enforce that.)

> direct and explicit, though.

   Alas, that won't fix the problem. At best, it might change new
middlebox designs. There's no way it could fix deployed middleboxes.
(But it would _feel_ better to have an unambiguous statement that
this is damage!)

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Jul 2014 08:29:28 -0700

Hi, John,

>   But only so interpreted by an endpoint. No middlebox is entitled to

Right - my claim has always been that there are no such things as middleboxes; there are hosts and there are routers. Routers ought to look no further than L3; everything else is acting like a host, and breaks what we expect when we think of an Internet. That's especially true for boxes that modify L3 or L4 beyond what RFC1812 permits (HBH options, hopcount, IP checksum).

>   (Of course, a middlebox _is_ entitled to drop an IP packet for any

Anything that is visibly indistinguishable from a link is a link (or a part of a link). The same applies to routers and hosts, to me at least. Intent and mechanism aren't relevant; externally visible behavior is.

> that it's a reasonable interpretation of 793.

Agreed.

>   If the two endpoints have agreed on a meaning, of course the receiver

That's true for any property. It doesn't mean they're running TCP anymore, though.

> connection; otherwise it could discard the packet.

I don't think a single invalid segment should ever affect a connection or connection in progress. I would say "silent drop" to any packet that can't be understood.

> it should probably do that and pass everything else unchanged,

I disagree; a middlebox that modifies the IP address and/or TCP ports is acting as a host to the downstream components, and should be expected to follow host requirements. In this case, if a host MUST silently drop nonsense packets then so should a box that looks like a host.

> probably needs to drop the packet -- because it can't do what it is

I think it has to have already dropped it.

> act as an endpoint. (But of course, we can't enforce that.)

See above; I've been saying as much for a long time. Actually NAT boxes are a little more complex:

	- to the upstream (the devices "behind") them, they MUST act like a router
	(including decreasing the hopcount, etc.)

	- to the downstream, they MUST act like a host

So they get twice the requirements.

> (But it would _feel_ better to have an unambiguous statement that

Sometimes that's the best we can do; sometimes it's better to declare what's deployed "broken" than to try to find a way to accommodate it.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 11 Jul 2014 09:02:05 -0700

overall I like this new draft. but I am not sure why default-on would
interfere legacy apps. To me EDO is similar to SACK. We always want to
negotiate this capability but only  use the feature at times when
needed. My primary interests to use EDO is for reporting large number
of SACK blocks under high-reordering high-ack-loss high-bw networks.
I am not sure if apps should opt-in this case.

">> Implementations can also employ system-wide defaults, however
   systems SHOULD NOT use this extension by default to avoid
   interfering with legacy applications."

On Wed, Jul 2, 2014 at 5:01 PM, Joe Touch <[email-masked]> wrote:
> I'd like to suggest this version be the topic of discussion for inclusion as
> a WG doc, intended for (preferably) PS or at least Experimental.
>
> The SYN DO extension is intended to be considered separately, and would be
> focused at Experimental (whether in the WG or individual).
>
> I won't be in Toronto, but will provide a slideset summarizing the changes
> as well.
>
> Joe
>
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 11 Jul 2014 12:16:26 -0400

>    interfering with legacy applications."

It could cause trouble for the application if middlebox issues are
causing corruption / disruption in connections using EDO.

It might be possible to work around this similar to ICMP or ECN black
holes, if EDO is on by default and "EDO black holes" can be detected,
but I think it would take more effort.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Jul 2014 10:51:48 -0700

> causing corruption / disruption in connections using EDO.

Yup - the text should be reworded. The issue isn't interference with 
legacy apps; it is that ANY app (legacy or new) that doesn't actively 
need the feature should avoid using it - that goes for ALL TCP options, IMO.

> but I think it would take more effort.

Yup.

Joe