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

[Sebastian Moeller <[e-mail]>]

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



> 
> 
> 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...
>> 
>> 
>>> 
>>> 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...
>> 
>> 	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...
>> 
>>> 
>>>>> 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).
>> 
>>>>> 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.
>> 	[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.
>> 	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?
>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>> 
>> 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/
>