[tsvwg] End of thread: Interaction between L4S and tunnel-congestion-feedback

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

Bob,

I'm going to end discussion of ECT(1) for tunnel congestion feedback here
and start a new thread  as it's clear (at least to me) that a WG decision is
needed on this matter.   This thread began with what I thought was a request
for a minor clarification to the Tunnel Congestion Feedback (TCF) draft:

> Given L4S, I think we just need to make sure a tunnel ingress solely
> sets Not-ECT packets to ECT(0), not ECT(1).

Based on the discussion that has transpired, it’s no longer reasonable to
treat that as a request for a minor clarification.   I will write up the question
that I believe the  WG needs to resolve and start a separate thread towards
resolving it.

At this point, I think this ECT(1) issue needs to be resolved before the TCF
draft goes to Working Group  Last  Call.   FWIW, it looks like another revision
of the TCF draft will be needed anyhow for WG Last Call in any case, as I’ll
explain in the message that starts the other thread.

Thanks, --David

From: Bob Briscoe [mailto:[e-mail]]
Sent: Sunday, August 14, 2016 9:21 AM
To: Black, David; [e-mail]
Cc: tsvwg IETF list
Subject: Re: Interaction between L4S and tunnel-congestion-feedback


David,

On 09/08/16 20:59, Black, David wrote:

Bob,



Every other ECN spec has always stated that ECT(0) is the default, if

there's no need to use two codepoints.

That latter sentence on default use of ECT(0) is ok with me.



In contrast, I read the original message as requesting a prohibition on the use

of ECT(1) for this purpose:

Good...



Ok ...



Given L4S, I think we just need to make sure a tunnel ingress solely

sets Not-ECT packets to ECT(0), not ECT(1).

That's something rather different, and not ok.  For example, it would

prevent tunnel congestion feedback from probing the low latency side

of L4S.

The sentence above says nothing to prevent the tunnel ingress /creating/

its own ECT(1) probe packets.



That's not relevant - there is no text in the tunnel congestion feedback

draft about creating any packets.
[BB] OK. I only went down this line of thinking because you used the term "probing" which normally means newly created traffic, not modifying customer traffic.






This draft says, when the inner is Not-ECT, the ingress can change the

outer to ECT.

It ought to say, when the inner is Not-ECT, the ingress can only change

the outer to ECT(0).



Sorry, "can only" is back in "prohibition" territory.   In my view, this

is akin to an endpoint adding ECT marks, as the tunnel ingress is

doing that as a measurement endpoint - the existing behavior is:



Every other ECN spec has always stated that ECT(0) is the default, if

there's no need to use two codepoints.



I'm ok with text that says that the default configuration MUST only use

ECT(0) for Not-ECT traffic,  and also with text that says that the ingress

SHOULD NOT use ECT(1) for Not-ECT traffic in the absence of knowledge

of what (if any) different network behavior ECT(1) may cause inside the

tunnel by comparison to ECT(0).
[BB] If this draft says faked ECT (encapsulating a Not-ECT inner) MUST only use ECT(0) on the outer, it does not prevent you or someone else standardising an additional test that compares the difference between ECT(1) and ECT(0) outers on customer traffic with a Not-ECT inner. You could either add this to the draft now, or a new RFC could add it later.

However, if you want to add another idea for how tunnel congestion feedback might be used, it needs to be motivated and written up as a proposal to put in this draft. Particularly because:
* it needs two codepoints, whereas the faked ECT idea in the draft only needs one.
* ECT(1) is in the IP header (v4 & v6), where space it at an extreme premium
* it would create a hurdle to any future use of ECT(1), particularly as a classifier for more aggressive marking
* it uses customer traffic for experimentation.


Indeed, when Murari and I first proposed the idea of faking ECT at a tunnel ingress, we specified MUST use ECT(0) - because it only /needed/ one codepoint.
That was Feb 2013; long before L4S was even thought of.
(see https://tools.ietf.org/html/draft-briscoe-conex-data-centre-01#section-5.1.3 quoted below:)

   3.  Directly after encapsulation (but not if the packet was not

       encapsulated):



       1.  If and only if the ECN field of the outer header is not ECN-

           capable (Not-ECT i.e. 00) it MUST be made ECN-capable by

           remarking it to ECT(0), i.e. 01.



       2.  If the outer ECN field carries any other value than 00, it

           should be left unchanged.
This idea was borrowed by draft-wei-tsvwg-tunnel-congestion-feedback-04 in July 2015, but unfortunately with much less precise wording.

Cheers


Bob






I'm not ok with text that says that  ECT(1) MUST NOT be used for Not-ECT

traffic, as that reduces the scope of the tunnel-congestion feedback draft's

potential usage.  I'm ok with the above SHOULD NOT that warns about

what could happen.



Thanks, --David



-----Original Message-----

From: Bob Briscoe [mailto:[e-mail]]

Sent: Tuesday, August 09, 2016 12:58 PM

To: Black, David; Gorry Fairhurst; draft-ietf-tsvwg-tunnel-congestion-

[e-mail]<mailto:[e-mail]>

Cc: tsvwg IETF list

Subject: Re: Interaction between L4S and tunnel-congestion-feedback



David,





On 09/08/16 16:12, Black, David wrote:

Bob,





      Faked ECN-capable transport (ECT) is used at ingress to defer packet

                                   ^^^

      loss to egress. [...]



By just saying "ECT", implementers might set faked ECT to either ECT(0)

or ECT(1), when faked ECT doesn't need more than one codepoint.

Every other ECN spec has always stated that ECT(0) is the default, if

there's no need to use two codepoints.

That latter sentence on default use of ECT(0) is ok with me.



In contrast, I read the original message as requesting a prohibition on the use

of ECT(1) for this purpose:

Good...



Given L4S, I think we just need to make sure a tunnel ingress solely

sets Not-ECT packets to ECT(0), not ECT(1).

That's something rather different, and not ok.  For example, it would

prevent tunnel congestion feedback from probing the low latency side

of L4S.

The sentence above says nothing to prevent the tunnel ingress /creating/

its own ECT(1) probe packets.



This conversation is solely about packets that arrive as Not-ECT, and

what codepoint an ingress is allowed to /change/ the outer to.

We can't allow an ingress to arbitrarily change Not-ECT packets to

anything it wants.

Before this draft, all RFCs have always said that an ingress must not

change Not-ECT to anything else.



This draft says, when the inner is Not-ECT, the ingress can change the

outer to ECT.

It ought to say, when the inner is Not-ECT, the ingress can only change

the outer to ECT(0).

This is sufficient to defer any light congestion drop to the egress,

which is what tunnel congestion feedback is trying to do by using faked ECT.







Bob









Thanks, --David



-----Original Message-----

From: Bob Briscoe [mailto:[e-mail]]

Sent: Monday, August 08, 2016 7:45 PM

To: Black, David; Gorry Fairhurst; draft-ietf-tsvwg-tunnel-congestion-

[e-mail]<mailto:[e-mail]>

Cc: tsvwg IETF list

Subject: Re: Interaction between L4S and tunnel-congestion-feedback



David,



I think you've missed my point.



* I am definitely not trying to limit what tunnel congestion feedback

/copies/ at the ingress, or what it /reports/ from the egress.



* I am only wanting to limit which ECT codepoint the ingress "fakes".



First, at the ingress, tunnel congestion feedback copies the ECN field

to the outer. So if the inner is already ECT(1), copying ECT(1) to the

outer is fine - that's regular ECN tunnel behaviour. And subsequently

reporting any ECT(1) back from the egress is fine too.



However, after the ingress copies the ECN field but before it forwards

the packet, if the outer is Not-ECT it sets it to "ECT", as highlighted

in the text I quoted:



      Faked ECN-capable transport (ECT) is used at ingress to defer packet

                                   ^^^

      loss to egress. [...]



By just saying "ECT", implementers might set faked ECT to either ECT(0)

or ECT(1), when faked ECT doesn't need more than one codepoint.

Every other ECN spec has always stated that ECT(0) is the default, if

there's no need to use two codepoints.



If the draft does not specifying which ECT the ingress should use as a

default for faked ECT, it will unnecessarily burn both ECT(0) and ECT(1)

for deferred loss, so that nothing (whether L4S or anything else) can

use ECT(1) differently from ECT(0) in future.



This is a perfectly reasonable request, and would be sensible even if we

were not proposing L4S.



It's not specific to L4S, so there is no need to mention anything about

what might be planned for L4S.







Bob





On 08/08/16 14:55, Black, David wrote:

Bob,



[writing as draft shepherd, not WG chair]



Given L4S, I think we just need to make sure a tunnel ingress solely

sets Not-ECT packets to ECT(0), not ECT(1).

I respectfully disagree.   The tunnel congestion feedback draft is already

capable of reporting congestion statistics for both ECT(0) and ECT(1).



I'll also observe that I don't think L4S is at the point where we should

reserve ECT(1) for L4S and nothing else.



The tunnel congestion feedback draft doesn't contain any language on

how to use ECT(0) vs. ECT(1), e.g.,  in what proportion to mark them.  I

could see adding a sentence about that, but it's likely to be vague, as

at the general level of this draft, there's no strong reason to restrict or

prefer one of the codepoint.



I could see making a factual statement that ECT(1) is likely to be used

for work on varying congestion marking behavior, but if L4S wants to

recommend that tunnel congestion feedback not use ECT(1) due to

queue effects, that recommendation probably belongs in an L4S draft.



Thanks, --David



-----Original Message-----

From: Bob Briscoe [mailto:[e-mail]]

Sent: Friday, July 22, 2016 4:31 AM

To: Black, David; Gorry Fairhurst; draft-ietf-tsvwg-tunnel-congestion-

[e-mail]<mailto:[e-mail]>

Cc: tsvwg IETF list

Subject: Interaction between L4S and tunnel-congestion-feedback



Chairs, list,



The draft-ietf-tsvwg-tunnel-congestion-feedback-02 draft says



      Faked ECN-capable transport (ECT) is used at ingress to defer packet

      loss to egress. [...]





Given L4S, I think we just need to make sure a tunnel ingress solely

sets Not-ECT packets to ECT(0), not ECT(1).



I'll think about it further to check all the possible interactions with

other RFCs and L4S, but I think that's all.



Cheers







Bob



--





______________________________________________________________

__

Bob Briscoe                               http://bobbriscoe.net/

--



______________________________________________________________

__

Bob Briscoe                               http://bobbriscoe.net/



--

______________________________________________________________

__

Bob Briscoe                               http://bobbriscoe.net/





--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/