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

Hi Brian,

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

Indeed... You would want to send the ECT(1) first, and the artificial CEs afterwards; if there is an ACK,ECE for the segment with ECT(1), this would also prove the path is ECN-capable, right?

But I'd like to listen to your elaborate scheme :)

Richard Scheffenegger

> -----Original Message-----
> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]
> Sent: Montag, 22. Juli 2013 17:03
> To: Scheffenegger, Richard
> Cc: tcpm@ietf.org; Mirja Kuehlewind
> Subject: 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