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

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).

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?

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).

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

Richard Scheffenegger

> -----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