Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

[Gorry Fairhurst <[e-mail]>]

On 17/05/2022 13:08, [e-mail] wrote:
> Hi Gorry,
>
> I've introduced marks [GF] and my replies by [RG].
>
> Regards, Ruediger
>
>> One step helping to find consensus may be to accept treatment of "Unknown/Improperly Mapped DSCPs"
>> as specified by the latest RFC providing text on that:
>>
>> https://datatracker.ietf.org/doc/html/rfc3260#section-6
> [GF] True. However, it seems to me that there are multiple ways that DSCPs can be used and the IETF RFCs are not (yet) consistent. I'm pretty sure that in publishing RFC3260, the group was at that time reflecting work based on ITU specs, and they seem consistent with your proposal. I recall also that this style of spec was not overwhelmingly welcomed, so I suspect this can't be taken as the only way.
>
> [RG] RFC3260 reads explicit to me:
>     Therefore, the statement in RFC 2474 will be clarified to indicate
>     that it is not intended to apply at the ingress traffic conditioning
>     function at a DS-ingress node, and cross reference RFC 2475 for that
>     case.
>
> [RG] RFC 2475
>       "Ingress nodes must condition all other inbound traffic to ensure
>        that the DS codepoints are acceptable; packets found to have
>        unacceptable codepoints ... must have their DS codepoints
>        modified to acceptable values before being forwarded.
>
> [RG] The acknowledgements of RFC 3260 don't point to ITU, neither do the references. Please provide a reference to enable me figuring out which ITU-T work RFC 3260 is related to. I'm not aware of ITU-T standards of that time (2002) specifying IP provider interconnections.
> I've looked into https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.1291-200405-I!!PDF-E&type=items , but it doesn't contain a reference to RFC3260 (and also doesn't discuss the issues mentioned, I think).
You are correct, so sorry, and I should not have headed that direction, 
because it didn't help suggest a codepoint usage.
> <snip>
>> Then there may be a second discussion, which may impact markings desired at interconnection:
>> - there may be network providers supporting DiffServ PHBs differing from "default" for consumer traffic only at Access Nodes.
>> - there are network providers supporting DiffServ PHBs differing from "default" for consumer traffic throughout their backbone.
>>
>> Recommendations given by IETF should respect existing deployments.
>>
>> My perception is that NQB will be forwarded marked decDSCP 5 and
>> default PHB within Deutsche Telekom's backbone and should be received
>> by that DSCP at interconnection as a default (i.e. without negotiated
>> SLA). The PHB assigned for traffic from Access Node to Home Gateway
>> and the DSCP used may follow IETF specifications for that section,
> [GF] That might make sense also to me for a network that does condition to an SLA and remarks.
>
>> if NQB is supported (I'd expect this to include a re-write to decDSCP 45,
>> if recommended by IETF). Traffic received from consumers will face a
>> DSCP rewrite at Access Nodes, and there decDSCP 5 is the only
> < alternative to decDSCP 0 for traffic classified as NQB.
>
> [GF] I see, on the one hand, if the network bleached, then it would become
> DSCP 0.
>
> [GF] On the other hand, if the traffic was marked as DSCP dec 45, and the
> network that did not condition, then it would anyway travel with a DSCP 45.
>
> [GF] So, this is what I arrived at.....
>
> [GF] There are networks that do condition the DSCP: If they were to prefer to
> keep both DSCP 45 or DSCP 5 marking with NQB, they could.  I see the
> policy could choose to remark to DSCP 5 if they support NQB and DSCP 0
> if they do not. I can see an argument that some operators could prefer
> to always remark to DSCP 5 - in the spirit of what I understand by
> RFC3260 - and that would then suggest they remark to DSCP45 on egress
> unless peering with an operator only using DSCP 5. If a domain
> supporting NQB peers with a SLA requiring DSCP 5, they would need to
> ensure traffic was marked to DSCP 5, to gain NQB behaviour.
>
> [GF] There are also networks that do not condition the DSCP : If that is the
> sort of network is used along an entire path, then  DSCP 45 or DSCP 5
> would be usable end-to-end. DSCP 45 seems more applicable to end systems.
>
> [RG] This section discusses treatment of traffic received from the consumer
> domain and forwarding across domain boundaries - to have a defined
> starting point for my comment.
> The access node receives a DSCP from a never-to-be-updated WiFi AP,
> which is part of WiFi AC-VI. I recall dDoS attacks originating from
> never-to-be-updated IoT gear connected to such WiFi APs and I think,
> forwarding this traffic with a DSCP classified for AC_VI  requires
> a fair relation of trust. Similar, forwarding such traffic with such a DSCP
> across an interconnection requires trust. I don't recommend to
> configure an interconnection node to forward traffic with DSCPs, which
> the sending domain wouldn't like to receive with that DSCP (unless
> an SLA specifies differently).
>
> [RG] From a security point of view, picking a DSCP which demands
> default transport in carrier network, like decDSCP 5
> seems to be a better choice than a DSCP identifying AC_VI.
>
GF:  Clearly an operator supporting better than default PHBs needs to be 
allowed to condition to protect use of these PHBs. Remarking 
unauthorised use of a DSCP associated with a non-default PHB can provide 
this protection.

However, remarking "unknown" DSCP to default (0x00) will result in 
ossification of the set of useful future codepoints - the alternative 
would be to assign traffic with an "unknown" DSCP to the default PHB.

I agree also that forwarding a packet with a DSCP that uses a 
high-numbered value can have implications when equipment interprets the 
former ToS precedence field. It also seems to me quite reasonable for an 
operator to ensure DSCPs are acceptable to the customers they serve, we 
shouldn't prevent remarking to achieve that. I would like to hear 
clearly whether the group thinks we ought to constrain the use of DSCP 
45 to avoid this?

>> As has been written, I favour rather simple Behaviour Aggregate classification
>> at interconnection and within backbone networks, always based on ranges
>> of DSCPs. That includes re-writes, which should follow a small and long term
>> stable set of generic rules applicable for Behaviour Aggregates (unless a QoS
>> interconnection SLA agrees something different).
> [GF] I see we have an issue as a working group in how the DSCP 5 is
> characterised in a standard. If we specifically allocate this as the
> only way for Internet-wide use for NQB, that will effectively reduce our
> ability to assign any other DSCP end-to-end that sets the same upper
> three bits. To me, that hints at a benefit in more caution - and I do
> wonder if we should explicitly say that DSCP 5 is an aggregate for any
> codepoint of the style of NQB ... that would mean careful wording, but
> it would allow future assignment of other DSCPs that also set the first
> 3 bits to the same pattern.
>
> [RG] I'd hope there aren't many different PHBs which
> - cope well with default transport within operator backbone and
>    at interconnection
> - and require distinct differentiated treatment at access nodes and
>    within home networks
> because scalability of VoQ based router architectures is limited with
> complex QoS designs. The number of the above PHBs should remain
> small (a default queue and a queue supporting NQB/L4S currently
> looks desirable to me).
>
> [ End of comments [RG] ]
>
GF: I expect these are food points to consider if the group decides on 
an update to tyhe DS spec.

Gorry

>> -----Ursprüngliche Nachricht-----
>> Von: Greg White <[e-mail]>
>> Gesendet: Donnerstag, 12. Mai 2022 01:39
>> An: Geib, Rüdiger <[e-mail]>
>> Cc: [e-mail]
>> Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy
>>
>> Hi Ruediger,
>>
>> Ok, apologies for misunderstanding your earlier message.
>>
>> My interpretation of where we stand on this is:
>>
>> I'd suggested text on April 4, where it is recommended to negotiate the use of 45 at interconnection, but where negotiation isn't possible, use 5.
>> RG agreed with that text.
>> GF wasn't super happy with it and would prefer the value 45 when negotiation isn't possible, but hasn't responded to RG and GW JL agreed with GF, but seems to be more concerned about direct peering as opposed to transit.
>>
>> Is that summary accurate?  Any suggestions on how we reach rough consensus on this point?
>>
>>
>> Below I'll try to answer your technical questions. If I've missed some, misunderstood them, or this is unclear, please let me know.
>>
>> For network operators that use DOCSIS access network equipment, the option definitely exists to classify upstream traffic based on L2,L3,L4 criteria (including e.g. DSCP 45) into traffic aggregates and then to re-mark such a traffic aggregate at the access network to the value 5.  Similarly downstream traffic can be classified (e.g. using DSCP 5) and then re-marked to 45 at the access network.   In the case of LLD, the Queue Protection function can also serve as a policy enforcement function of sorts, since traffic redirected to the Classic queue would get the DSCP re-marking appropriate for that queue (e.g. DSCP 0).  In cases where the operator provides the gateway device (this isn't universal, there is also no lock-in in the US and Canada), they could also implement more sophisticated policy enforcement and marking if they choose. Whether network operators choose to take this approach is entirely up to them.  They could choose to use a different, local-use, code point (or 45) in their core network, and re-mark at interconnection.  They could negotiate with their interconnection partner to use 45 end-to-end if they choose. This is entirely up to them, and whatever we put in an IETF draft/RFC is (in my view) simply a suggestion. I don't think that network operators are unwilling to perform re-marking, but if it isn't needed then I assume (and one has stated) they'd rather not. If ISP X and Application Provider Y directly interconnect, they can choose whichever DSCP they want, and if it is convenient to use 45, then why not?
>>
>> You'd asked whether cable ISPs support DiffServ, and I am not exactly sure how to answer that question, because I don't know what you mean by it.  If you are asking, do cable ISPs implement the IETF defined DiffServ PHBs (CSx, AFxx, EF, VA, LE) and use the recommended IANA DSCPs, I think the answer to that is generally no. If you are asking, do cable ISPs use DSCP within their network for differentiated treatment of traffic, I think the answer is generally yes.  If you are asking, do cable ISPs differentiate inbound traffic at interconnections based on DSCP (with or without an SLA), I think the answer is that most likely some do.  I hope that helps somewhat.  If not, maybe you can try to clarify what specifically you are asking, but I can't guarantee to know the answer, and I am almost certain that the answer will vary depending on which ISP it is.
>>
>> -Greg
>>
>>
>>
>>
>>
>>
>>
>> On 5/9/22, 1:52 AM, "[e-mail]" <[e-mail]> wrote:
>>
>>       Hi Greg,
>>
>>       I've never asked for decDSCP 5 end-to-end. Please stop this way of arguing. To repeat:
>>       - IF there's no negotiated SLA at interconnection
>>       - AND standard conforming NQB traffic is sent to DT
>>       - THEN mark by decDSCP 5.
>>
>>       That's it. If DT intends to support NQB for traffic received that way, the DSCP useful to give priority to NQB over Best Effort traffic at WiFi APs, decDSCP 45, will be set by the Access-Policy Point (valid for fixed and mobile networks).
>>
>>       I'd think IETF best should implement standards, which follow operational practice of carriers:
>>       - simple and generic (to operate and configure)
>>       - allow for simple and generic aggregation at interconnection gateways and within backbones
>>
>>       Please answer the technical questions I've been asking you. I don't know any detail about the DiffServ related architecture of and whether DiffServ is supported by the backbones of these operators you claim to talk for. Greg, you continue to go at length arguing about DT's DiffServ deployment, never providing any reference for your beliefs. Please stop that (or start to provide references supporting your claims).
>>
>>       I'd be happy to technically understand why assigning decDSCP 45 and recommendation for use at interconnection gateways, especially those without an SLA,  should be done by IETF. So far, I just heard that some operators, who are not known, may like that. Well, you've heard that others don't (at least one is known).
>>
>>       I don't share your interpretation RFCs 2474 & 2475 and RFC2597, as you so far failed to support your argumentation by any reference.
>>
>>       Regards, Ruediger
>>
>>
>>
>>
>>       -----Ursprüngliche Nachricht-----
>>       Von: Greg White <[e-mail]>
>>       Gesendet: Freitag, 6. Mai 2022 23:51
>>       An: Geib, Rüdiger <[e-mail]>
>>       Cc: [e-mail]
>>       Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy
>>
>>       Hi Ruediger,
>>
>>       I'm afraid you may have taken my statements too literally. You had made an argument that I interpreted as "DT has an established interpretation of DSCPs, and so the DSCP assigned for NQB needs to align with that, and thus be 5 end-to-end".  What I was trying to point out is that DT isn't the only entity with an established DSCP practice (in fact there are some others that I argue may be more important to align with), and that some have questioned whether DT's practice is aligned with the IETF's intention for DiffServ in the first place*.  I was not trying to ask you to defend your DSCP implementation, but rather was simply pointing out that others may think that their approach is the "correct" way too, or they may think the DT model isn't necessarily the one that all IETF standards need to be based on.  For these reasons, I don't think that assigning the value 5 end-to-end is the solution.
>>
>>       To be clear, I'm not saying that your implementation is incorrect or in violation of the letter of the RFCs.  I'm just saying I don't believe that it provides a compelling argument against assigning the value 45 for use at the edge (at least).
>>
>>       Like I said yesterday, no one is arguing from a position of architectural purity here.  In my view there are a lot of conflicting established practices in place, none of which foresaw the definition of NQB, so I think we need to find a set of DSCP recommendations that have the greatest chance of success with the least effort and confusion.  I think we are close to achieving that with the recommendations to use two DSCPs (45 & 5) and the language that we've discussed on this thread.  I'd rather that we continue down that path.
>>
>>       Not that anyone has actually suggested this yet, but if assigning two DSCPs is somehow not possible, then I would argue that we assign 45, since any DS domain in the core can decide to use different DSCPs and either A) re-mark inbound traffic from the IANA assigned NQB DSCP to whichever local-use DSCP (e.g. 5) that they wish, or B) inform its peers that they need to mark NQB traffic in a particular way if they wish that traffic to receive NQB treatment. Neither of these options are available at the edge.
>>
>>       To your specific questions, I'm not sure how to answer them. If it is important for resolving this thread then I'm willing to try, but it isn't clear to me what you were asking.
>>
>>       * For me personally, it has always been my understanding that the DiffServ architecture was intended that the 64 DSCPs are independent values without a defined structure, and that there was no special meaning *in general* for the upper 3 bits separate from the lower 3 bits.  Interoperation with IP Precedence was defined only for the case where the lower 3 bits are 000, and only then do the upper 3 bits indicate something akin to numerical priority. If the lower 3 bits are not 000, then the DSCP is just an index in the number space, and (other than the Pool 1, 2, 3 concept for local use vs standards) there is no structure to that number space.    The AF PHB Group created a structure within its set of 12 DSCPs, where the upper 3 bits convey the "AF class" (which doesn't equate to priority or precedence at all) and the next 2 bits convey the "AF drop precedence" (which is more akin to IP precedence, but here the order is inverted with lower values being higher "priority"), but that only applies to the DSCPs within that set of 12.  DT's practice of using IP Precedence - ignoring the lower 3 bits - (what you refer to as classifying based on DSCP ranges) doesn't align with what I thought was the intention of RFCs 2474 & 2475 (and it sounds like it might not comply with RFC2597), but to your point, I don't see any explicit requirement that forbids it.  Furthermore, the DiffServ specs all seem to allow quite a bit of flexibility (particularly on DSCP values - they are only recommendations after all).
>>
>>       - Greg
>>
>>
>>
>>
>>
>>
>>       On 5/6/22, 2:43 AM, "[e-mail]" <[e-mail]> wrote:
>>
>>           Greg,
>>
>>           I can't tell what the exact QoS deployments of operators competing in Germany are, but I know that at least the larger operators negotiate QoS for all types of interconnection. Some DiffServ related home gateway interface specifications are public, as there is no home gateway operator lock in in Germany (meaning DSCP marking policies helpful for e.g. Wifi gear could be specified there too, and home gateway vendors can support it - I agree, that this "no operator home gateway lock in" is likely specific for Germany an few other countries).
>>
>>           I know that Bob worked on BT's DiffServ QoS a long time ago, when he was working with BT. I'd expect Orange to run some QoS differentiation too, but don't know details (M. Boucadair is active on BGP related QoS signaling in IETF, one may ask him). I also don't know details about US and Asian deployments, or whether these exist at all. I'd recommend not to ignore these deployments, if you'd like to increase benefit for consumers (noting that no one knows all these daggering QoS deployments).
>>
>>           I'd think the best way of reaching the widest support is looking for consent and part of that is respecting existing operational environments to largest extent possible.
>>
>>           Your message doesn't state that operators you've been talking with support DiffServ. Could you clarify that? They don't seem to be able or willing to re-mark DSCPs at access policy points (which are the QoS policy management points in fixed and mobile networks). You didn't answer my question related to broadband cable network Access Policy points yet, I'd appreciate you doing that.
>>           To the extent I can tell, no IP packet viable for some differentiated service passes a mobile edge or fixed network access policy point without being Multi-Field classified. I don't think our vendors sold us equipment having QoS features just and only built for DT.
>>
>>           You write: "And, we've heard the view that IP precedence is deprecated and is not what standards should be written for." - Could you be more precise, so that I understand, what you mean by that? Dou you want to say that classification based on DSCP ranges is not conforming to DiffServ standards? If your answer is yes, please point to a suitable reference.
>>
>>           I'm not sure, whether https://datatracker.ietf.org/doc/html/rfc8837 is supported across carrier backbones. If you or anyone else can shed some light on that, I'd appreciate. It's another example for a recently specified DSCP scheme not requiring any particular operator support apart from transparent transport of DSCPs.
>>
>>           Regards,
>>
>>           Ruediger
>>
>>           -----Ursprüngliche Nachricht-----
>>           Von: Greg White <[e-mail]>
>>           Gesendet: Freitag, 6. Mai 2022 01:52
>>           An: Geib, Rüdiger <[e-mail]>; [e-mail]
>>           Cc: [e-mail]
>>           Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy
>>
>>           See [GW].
>>
>>           On 5/4/22, 1:42 AM, "[e-mail]" <[e-mail]> wrote:
>>
>>               Greg, Gorry
>>
>>               I favour an approach on the recommended marking respecting that DiffServ is operational in some networks for more than a decade.
>>
>>               I think, an approach to maintain DSCP 45 on an end-to-end basis is likely to fail without SLAs at interconnection. That's why I oppose to that. And as I said, the motivation to have this DSCP to support NQB on outdated WiFi boxes to me is not what standards should be written for.
>>
>>           [GW] But, we've heard the opposite from other network operators, who feel that 45 end-to-end is simplest.  And, we've heard the view that IP precedence is deprecated and is not what standards should be written for.  Also, similar to what I indicated in my response to David, I don't know what you mean by "outdated WiFi boxes".  We're talking about nearly every WiFi device on the planet and nearly all of the ones that are available for purchase today.  That's a deployed base that is probably two orders of magnitude larger than the DT network (and growing).  If we had to pick one or the other, I would go with interoperation with Wi-Fi rather than interoperation with DT.
>>
>>           [GW] I think we all need to agree that there is a lot of history with different established practices in place for DSCP usage, and we need to be willing to be flexible. No one is arguing from a position of architectural purity here (well, perhaps Gorry is to some degree), so I think it is a matter of coming up with recommendations that give us the best chance of having the widest support with the least effort and confusion.
>>
>>
>>
>>
>>
>>
>>
>>               Which scenarios do apply?
>>               a) Access provider supports NQB at Access Gateway:
>>                   a1) fixed & mobile networks: the Access Gateway is likely a QoS policy point, (Multi-Field) classification and re-marking are operational.
>>                   a2) I'm not sure about broadband network Access Gateway policy functions.. could these support NQB
>>                          without being QoS policy point? If yes, is that prevalent?     -I try to be careful, no blaming intended-
>>               b) Access provider supports QoS at Access Gateway, but doesn't want to support NQB: then the Gateway is likely a policy point and re-marking is to be expected (in a negative sense could well be DSCP 000 000).
>>               c) Access provider doesn't support QoS at Access Gateway, but wants at least outdated WiFi gear to benefit from NQB. Then DSCP 45 may make sense.
>>               d) Access provider really doesn't care about QoS at any location. Then DSCP 45 may make sense.
>>
>>               In cases b), c) and d), the Access Gateway is forwarding NQB like default (and NQB inherits default performance). Than all the effort is at best only about the WiFi AP. To me that's not justifying an end-to-end marking scheme likely conflicting with providers operating a1). As Greg has mentioned, the home network gateway may deal with the issue (and that should become part of the draft).
>>
>>               Regards, Ruediger
>>
>>               <snip>
>>
>>
>>
>>