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

[Yuchung Cheng <[e-mail]>]

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