Re: [tsvwg] Tunnel Congestion Feedback: Faked ECT and the ECT(1) codepoint

["Black, David" <[e-mail]>]

Hi Xinpeng,

Biting my tongue on the ECT(1) technical issue ... 

Thanks for the response and the confirmation that RFC 6040 ECN decap behavior is intended.

In order to move this tunnel congestion feedback draft along, would you please submit a -03 version that explicitly specifies use of RFC 6040 ECN decap behavior including the use of the CE|Not-ECT case (drop packet) that was described as a "currently unused" combination in RFC 6040.  Please don't do anything about use or non-use of ECT(1) in this -03 version.  My intent is to send that version of the draft to Working Group Last Call, and use that WGLC to sort out the ECT(1) technical issue along with anything else that arises.

Thanks, --David (as draft shepherd)

> -----Original Message-----
> From: Weixinpeng (Jackie) [mailto:[e-mail]]
> Sent: Monday, August 22, 2016 3:32 AM
> To: Black, David; [e-mail]
> Subject: RE: [tsvwg] Tunnel Congestion Feedback: Faked ECT and the ECT(1)
> codepoint
> 
> Hi David and all,
> Sorry for late response for this discussion.
> The following are some of my clarification for TCF draft.
> 
> For the decapsulation behavior at egress, RFC6040 ECN decapsulation behavior is
> intended to be used by TCF. The packet marked as CE|Not-ECT is ought to have
> been dropped in the tunnel, but the faked
> ECN defer the packet to be dropped at egress, this is align with the behavior in
> RFC6040 to drop CE|Not-ECT packet at egress. I will provide this decapsulation
> behavior in the next version.
> 
> The purpose of faked ECN is to assist measuring the congestion level in the
> tunnel, and it will defer packet loss to egress, to this end, both ECT(0) and ECT(1)
> are ok
> for faked ECN, and there are no difference between ECT(0) and ECT(1). To avoid
> potential conflicts with L4S which is to use ECT(1) for L4S traffic marking, I think it
> would be ok to only use ECT(0) in faked ECN.
> Thanks!
> 
> Regards,
> -Xinpeng (Jackie)
> 
> 
> 
> >-----Original Message-----
> >From: tsvwg [mailto:[e-mail]] On Behalf Of Black, David
> >Sent: Monday, August 15, 2016 5:13 AM
> >To: [e-mail]
> >Subject: [tsvwg] Tunnel Congestion Feedback: Faked ECT and the ECT(1)
> >codepoint
> >
> >This is the promised new thread on the ECT(1) topic for the tunnel congestion
> >feedback (TCF) draft.   I'll start with the item I noticed that I think ought to be
> >addressed before the tunnel congestion feedback draft goes to Working Group
> >Last Call:
> >
> >The Faked ECT mechanism sets an ECT codepoint in the outer header of a
> packet
> >whose inner header is marked  Not-ECT).  The TCF draft specified the ECN
> >encapsulation behavior for Faked ECT, but I can't find any explicit specification of
> >the ECN decapsulation behavior.
> >
> > My best guess is that unmodified RFC 6040 ECN decapsulation behavior is
> >intended (if so, that will need to be stated).  That ought to suffice, as RFC 6040
> >covers the crucial congestion-related case for Faked ECT - the tunnel egress
> >drops a packet whose outer header is marked CE but whose inner header is
> >marked not-ECT, thus avoiding forwarding a CE-marked Faked ECT packet
> >beyond the tunnel.
> >
> >TCF draft Authors: What is the intended ECN decapsulation behavior?
> >
> >The answer to that question may help with the ECT(1) issue, as if RFC 6040
> >behavior is  intended, then CE marking of Faked-ECT packets is drop-equivalent,
> >which would be at least an impediment to experimenting with much more
> >aggressive CE marking for ECT(1) than drop equivalence, e.g., as proposed by
> >L4S and strongly supported in principle in Berlin.
> >
> >In any case, I believe the TCF ECT(1) question is:
> >
> >The tunnel congestion feedback draft "remarks outer header of Not-ECT packet
> >as ECT."   There are two ECT codepoints, ECT(0) and ECT(1).  What should
> >the
> >draft say about using them?
> >
> >[A] Default - ECT(0) is the default, ECT(1) is not the default.
> >[B] RECOMMENDED - ECT(0) SHOULD be used, ECT(1) SHOULD NOT be used.
> >[C] REQUIRED - ECT(0) MUST be used, ECT(1) MUST NOT be used.
> >
> >Gorry will have to determine WG rough consensus on this topic, as I've clearly
> >become a party to the technical conversation.   It may be helpful to wait for
> >the
> >TCF draft authors to clarify intended ECN decap behavior before anyone else
> >responds to this TCF ECT(1) question.
> >
> >Thanks, --David
> >----------------------------------------------------
> >David L. Black, Distinguished Engineer
> >EMC, 176 South St., Hopkinton, MA  01748
> >[phone]     Cell: [phone]
> >[e-mail]
> >----------------------------------------------------