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

[Bob Briscoe <[e-mail]>]

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:
>On Tue, Apr 15, 2014 at 6:09 PM, Bob Briscoe <[e-mail]> 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).
> >
> >
> > 
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> > 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.
>
>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.
>
>
> >
> >
> > Bob
> >
> >
> > At 18:42 11/04/2014, Scharf, Michael (Michael) wrote:
> >>
> >> 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:[e-mail]] On Behalf Of Bob Briscoe
> >> > Sent: Thursday, April 10, 2014 6:02 PM
> >> > To: [e-mail]
> >> > Cc: [e-mail]; tcpm IETF list
> >> > Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN
> >> >
> >> > 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
> >> >
> >> > _______________________________________________
> >> > tcpm mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT