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

[Bob Briscoe <[e-mail]>]

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