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

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:
>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:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
> > Sent: Thursday, April 10, 2014 6:02 PM
> > To: ycheng@google.com
> > Cc: draft-tcpm-fastopen@tools.ietf.org; 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
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT 