Re: [tsvwg] Default PHB (was Re: Some comments on NQB (part 2))

[[e-mail]]

Hi Brian,

Agreed. If further explanations were useful, these may be added too, I think.

Thanks, Rüdiger

-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter <[e-mail]> 
Gesendet: Freitag, 6. Mai 2022 22:47
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: AW: [tsvwg] Default PHB (was Re: Some comments on NQB (part 2))

Hi Rüdiger,

You are correct that "such as" leaves the option for an additional interpretation. My concern is only that a reader ten years from now might be confused if there appears to be a discrepancy. Perhaps it would be useful to add a brief clarification where the default PHB group is first introduced, something like:

This is a PHB group as defined in [RFC2474]; even though the individual PHBs do not share a queue, they share other attributes and can be handled similarly.

Regards
    Brian Carpenter

On 06-May-22 19:23, [e-mail] wrote:
> Hi Brian,
> 
> In the backbone and at interconnection, Lower Effort and default PHBs Queue Building (QB) and NQB may all be forwarded by the same default BA. None of the PHBs requires an SLA at interconnection gateway.
> 
> At the access gateway:
> Lower Effort and Default may share the same Queue and Lower Effort 
> then
would be treated as "drop me first". To me, there's at least similarity to AF for this subset. NQB is supposed to share the same capacity as Queue Building default PHB, a list of several requirements/constraints relating QB and NQB is specified here: https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-10.html#name-primary-requirements.
> Further, all three PHBs may be overbooked at bottleneck (more traffic than guaranteed minimum capacity) and transport protocols may determine fair sharing of bandwidth.
> 
> At the Wifi AP: NQB may be prioritized. I hope that won't get your 
> core
argument to sink me.
> 
> "a common constraint applying to all PHBs in the set" I think, that holds at least in all network sections which aren't controlled by the receiving host.
> "such as a common queue" I'm not a native speaker. Does "such as" introduce an example of a common constraint or does it state a binding requirement (the common queue) - or would "such as" leave room for both ways of interpretation?
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Brian E Carpenter <[e-mail]>
> Gesendet: Donnerstag, 5. Mai 2022 22:49
> An: Geib, Rüdiger <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Betreff: Re: [tsvwg] Default PHB (was Re: Some comments on NQB (part 
> 2))
> 
> Hi,
> 
> "part of a default PHB group specification"
> 
> As you know, the phrase "PHB group" is formally defined in RFC2474 and I am not sure you are using it in that precise sense:
> 
>      Per-hop Behavior Group: a set of one or more PHBs that can only be
>      meaningfully specified and implemented simultaneously, due to a
>      common constraint applying to all PHBs in the set such as a queue
>      servicing or queue management policy.  Also PHB Group.
> 
> The idea was (as for the AF groups) that a single queueing discipline would apply to the group but with something (such as drop priority) parameterised within the group.
> 
> I think you are describing something a little different here.
> 
> Regards
>      Brian Carpenter
> 
> On 05-May-22 21:29, [e-mail] wrote:
>> Hi Sebastian,
>>
>> A recommendation to forward and remark CS1 traffic received at an 
>> interconnection point is a valid point, and that may become part of a 
>> default
PHB group specification. Relation to other PHBs, and here the aspect of re-marking at interconnection, is another aspect, which requires attention. Careful thought will be required when specifying such a default PHB group.
>>
>> Regards,
>>
>> Ruediger
>>
>> (changed subject, to disambiguate discussion)
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Sebastian Moeller <[e-mail]>
>> Gesendet: Donnerstag, 5. Mai 2022 10:31
>> An: Geib, Rüdiger <[e-mail]>
>> Cc: Black, David <[e-mail]>; [e-mail]
>> Betreff: Re: [tsvwg] Some comments on NQB (part 2)
>>
>> Hi Ruediger,
>>
>>
>> I would like to offer an opinion on the default PHB group 
>> (top-posted, because it seems related, but not directly addressing 
>> any of your points below). These 8 DSCPs seem to have a higher 
>> probability to survive end-to-end and hence could be use to signal 
>> "intent" from source to destination. But if an intermediate node 
>> receives a packet with such a potential e2e DSCP it should be 
>> encouraged to adjust its own DSCP marking if it is prepared to give 
>> special treatment based on "intent". For an easy example the LE PHB 
>> comes to mind if an endpoint marks decDSCP1 but a diffserv domain 
>> uses the top 3 bits of "CS1" for that PHB, the network should be 
>> encouraged to set the appropriate TOS bit and treat such packets 
>> appropriately. Not sure whether other intent-DSCPs will have similar 
>> properties where
> automatically translating makes sense, but at least for LE all "players" along the path have more or less aligned motivations, no?
>>
>> Best Regards
>> 	Sebastian
>>
>>
>>> On May 5, 2022, at 10:16, <[e-mail]> <[e-mail]> wrote:
>>>
>>> David,
>>>
>>> Thanks, I share your view.
>>>
>>> I've read into the DiffServ standards a little, and I propose to specify a new PHB group "Default". It should apply the same DSCP assignment philosophy as the AF specification which specifies 4 PHB groups. Each of the four AF PHB groups can easily classified using DSCP ranges (and each PHB group has 3 assigned 3 DSCPs).
>>>
>>> The commonality I see for PHBs belonging to the Default PHB group is 
>>> that they all SHOULD be classified for and forwarded by default PHB 
>>> at interconnection nodes and within the backbone. If received by 
>>> suitable DSCPs
> in range 0-7 (as an example, could be a subset too), re-marking SHOULD NOT apply at interconnection gateways.
>>>
>>> Rules for the resources configured of PHBs of the Default PHB group need to be defined (but currently available drafts do so quite well, I think). Apart from using the same capacity as default PHB, I think, these PHBs further all have in common, that resources provided may be overbooked at bottlenecks.
>>>
>>> Specifying a new Default PHB group shouldn't become part of the NQB spec, but NQB should be made part of the latter PHB group.
>>>
>>> Regards,
>>>
>>> Ruediger
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: tsvwg <[e-mail]> Im Auftrag von Black, David
>>> Gesendet: Mittwoch, 4. Mai 2022 22:08
>>> An: Greg White <[e-mail]>
>>> Cc: [e-mail]
>>> Betreff: Re: [tsvwg] Some comments on NQB (part 2)
>>>
>>> <WG_Chair_Hat=OFF>
>>> With apologies for resurrecting some topics that have been more or less settled in the past, I am still bothered by the recommendation of two default DSCPs for NQB.
>>>
>>> The question that I can't satisfactorily answer is: If NQB traffic 
>>> is
supposed to be carried as a peer to Default traffic, why are we instructing end systems to use DSCP 45 for originated NQB traffic on all networks?
>>>
>>> The answers to that question seem to boil down to (with apologies 
>>> for
the crass bluntness) necessity of allowing the Legacy WiFi "tail" to wag the Internet QoS "dog".
>>>
>>> Would someone (Greg?) provide a reminder of what is it about legacy WiFi that requires this approach, please ...
>>> </WG_Chair_Hat>
>>>
>>> Thanks, --David
>>>
>>> -----Original Message-----
>>> From: tsvwg <[e-mail]> On Behalf Of Greg White
>>> Sent: Friday, April 29, 2022 3:34 PM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Re: [tsvwg] Some comments on NQB (part 2)
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> Thanks Ruediger.
>>>
>>> Glad to hear that we are converging, though it wasn't clear to me which version of the new text you preferred.  For now, I'll stick with the version that I'd sent on April 4, but let me know if I've misunderstood you.
>>> Hopefully others find this text change acceptable.
>>>
>>> N.B. I don't have any issue with your bigger picture idea, but it is beyond the scope of the NQB draft.   So, if you want to pursue documenting
> it in an RFC, it probably should be proposed separately.
>>>
>>> So, for the NQB draft, are folks ok with replacing:
>>>
>>> To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.
>>> To facilitate the default treatment of NQB traffic in backbones and 
>>> core networks discussed in the previous section (where IP Precedence 
>>> may be
> deployed), networks that support NQB SHOULD NOT use the value 45 for NQB at network interconnects unless that usage is explicitly documented in the TCA (Traffic Conditioning Agreement, see [RFC2475]) for that interconnection.
>>> Rather, networks SHOULD remap NQB traffic to DSCP 5 prior to interconnection, unless agreed otherwise between the interconnecting partners.
>>> To be clear, interconnecting networks are not precluded from 
>>> negotiating (via an SLA, TCA, or some other agreement) a different 
>>> DSCP to use to
signal NQB across an interconnect.
>>> Additionally, the fact that this PHB is intended for end-to-end 
>>> usage
does not preclude networks from mapping the NQB DSCP to a value other than 45 or 5 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.
>>>
>>>
>>> With [notes in square brackets added to help those trying to compare against the above]:
>>>
>>> To support NQB, networks MUST preserve a DSCP marking distinction between NQB traffic and Default traffic when forwarding via an interconnect from or to another network.    [no change]
>>> Networks that support NQB SHOULD support the ability to re-mark NQB traffic prior to such an interconnection.    [new recommendation]
>>> It is RECOMMENDED that interconnecting networks negotiate the use of the DSCP value 45 to indicate NQB traffic across their interconnections (thus avoiding the need to re-mark traffic), however, local DSCP usage by either network could require the use of a different value.   [new recommendation]
>>> To be clear, interconnecting networks are not precluded from 
>>> negotiating (via an SLA, TCA, or some other agreement) a different 
>>> DSCP than 45 to
> use to mark NQB traffic across an interconnect.  [only editorial 
> change] In situations where negotiation of a DSCP between 
> interconnection partners is infeasible, networks that support NQB 
> SHOULD NOT use the value 45 for NQB at network interconnects, but 
> rather SHOULD re-mark NQB traffic to DSCP 5 prior to interconnection.  
> [limited the applicability of this recommendation] This is intended to 
> facilitate the default treatment of NQB
traffic in backbones and core networks discussed in the previous section (where it is possible that IP Precedence may still be deployed).  [only editorial change] Additionally, the fact that this PHB is intended for end-to-end usage does not preclude networks from mapping the NQB DSCP to a value other than 45 or 5 for internal usage, as long as the appropriate NQB DSCP is restored when forwarding to another network.  [no change]
>>>
>>>
>>> In addition to Ruediger, I'd like to specifically hear from David Black and Gorry, since two of the original sentences came from David, and Gorry was the OP raising a concern about those sentences.
>>>
>>>
>>> -Greg
>>>
>>>
>>>
>>> On 4/29/22, 3:27 AM, "[e-mail]" <[e-mail]> wrote:
>>>
>>>      Hi Greg,
>>>
>>>      Thanks. My bigger picture: RFC 8100 is intended to support interconnection policies like:
>>>
>>>      If DSCP in range <0-7>      # with a negotiated SLA, different ranges may apply for different backbone PHBs and Codepoint rewrites...
>>>          then PHB=default
>>>
>>>      To me, no SLA negotiation is necessary if forwarding expected 
>>> by a
> backbone is "default". In addition, I prefer the interconnection QoS policy to be as simple as possible, if no QoS SLA is negotiated:
>>>
>>>      (PHB=default)
>>>      If DSCP in range <8-63>
>>>          set DSCP=000 000
>>>
>>>      I appreciate your suggested text which allows that; no DSCP 45 
>>> traffic should be received at interconnections without negotiated 
>>> QoS SLA,
if the above is deployed. If DiffServ Standards were changed to support the above, 8 DSCP are available for PHBs whose differentiating support is most useful and can be decided upon at the access. I think that would be beneficial for
>>>      - Lower Effort PHB
>>>      - L4S / NQB (I think, any DSCP can be rewritten at access and may be at a home gateway, and if a standard proposes a value like 45, the better).
>>>
>>>      What I suggest to avoid at interconnection (and will not 
>>> deploy,
where I'm in charge) is (e.g.):
>>>
>>>      If <InterconnectionPartnerX> then
>>>          If DSCP <a>
>>>              then PHB=default
>>>          If DSCP <b>
>>>              then PHB=default AND set DSCP=000 001
>>>          If DSCP <c>
>>>              then PHB=EF
>>>          If DSCP <d>
>>>              then PHB=AF4 AND set DSCP=001 010
>>>          If DSCP <e>
>>>              then PHB=AF4 AND set DSCP=001 100
>>>          If DSCP <f>
>>>              then PHB=default AND set DSCP=000 101
>>>            ....
>>>          If <no match>
>>>              then PHB=default AND set DSCP=000 000
>>>
>>>      Rather than individual per interconnection partner combined 
>>> with
per DSCP policies at interconnection, I'm looking for simplistic, easily comprehensible and to the extent possible generic Behaviour Aggregate classification. That holds for (range based DSCP) remarking at interconnection too.
>>>
>>>      Regards,
>>>
>>>      Ruediger
>>>
>>>
>>>
>>>
>>>
>>>      -----Ursprüngliche Nachricht-----
>>>      Von: Greg White <[e-mail]>
>>>      Gesendet: Freitag, 29. April 2022 01:12
>>>      An: Geib, Rüdiger <[e-mail]>
>>>      Cc: [e-mail]
>>>      Betreff: Re: [tsvwg] Some comments on NQB (part 2)
>>>
>>>      Hi Ruediger,
>>>
>>>      Thanks for responding.   See my responses [GW] below.
>>>
>>>      -Greg
>>>
>>>
>>>      On 4/26/22, 8:14 AM, "[e-mail]" <[e-mail]> wrote:
>>>
>>>          Greg,
>>>
>>>          Sorry for the late response.
>>>
>>>          <snip>
>>>
>>>          You wrote:
>>>          What I offered for consideration below was that the [DSCP] value 45 be recommended across interconnections in cases where the two interconnecting partners are NQB-aware and they negotiate DSCP markings.
>>>
>>>          RG: To me, that's an additional concept. My take was, NQB 
>>> doesn't require more than default transport in the backbone and at 
>>> interconnection. If the later holds, negotiation of NQB is no issue 
>>> to me, but an
appropriately picked DSCP is important (it should unambiguously indicate "default forwarding" at interconnection).
>>>          If a QoS SLA is negotiated, in principle any negotiated 
>>> DSCP
does (it is well known that I prefer RFC 8100 at wholesale and interconnection interfaces, as this simplifies deployment and operation).
>>>
>>>      [GW] It seems to me that there isn't such a thing as a DSCP 
>>> (other
> than possibly 0) that unambiguously indicates default forwarding at 
> interconnection.  I quickly re-read RFC8100 and also don't see mention 
> of it
there (it refers to DSCP=0 as being default and seems to recommend that any traffic classified into the Default / Elastic Treatment Aggregate be re-marked to 0). As I understand it, the practice of aggregating traffic based on the IPP bits (top 3 bits) is not universal. If I'm right in that, then it seems that recommending NQB-aware networks re-mark NQB traffic to 5 and not use 45 at *all* interconnections might be unnecessary (and it was apparently concerning to some).
>>>      In my post on April 4: 
>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ts
>>> vwg/PKTrfNdTCEXmwoovSkqec6cOJZc/__;!!LpKI!mzr4n4KDAty5Aq0a1tG2B89wGf
>>> Rac3ylHv0FS_U75V-j47XXXS_4VgGjl_ncHFL_4IO4sSMU0X0akSepO1Y$ 
>>> [mailarchive[.]ietf[.]org] in response to Gorry's concerns, I had
suggested softening this to (paraphrasing here):
>>>      - If negotiating a DSCP to use at interconnection, recommend 
>>> 45,
but the parties can negotiate whichever value they want.
>>>      - If negotiation isn't possible, the sending network SHOULD NOT use 45, and instead SHOULD use 5.
>>>      What about this do you not like?  It seems to me that you're saying that you wouldn't negotiate a DSCP for NQB.  So, based on the proposed text, your interconnection partners SHOULD use 5.
>>>      Would it make you happier if the first statement were replaced with:
>>>      - If negotiating a DSCP to use at interconnection, recommend 
>>> the
use of either 5 or 45, but the parties can negotiate whichever value they want.
>>>
>>>
>>>
>>>          You wrote:
>>>          The data from Ana Custura and Gorry indicates that, unless 
>>> something changes in regards to bleaching of the upper 3 bits by 
>>> some networks, any future assignments of the values 13, 21, 29, 37, 
>>> 53, 61 would do well to keep in mind that any traffic so marked 
>>> could end up being aggregated with NQB traffic.  That said, this 
>>> sort of bleaching is non-compliant with the definition of the DSCP 
>>> field, and is already problematic for
EF, VA, and all of the CS codepoints (which aggregate in incompatible ways), so (as was commented in the last meeting) we may want to consider identifying the routers that continue to do this, and try to work with the associated network operators to change the behavior.
>>>
>>>          RG: I'd appreciate a concise reference for your claim "this sort of bleaching is non-compliant with the definition of the DSCP field".
>>>
>>>      [GW] I probably didn't choose my words as carefully as I could 
>>> have, and I made that statement (without doing the appropriate 
>>> research) based on comments others had made.  RFC2474 Section 3 
>>> seems to imply to me
that selectively bleaching certain bits of the field is not what was intended, but it does allow that "Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service."  So, I don’t see any requirement statement that is violated.
>>>
>>>
>>>          RG: If you are interested, I can sketch examples where 
>>> single sided changes were made to well  negotiated EF deployments 
>>> and the interesting consequences caused by that. That's not what 
>>> mean by "problematic
for EF", it rather shows what happens if a QoS design isn't well agreed with all parties responsible for QoS aware network sections and policy points in an operational end-to-end production chain.
>>>
>>>          Regards,
>>>
>>>          Ruediger
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>