Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 Apr 2014 17:02:08 +0100

Yuchung,

In draft-tcpm-fastopen, you may be able to get away with saying 
nothing about this, but..

1) Just in case someone thinks it would be clever for a TFO client to 
resume use of ECN on a subsequent SYN, it may be best to clarify that:
"TFO does not allow a subsequent connection to reuse the ECN 
capability negotiated in a previous connection. If TCP endpoints 
negotiate the use of ECN, they MUST apply the initialization rules 
(Section 6.1.1 of [RFC3168]) separately for each connection."

2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), 
just to give developers a tick-list of RFCs to use. However, if you 
plan to quickly move TFO on from experimental status, make sure you 
just say this 'for information', rather than as a normative 
reference, because 5562 is experimental.

I know this is my second comment after WGLC, but I thought it best to 
say something. (I was just getting the capability negotiation logic 
in Accurate ECN to interwork with TFO, when I realised this issue 
applied to classic ECN too.)

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 11 Apr 2014 17:42:57 +0000

Bob,

Indeed, the WGLC for draft-tcpm-fastopen has completed... I am about to forward the document to the AD.

Apparently, right now, draft-tcpm-fastopen does not comment on ECN at all, and I am not aware of any past discussion in TCPM.

Thus, my initial thinking would be that if ECN should be addressed in this document, it could be mentioned in section 7 as a topic for further experimentation - instead of adding normative text late in the process. 

Thoughts from the community (and the authors) would be welcome - but please recall that we are really past WGLC and I'd like to move the document forward within the next couple of days.

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Bob Briscoe
> Sent: Thursday, April 10, 2014 6:02 PM
> To: [email-masked]
> Cc: [email-masked]; tcpm IETF list
> Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN
> 
> Yuchung,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 16 Apr 2014 02:09:34 +0100

Michael,

It was only advice about what not to cache. I didn't intend it as a 
suggestion for experimentation. And it doesn't have to be normative 
text (see the non-normative suggestion below).

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Append new para to end of "4.1.3 Client Cookie Handling"

"A client is unlikely to find it useful to cache the result of a 
successful ECN negotiation for a subsequent connection. Attempting to 
resume a connection with a SYN that is ECN-capable at the IP layer is 
likely to risk discard by security devices, and a consequent timeout. 
Initializing ECN separately for each connection using the procedure 
in Section 6.1.1 of [RFC3168] should introduce no worse risk of delay.
"

Additional Informative Reference:

[RFC3168]
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

This doesn't warrant holding up the draft now. If the authors want to 
incorporate this para while dealing with RFC Editor comments later, 
it would be up to them. They might not consider it necessary at all, 
but on balance I think it would be.

Bob

At 18:42 11/04/2014, Scharf, Michael (Michael) wrote:
>Apparently, right now, draft-tcpm-fastopen does not comment on ECN 
>at all, and I am not aware of any past discussion in TCPM.
>
>Thus, my initial thinking would be that if ECN should be addressed 
>in this document, it could be mentioned in section 7 as a topic for 
>further experimentation - instead of adding normative text late in 
>the process.
>
>Thoughts from the community (and the authors) would be welcome - but 
>please recall that we are really past WGLC and I'd like to move the 
>document forward within the next couple of days.
>
>Michael
>
>
>

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 22 Apr 2014 15:02:29 -0700

On Tue, Apr 15, 2014 at 6:09 PM, Bob Briscoe <[email-masked]> wrote:
>
> Michael,
>
> It was only advice about what not to cache. I didn't intend it as a suggestion for experimentation. And it doesn't have to be normative text (see the non-normative suggestion below).
>
>
> "A client is unlikely to find it useful to cache the result of a successful ECN negotiation for a subsequent connection. Attempting to resume a connection with a SYN that is ECN-capable at the IP layer is likely to risk discard by security devices, and a consequent timeout. Initializing ECN separately for each connection using the procedure in Section 6.1.1 of [RFC3168] should introduce no worse risk of delay.
> "
>
> This doesn't warrant holding up the draft now. If the authors want to incorporate this para while dealing with RFC Editor comments later, it would be up to them. They might not consider it necessary at all, but on balance I think it would be.

I am neutral about adding this part. But if we do edit this part, I'd
prefer we explicitly suggest against caching anything other than
what's mentioned in the RFC. So that covers ECN bit, sack, timestamp,
etc. The fast open cache is supposed to cache information only for
fastopen. nothing else.

I want to note that the WG did ask about potential ECN
interoperability issues (Orlando mtg?). After that meeting I did go
over the ECN RFC and didn't find anything obvious.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 23 Apr 2014 09:43:19 +0000

> Initializing ECN separately for each connection using the procedure in
> Section 6.1.1 of [RFC3168] should introduce no worse risk of delay.
> > "
> >
> incorporate this para while dealing with RFC Editor comments later, it
> would be up to them. They might not consider it necessary at all, but
> on balance I think it would be.
> 

As individual contributor to TCPM, this proposal sounds like a good idea to me - I think this is already implied by the draft, but if the current text should not be clear enough, it could perhaps be stated explicitly.

As document shepherd, I'll move this document forward to the AD by end of this week. If anybody has thoughts on such a post-post-WGLC change, please speak up *now*. In particular, I'd really be interested in explicit support for any change of the document, given that the draft has been out for such a long time already.

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Apr 2014 14:33:32 +0100

Yuchung,

Thx. I hadn't realised you had already checked for ECN interactions.

I do not agree with saying no-one should cache anything other than
what's mentioned in the RFC.

For example, at one stage we (me, Mirja, Richard ?) were proposing 
that the timestamp on the SYN could be used to negotiate timestamp 
precision (and other stuff I can't recall at the moment).

If caching a particular item of negotiated connection state X will 
save negotiation delay, and a SYN on a resumed TFO connection can 
re-declare X rather than re-negotiating it, then a valid TFO cookie 
would save negotiation delay in a case where X would be useful on the 
SYN but would normally have to wait for the next round.

Note: even tho the cookie wouldn't need to contain X itself, a valid 
cookie would prove that this client had talked to the server before, 
which may be sufficient proof.

If we are going to say "don't cache anything else", I suggest we say 
"SHOULD NOT cache anything else" and say why. Then for cases where 
the reasons don't apply, we are not stopping people being innovative.

Possible reasons against caching are case-dependent:
* SACK: Negotiation adds no delay because SACK on SYN is irrelevant.
* Window scale: Could save negotiation delay by allowing window 
scaling from the previous session to be meaningful on both SYNs (with data).
* Timestamp: Adds no delay because TS should be on the SYN anyway.
* ECN: An ECT SYN is likely to be discarded by security boxes.
* etc etc.

* In all cases, the client may communicate with a different replica 
of the server that does not have the same config as the original 
server. However, for some features this might be very unlikely.

Apologies that this reply is a bit vague. I'm on holiday, but I 
didn't want to hold up this draft going to the IESG.

Bob

At 23:02 22/04/2014, Yuchung Cheng wrote:
> > It was only advice about what not to cache. I didn't intend it as 
> a suggestion for experimentation. And it doesn't have to be 
> normative text (see the non-normative suggestion below).
> >
> >
> > 
> successful ECN negotiation for a subsequent connection. Attempting 
> to resume a connection with a SYN that is ECN-capable at the IP 
> layer is likely to risk discard by security devices, and a 
> consequent timeout. Initializing ECN separately for each connection 
> using the procedure in Section 6.1.1 of [RFC3168] should introduce 
> no worse risk of delay.
> > "
> >
> > This doesn't warrant holding up the draft now. If the authors 
> want to incorporate this para while dealing with RFC Editor 
> comments later, it would be up to them. They might not consider it 
> necessary at all, but on balance I think it would be.
>
> >> Apparently, right now, draft-tcpm-fastopen does not comment on 
> ECN at all, and I am not aware of any past discussion in TCPM.
> >>
> >> Thus, my initial thinking would be that if ECN should be 
> addressed in this document, it could be mentioned in section 7 as a 
> topic for further experimentation - instead of adding normative 
> text late in the process.
> >>
> >> Thoughts from the community (and the authors) would be welcome - 
> but please recall that we are really past WGLC and I'd like to move 
> the document forward within the next couple of days.
> >>
> >> Michael
> >>
> >>
> >>