Subject: Re: [tsvwg] Interaction between L4S and tunnel-congestion-feedback

From: "Black, David" <[email-masked]>
Date: Mon, 8 Aug 2016 13:55:05 +0000

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:[email-masked]]
> Sent: Friday, July 22, 2016 4:31 AM
> To: Black, David; Gorry Fairhurst; draft-ietf-tsvwg-tunnel-congestion-
> [email-masked]
> 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/

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Aug 2016 00:45:15 +0100

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:

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Aug 2016 15:12:17 +0000

Bob,

> 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

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

Thanks, --David

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: Monday, August 08, 2016 7:45 PM
> Subject: Re: Interaction between L4S and tunnel-congestion-feedback
> 
> David,
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 9 Aug 2016 17:58:25 +0100

David,

> of ECT(1) for this purpose:
Good...
> prevent tunnel congestion feedback from probing the low latency side
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

---

From: "Black, David" <[email-masked]>
Date: Tue, 9 Aug 2016 19:59:01 +0000

Bob,

> > of ECT(1) for this purpose:

Ok ...

> its own ECT(1) probe packets.

That's not relevant - there is no text in the tunnel congestion feedback
draft about creating any packets.

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

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

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

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 14 Aug 2016 14:21:26 +0100

David,

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