Re: [tcpm] New Version Notification for draft-kuehlewind-tcpm-ecn-fallback-00.txt

hi Richard,

Thanks for the comments! Inline...

On 16 Jul 2013, at 14:55 , "Scheffenegger, Richard" <rs@netapp.com> wrote:

> Brian, Mirja,
> 
> 
> Having read this draft (I think the rationale for not probing in the IW is a good one, but perhaps a little more text in the draft would do good - i.e. a short flow will be effectively non-reactive anyway, thus any ECN signal would be superfluous), I like it.
> 
> 
> I have one (probably academic) point though:
> 
> 
> (I would like to see a diagram visualizing the probing process).

Good suggestion; we'll add one in the next rev.

> In Step 4, the algo sends the next 3 segments after IW with "CE". In addition to the "first hop must not have experienced congestion" scenario, a middlebox might also clear CE if these three segments are pure ACKs, as per 3168, pure ACKs should not be marked ECN-capable... also, you expect an ACK for these. Thus you need to send 3 "data segments" not simply segments, right?

Yep, this is what we meant, but we need to make this more clear.

> In Step 6, you mention an interaction with ECN Nonce... Perhaps having an explicit example for an ECN-Nonce enabled session would do well (which can detect the removal of the CE-flag in probing data segments by sending one ECT(1) data segment).
> 
> In Step 7, CWR should be sent with the segment (not necessarily data segment) ACKing any of the 1st up to the 3rd probing CE data segment. This could be 1, 2 or 3 segments (the text only hints on a single such segment).

hm, that wasn't the intention, but on review that could be clearer, as well. We'll make it so.

> Including the optional ECN Nonce probing (4th segment with ECT1; 4th ACK with NS=1) in the algorithm might be good...

Good suggestion; we were originally thinking of something a little more elaborate, and I do think we need to think about this a bit more, though, since an actual CE mark would obliterate the nonce. I know that's unlikely _now_, but one of the goals of the work is making it less so. :)

Cheers,

Brian

>> -----Original Message-----
>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>> Brian Trammell
>> Sent: Donnerstag, 04. Juli 2013 14:14
>> To: tcpm@ietf.org
>> Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-
>> ecn-fallback-00.txt
>> 
>> Greetings, all,
>> 
>> We've posted a draft on ECN path probing and fallback, which we'd like to
>> discuss at the TCPM meeting in Berlin. In a recent work [1], we found that
>> though the ECN-readiness of popular webservers has significantly increased
>> even in the last couple of years, there still exist paths on which
>> attempts to use ECN after successful ECN negotiation will cause connection
>> disruption.
>> 
>> This draft proposes an experimental approach to determine at runtime
>> whether a path is usable, by sending segments after connection startup and
>> ECN negotiation with the CE codepoint set, and disabling ECN if all probe
>> segments were lost, on a per-flow or per-destination basis.
>> 
>> Experiments with an implementation of the approach within the Linux kernel
>> are underway; we plan to be able to present initial results in Berlin.
>> 
>> Best regards,
>> 
>> Mirja and Brian
>> 
>> [1] Kuehlewind, M., Neuner, S., and Trammell, B., "On the state of ECN and
>> TCP Options on the Internet", in Proceedings of the the 2013 Passive and
>> Active Measurement Conference, Hong Kong SAR, China, 19 March 2013.
>> 
>> Begin forwarded message:
>> 
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for
>>> draft-kuehlewind-tcpm-ecn-fallback-00.txt
>>> Date: 3 July 2013 17:40:32 GMT+02:00
>>> To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>, Brian
>>> Trammell <trammell@tik.ee.ethz.ch>
>>> 
>>> 
>>> A new version of I-D, draft-kuehlewind-tcpm-ecn-fallback-00.txt
>>> has been successfully submitted by Mirja Kuehlewind and posted to the
>>> IETF repository.
>>> 
>>> Filename:	 draft-kuehlewind-tcpm-ecn-fallback
>>> Revision:	 00
>>> Title:		 A Mechanism for ECN Path Probing and Fallback
>>> Creation date:	 2013-07-02
>>> Group:		 Individual Submission
>>> Number of pages: 5
>>> URL:             http://www.ietf.org/internet-drafts/draft-kuehlewind-
>> tcpm-ecn-fallback-00.txt
>>> Status:          http://datatracker.ietf.org/doc/draft-kuehlewind-tcpm-
>> ecn-fallback
>>> Htmlized:        http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-
>> fallback-00
>>> 
>>> 
>>> Abstract:
>>>  Explicit Congestion Notification (ECN) is a TCP/IP extension that is
>>>  widely implemented but hardly used due to the perceived unusablilty
>>>  of ECN on many paths through the Internet caused by ECN-ignorant
>>>  routers and middleboxes.  This document specifies an ECN probing and
>>>  fall-back mechanism in case ECN has be successfully negotiated
>>>  between two connection endpoints, but might not be usable on the
>>>  path.
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm