Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Bob Briscoe <[e-mail]>]

Sebastian,

If you are not adding to a thread, please consider remaining silent.
I've corrected all your misunderstandings inline (I ignored the one that 
is just a restatement of an opinion), tagged [BB].


On 29/03/2021 13:58, Sebastian Moeller wrote:
> Hi Bob,
>
>
>> On Mar 29, 2021, at 02:35, Bob Briscoe <[e-mail]> wrote:
>>
>> Mike,
>>
>> Many of the arguments for why a DSCP is not useful e2e also apply when it is used as a guard DSCP in a single network. For instance, when an IP header with a DSCP is tunnelled in pipe mode, it is not propagated to the outer. So it won't be visible, won't be bleached, etc.
> 	[SM] Excellent point, sothe  L4S-ops draft should probably a recommendation to also propagate DSCPs in and out while tunneling, if tunneling is something the diffserv domain wants to support for L4S, otherwise the recommendation might simply be to bleach on tunnel ingress (which is a also a naturally safe default, if the tunnel might terminate in another potentially unknown diffserve domain).

[BB] L4S does not involve a DSCP, so there is no need to discuss DSCPs 
in l4sops.


>
>> There's far too much vagueness in this thread.
> 	[SM] Not that much more than in the L4S drafts, where problems magically seem to dissolved when they are punted to the protocols that night want to use L4S signaling, really.
>
>> In the email I just sent to Jonathan, I asked him to address each of the critiques of a DSCP in Appx B.4, not just dismiss them all as invalid, which is untenable.
>> Certainly, some of the critiques are not relevant to the way the DSCP is used in Jonathan's scheme, but many are like the tunnel issue above.
> 	[SM] Odd that tunneling always moves into the spot-light if it helps your argument, but gets more or less ignored when it causes unsolved challenges for L4S, like a tunnel with mixed traffic running over one of the relative common (common as far as AQMs go) FQ rfc3168 compliant AQM. Is it really to much to ask for consistent application of the same yard stick to all proposals?

[BB] The tunnel issue with L4S in VPNs over FQ is addressed in l4sops.
https://datatracker.ietf.org/doc/html/draft-white-tsvwg-l4sops-02#section-3
A solution is mentioned that at least isolates L4S from Classic traffic 
within the same VPN. A later revision will give more details of this 
solution, which we have been working out off list.

The tunnel issue was central to the choice of the L4S identifier - you 
will find it mentioned all over the ecn-l4s-id draft.

>
>> So far, we've only just started on the basics like whether the feedback approach is even practical.
> 	[SM] Using DSCPs for feed-back is exactly what the "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" ID is all about. I have heard very little comment from your side about its practicability issues (I probably have missed those though). Interesting to cite from that draft:
>
> "7.  Relationship to L4S
>     Traffic flows marked with the NQB DSCP as described in this draft are
>     intended to be compatible with [I-D.ietf-tsvwg-l4s-arch, with the
>     result being that NQB traffic and L4S traffic can share the low-
>     latency queue in an L4S dual-queue node
>     [I-D.ietf-tsvwg-aqm-dualq-coupled].  Compliance with the DualQ
>     coupled AQM requirements is considered sufficient to enable fair
>     allocation of bandwidth between the QB and NQB queues."
>
>
> and
>
>
> "4.1.  End-to-end usage and DSCP Re-marking
>     In contrast to the existing standard DSCPs, many of which are
>     typically only meaningful within a DiffServ Domain (e.g. an AS or an
>     enterprise network), this DSCP is expected to be used end-to-end
>     across the Internet.  Some network operators typically bleach (zero
>     out) the DiffServ field on ingress into their network
>     [Custura][Barik], and in some cases apply their own DSCP for internal
>     usage.  Networks that support the NQB PHB SHOULD preserve the NQB
>     DSCP when forwarding via an interconnect from or to another network.
>     Bleaching the NQB DSCP is not expected to cause harm to default
>     traffic, but it will severely limit the ability to provide NQB
>     treatment end-to-end."
>
>
> And from Greg White directly on the topic of SLAs (https://mailarchive.ietf.org/arch/msg/tsvwg/NrWh_sfCBRcASHirmScjeIAHlFA/)
>
> "When we discussed this concern before, it seemed to me that an SLA might be a good approach (at least in the near term).  So, perhaps we aren’t communicating well.  It is possible that a peering network is already using the value 42 (0b101010) - or for that matter any DSCP that IANA might assign for NQB - in a manner that is inconsistent with NQB, so default bleaching is probably the best near term situation.  For an ISP that wishes to support the NQB PHB, they can validate (and set up SLAs) that identify the NQB traffic from a peer, and treat it per the PHB, whichever DSCP is chosen.  Alternatively, if the ISP does not wish to support the NQB PHB at all, then they can choose to bleach it to Default, or pass it though with Default treatment, whichever they choose."
>
> This is pretty much what you seem to argue for as being impractical, no?

[BB] None of these 3 quotes about NQB are anything to do with DSCP 
feedback, nor reading the DSCP at the receiver.

Perhaps the ambiguity of the word end-to-end is the misunderstanding here.
* When the term end-to-end is used by transport layer people, it means 
from one end-system process to another (and even then it does not imply 
anything about feedback unless feedback is being talked about).
* But, when the word end-to-end is used by network layer people, it 
means that a DSCP survives (possibly remapped) as it traverses the path 
across networks /at the network layer/.

Also NQB is not L4S, which is the subject of this thread.


Bob

>
>
> Best Regards
> 	Sebastian
>
>   
>
>>
>> Bob
>>
>> On 27/03/2021 03:00, C. M. Heard wrote:
>>> On Fri, Mar 26, 2021Sebastian Moeller wrote:
>>> On Mar 26, 2021, at 18:34, De Schepper, Koen wrote:
>>>> My first point is that requiring to set a DiffServ codepoint alone would already support that.
>>>   [SM] Well, sure, but you came to the ECT(1) decision for a reason (a reason I do not agree with, but that is a different topic, I am trying to build you a bridge here how to run your experiments without taking the rest of the internet down), so I am not going to argue about that. My proposal adds an GUARD DSCP for the duration of the EXPERIMENT to allow your measurements in live production networks without negative side-effects for non-participants. This layer of safety can be removed if the experiment has run ist course and measurements in consenting networks has provided data that L4S is safe without the DSCP. At which point the DSCP could be dropped, try doing that if you only use a DSCP as L4S classifier.
>>>
>>> This point sure seems to have been lost in much of the discussion. Note again: GUARD DSCP for the duration of the EXPERIMENT. NOT DSCP instead of ECT(1).
>>>
>>> I've read several comments objecting that using DSCP to distinguish L4S traffic is undeployable end-to-end on the general Internet. Well, according to the intended status of the drafts, L4S is starting life as an EXPERIMENT, and as such is not expected (or at least should not be expected) to be deployed on the general Internet. If the WG's desire is to have L4S deployed on the general Internet as soon as the specs are approved, then the WG should take Steven Blake's advice and deprecrate/obsolete RFC 3168 and change the intended status of the drafts, or else use a mechanism that is backward compatible with RFC 3168, such Jake Holland's proposal to use ECT(1) -> ECT(0) as the L4S congestion signal, leaving the semantics of CE unchanged.
>>>
>>> Mike Heard
>> -- 
>> ________________________________________________________________
>> Bob Briscoe
>> http://bobbriscoe.net/

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