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

[Sebastian Moeller <[e-mail]>]

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

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

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


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/