Re: [tsvwg] [on-list again] [offlist] L4S DSCP (was: L4S drafts: Next Steps)

[Bob Briscoe <[e-mail]>]

Sebastian,

I have helped you read the specs below. Personally I don't think anyone 
else is under the same misapprehensions as you about what the specs are 
saying, so I don't think this ought to be on the list, but you insisted, 
so pls see inline [BB]...


On 31/03/2021 08:57, Sebastian Moeller wrote:
> Dear Bob,
>
>
> see more below, prefixed [SM]. Since your post did not contain anything of sensitive nature, I opted for moving this back on list.
>
>
>> On Mar 31, 2021, at 00:24, Bob Briscoe <[e-mail]> wrote:
>>
>> Sebastian,
>>
>> I understand differences of opinion are valid. But all your three points were off-topic (and incorrect, as it turns out).
> [SM] I understand your mail, as a tacit acknowledgment that you accept my arguments as you did NOT respond to my arguments or cited facts in any substantial fashion.
>
> 	You are certainly free to argue that my points are incorrect, but then it is incumbent on you to actually show, preferably by citing facts, how you came to that assessment.
> Otherwise it just reduces your argument to an unsubstantiated statement of opinion. Which I add, says a lot about you, but little about the question at hand.
> 	Now, I understand what and why you are doing this, you are trying to shift the discussion away from points where your argument don't hold water. This is a time-honored debating strategy, used when the goal is to "score points" rather than as a discussion strategy that aims at actually solving problems by findig compromises (where they are possible).
> 	So let me get back to the question, what in the guard DSCP proposal is unfeasible, EXCEPT for not fulfilling your desire to force-recruit all internet users at the leisure of the L4S experiments participants? So, please tell me, why you consider requiring an explicit opt-in by those that will have to deal with the consequences (both positive and negative) as being out of the question? I can not help but repeating, that if you yourself consider L4S benefits so weak, that they will not survive such a common sense requirement, it might be time to drop the IDs.
>
> Best Regards
> 	Sebastian
>
[BB] Insults ignored.
more...

>
>>
>> Bob
>>
>> On 30/03/2021 11:46, Sebastian Moeller wrote:
>>> Bob,
>>>
>>>
>>>
>>>> On Mar 30, 2021, at 10:21, Bob Briscoe <[e-mail]> wrote:
>>>>
>>>> Sebastian,
>>>>
>>>> If you are not adding to a thread, please consider remaining silent.
>>> 	[SM] This is a tad impolite; in a discussion every opinion voiced (with sufficient civility) has the same right to be expressed. Just as I a not the arbiter on whether your posts "add" to a thread you are not the arbiter for mine. The fact that I have to explicitly write such self-evident and obvious facts is a sad fact in itself.
>>>
>>>
>>>> I've corrected all your misunderstandings inline (I ignored the one that is just a restatement of an opinion), tagged [BB].
>>> 	[SM] Bob, when I come to different conclusions from evaluation the same data as you, that does not automatically mean that I am misunderstanding something. there could be different reasonable interpretations of the data, or, god forbid, you might be wrong...

[BB] Insults ignored
more...

>>>
>>>
>>>> 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.
>>> 	[SM] Yet, if you read my proposal you would understand that a such modified L4S would very much contain a guard DSCP and hence L4S-OPs should be amended in that way. We can argue about the merits of my proposal and in the end reject it, but from my position and perspective adding the whole DSCP part to the OPs ID makes inherent sense. Also, an operator might want to use DSCPs for better isolation between network nodes with and without rfc3168, even if such a DSCP is not in the other L4S drafts\. And in fact most of the remedies/work-arounds in L4S-ops are not in the other drafts either.
>>> 	I can't shake the feeling, your are not actually trying to engage with my arguments, but rather try to swat them down with as little effort as possible...

[BB] Insults ignored.
more...

>>>
>>> 	But I understand you as saying that you categorically reject adding any DSCP requirement to the L4S drafts whether transiently for the duration of the experiment or permanently as part of the signaling, and based on that position you see no use for adding this to the OPs draft? If that is the case you might have started out with actually clearing up that assumption first, and then as a consequence rejecting discussing DSCPs as part of the OPs draft...

[BB] Your proposal is not what the l4sops draft is about. Last May the 
chairs confirmed that the WG would move forward with L4S work on the 
basis of the currently documented L4S identifier. The l4sops draft has 
just been adopted with a clear statement of scope, concerning the L4S 
identifier and traffic that shares a queue where there is an RFC3168 AQM.

Given that WG decision, we shouldn't even be engaging in discussions of 
alternative identifiers on the list. But I recently decided to engage in 
the discussions about a guard DSCP because I couldn't see how the scheme 
could possibly solve the CE ambiguity problem, and I detected that some 
people thought it could.

I engaged first with Jonathan about his guard DSCP proposal, not because 
he's any more important than you. but because the description of even 
one scheme was confusing everyone, let alone different people chipping 
in with slight differences. I'll discuss yours once discussion on his 
has converged.

>>>>>> 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.
>>> 	[SM] The thing is, there is no generic robust and reliable solution, neither off-list, nor on-list.... as I said, tunnels are only show-stoppers when L4S has no issues with them, and where it does it becomes magically manageable (somewhen in the future*).
>>>
>>>> The tunnel issue was central to the choice of the L4S identifier - you will find it mentioned all over the ecn-l4s-id draft.
>>> 	[SM] IMHO at the expected main deployment points, at the DOCSIS-ISP<-> end-user edge tunneling will simply be a minor issue that could for the first iteration of L4S be ignored, and for deeper bottlenecks like transit-links L4S simply is not suited (due to the ungodly increase in RTT-bias and bias against non-L4S traffic).

[BB] The WG has already decided to take into account factors like 
tunnelling in its choice of identifier.

As a for instance, the last operator I worked for was an ISP itself, but 
it also wholesaled ISP services to retail ISPs. When I left 6 years ago, 
60% of end-customers reached their ISP via an L2TP tunnel over this 
wholesaler.

You will see a large number of encapsulation protocols in rfc7059. When 
I took on editorship of draft-ietf-tsvwg-rfc6040update-shim, in order to 
make the scope manageable, I asked the IETF intarea to tell me which 
tunnel protocols currently in active use or development involve a shim 
under an outer IP header. That resulted in this cut-down list:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-13#section-6
That's doesn't include straightforward IP in IP.

I already knew tunnels and encapsulations are everywhere in the 
Internet. Both between 2 points within the network, and between 
end-systems. Having worked with the maintainers of each of those 
protocols, I discovered even more types of tunnel I didn't even know 
about, that are in widespread use.


>>>
>>>>>> 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] You are talking about SLAs between networks. The reason I moved 
this offlist was because stuff like this has got nothing to do with the 
point at hand - deploying DSCP receiving logic in the transport 
protocols of receiving hosts all around the Internet.


>>>> [BB] None of these 3 quotes about NQB are anything to do with DSCP feedback, nor reading the DSCP at the receiver.
>>> 	[SM] Well, these are about enabling NQB end to end, which would be e necessary condition for using DSCPs in the context I proposed, these quotes indicate that the sponsors of the NQB draft see this as feasible enough.

[BB] See my explanation about the ambiguity of end-to-end between L3 
people and L4 people.

>>> 	DSCP feedback is really a question about setting DSCPs and reading the DSCP at the reciever should be no issue, given that most protocols either live inside the kernel (where you just need to ask nicely) or in userspace, where raw_sockets seem to offer all the acces you might ever need.
>>> 	Honestly, Bob, these to questions indicate that you have not even started to look into how feasible a guard DSCP would be, but just trying to muddy the waters with under-researched objections, mostly based on lack of knowledge, no?

[BB] Insults ignored.

This is not about whether the DSCP /can/ be read at the receiver.

ECN deployment was painstakingly slow mainly because it required new 
code to be deployed in 3 places: at senders, receivers and at the 
bottleneck. L4S requires updated code in 2 places (at the sender and in 
the network), which makes deployment difficult enough. Requiring 
receivers to have updated logic as well would knock back deployment by 
decades.

Example: an ISP with 20 million users, each with an average of 8 devices 
(160million devices). Imagine the ISP deploys L4S technology at its 
bottlenecks. You deploy L4S on your host. But, even once 10,000 hosts on 
that ISP have upgraded to L4S, your L4S device can still see 159,990,000 
non-L4S devices over that ISP, so the chances of you being able to use 
L4S with anyone else are tiny. In contrast, when there is no dependency 
on the receiver, when you choose that ISP and you choose to upgrade to 
L4S yourself, you get to use it all the time.


(AccECN requires changes at the receiver, and L4S depends on AccECN if 
it is to be used over TCP. But that doesn't hold back L4S deployment 
over other transports, such as RTP/RTCP or QUIC which have suitable ECN 
feedback logic at the receiver already.)


>>>
>>>> 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/.
>>> 	[SM] I thougth that it was clear that I was talking about the NECESSARY condition of DSCPs traversing fully between the end-nodes. Reading them there and constructing a feed-back loop out of that signal, is something I propose, well within the spirit of how L4S tackles issues, to formulate as a requirement for L4S-compatible protocols.
>>>
>>>
>>>> Also NQB is not L4S, which is the subject of this thread.
>>> 	[SM] Reading the relevant CableLabs DOCSIS standards and the Low Latency DOCSIS White paper (where you were one of the co-authors) clearly indicates, that NQB is very much intended as the canonical DSCP in DOCSIS networks to request scheduling in the L4S-LL (or on DOCSISese immediate AQM). For all means and purposes, NQB seems to be the "missing" DSCP, even though it is not explicitly acknowledged as such in the L4S IDs yet. But again, ID text can (and in this case should) be changed, arguing that NQB is not L4S is technically true, but irrelevant. I understand you know this, and frankly am getting a bit tired of any discussion with you turning into a debate.

[BB] Insults ignored...

If you read the specs, I wouldn't have to spend all this 1-1 tutorial 
time with you telling you what the specs say.
Have you read 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-5.4.1.1 
?
Have you read the first four paras of Section 7.7.5 of the DOCSIS MULPI 
spec? https://www.cablelabs.com/specifications/CM-SP-MULPIv4.0

And as well as looking for some evil conspiracy about a "missing" DSCP 
in L4S, have you considered that the words in the specs might just mean 
exactly what they say?

It is very relevant that NQB is not L4S. They are certainly 
complementary - for instance DOCSIS shows that they can share the same 
queue. But they are no more complementary than the Expedited Forwarding 
(EF) DSCP and L4S. And NQB certainly cannot be described as /being/ L4S.
* L4S traffic gets its low latency from its congestion control response, 
hence the use of the ECN field
* NQB traffic gets its low latency from light and non-bursty use of 
capacity, but it is unresponsive if congestion does occur, hence the use 
of a DSCP.

* L4S traffic carries ECT(1) in the ECN field, but typically the default 
(zero) DSCP (Best Efforts).
* NQB traffic carries the NQB DSCP and Not-ECT in the ECN field (given 
it is typically unresponsive).

Both identifiers on the same packet are not expected, but it is 
perfectly possible that traffic is both light and responsive. And in 
systems where they share the same queue (like DOCSIS) it anyway doesn't 
matter which classifier is applied first.

draft-ietf-tsvwg-ecn-l4s-id-11#section-5.4.1.1 gives some examples of 
other identifiers that could be classified into the same queue as L4S:
   o EF, Voice Admit, and other similar PHBs
   o DNS, ARP
But this doesn't mean that L4S /is/ EF.

At the risk of patronizing you, let me explain that industry-specific 
standards bodies (like DOCSIS, Broadband Forum, 3GPP, etc) pull together 
component standards (often from the IETF) into system standards. 
Operators of those network technologies can then expect to be able to 
purchase the interoperating parts of these systems from their equipment 
vendors, without each having to define their own systems and their own 
testing regimes.

DOCSIS /uses/ L4S and NQB, just as it uses Ethernet and DHCP. They are 
all items in the recipe that makes up DOCSIS.
Similarly a Salade Nicoise is not a conspiracy between tuna, french 
beans and eggs. They are just /used in/ the recipe.

* L4S was released 2 years before services like NQB were thought of.
* Greg White was working on a new low latency service for DOCSIS. It was 
intended for non-queue-building traffic (lower case, originally just his 
description of the type of traffic). When he read about L4S, he realized 
his traffic could share a queue with L4S to reduce complexity.
* Thomas Fossati and others had got significant interest from the 3GPP 
in a similar low latency service, originally called LoLa. Given its 
success in 3GPP, he (and others) described it in a draft for the IETF: 
draft-fossati-tsvwg-lola-00
* NQB and LoLa eventually came together in the NQB proposal.
* In future, it is possible the 3GPP might put some of its low latency 
services (identified by DSCPs) together with L4S in the same queue. This 
doesn't make these DSCPs part of L4S. Just as eggs are not part of tuna.


>>>
>>> Again, here is the text from the NQB draft:
>>> "9.  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]. "
>>>
>>> If you do not think that text will make NQB the missing L4S DSCP, then I would expect you object to that paragraph immediately. Just because the L4S DSCP is not explicitly introduced and mentioned in the core L4S IDs does not change the fact, that if the NQB draft succeeds with its goal, NQB will be the de facto DSCP for L4S, no?
>>> I often wonder about the level of language lawyering happening in drafts and discussions, I would assume what matters more is what happens/is going to happen in reality than any amount of word smithing put into one draft, but what do I know.

[BB] L4S traffic doesn't have an NQB DSCP. And NQB traffic doesn't have 
ECT(1) in the ECN field. There is no missing DSCP on L4S packets. They 
are just two types of traffic that can coexist in the same queue. That's 
precisely what this text says. Please read what is in the lines of text. 
There is nothing written between the lines.



Bob

>>>
>>>
>>>
>>> Sebastian
>>>
>>>
>>> *) Or rather not, as the failed attempts at fixing up dualQ's RTT-bias inflation and L4S' general incompatibility with rfc3168 AQMs in TCP Prague demonstrated. All things promised in draft and on list and things that petered out falling way short of the promises and what should be required.
>>>
>>>
>>>
>>>> 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/
>>>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>

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