[tsvwg] Re: NQB claim of DSCP-

[Vasilenko Eduard <[e-mail]>]

> applaud you for taking on the effort to make DSCPs, or specifically DSCP dec45 useful
It is not possible to develop any mechanism of DSCP usage in the open Internet (cross-AS, peering) till all ISPs agree to charge additional money for this DSCP (that is not possible to negotiate).
If not charged, then this DSCP code point would be abused for profit (if the resource is unlimited and could preempt other traffic, like DualQ) or DDoS (if the resource is fixed, like NQB 5%).

Abuse mitigation techniques:
1. Monitoring per flow is not scalable, defeats the purpose because then it is better to have per-flow treatment initially and achieve even better service. This mitigation is not useful at all.
2. The potential abuser (every subscriber) could be isolated in his personal scheduler. Per-user scheduler (HQoS) is available on BNG/CMTS/UPF and scalable to have it per every subscriber. This mitigation is possible only on the specific subscriber-serving device.

DSCP is useful for VPNs where it is separately charged. But even VPNs are not standardized cross-AS.
Ed/
-----Original Message-----
From: Sebastian Moeller <moeller0=[e-mail]> 
Sent: Saturday, June 1, 2024 14:03
To: Livingood, Jason <jason_livingood=[e-mail]>
Cc: tsvwg <[e-mail]>
Subject: [tsvwg] Re: NQB claim of DSCP-

Hi Jason,


> On 31. May 2024, at 21:24, Livingood, Jason <jason_livingood=[e-mail]> wrote:
> 
> On 5/31/24, 03:10, "Sebastian Moeller" <moeller0=[e-mail] <mailto:[e-mail]>> wrote:
>>>> We can easily see that my ISP (O2/Telefonica) does not remark DSCP decimal 45 (they do remap tos 192 (CS6) and tos 224 (CS7) but I assume that these DSCPs are used in the O2 network itself;
>>> [JL] I wonder if that is unintentional - it would be great to pull in a Telefonica network engineer to see.
> 
>> [SM] Good question, curious to hear some answer to that one. What makes you believe that this might not be intended?
> 
> [JL] Because I have seen many examples over the years where people claim we're doing X or Y due to some presumed policy decision only to find it is an error or something missing in a config on a limited number of devices.

[SM2] Fair enough, I am not privy to the intended goals of O2's DSCP policy, and believe I have no way of figuring this out.
Speaking of DSCP re-mapping is it intentional that 75.75.75.75 remaps to TOS 0x20, aka CS1, when seeing 0x34 from the outside:

user@123-1234567 CODE % traceroute -aD  -t 180  75.75.75.75         traceroute to 75.75.75.75 (75.75.75.75), 64 hops max, 40 byte packets
 1  [AS0] 192.168.42.1 (192.168.42.1)  2.414 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc94000001110000c0a82af94b4b4b4bcc93829b00142e5f000000000000000000000000
____________________6a45________________________________________________________

 2  [AS6805] loopback1.0001.acln.06.ham.de.net.telefonica.de (62.52.201.198)  42.187 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc95000002110000c0a82af94b4b4b4bcc93829c00142e5e000000000000000000000000
________________01__6a44________________________________

 3  [AS6805] bundle-ether8.0002.dbrx.06.ham.de.net.telefonica.de (62.53.1.234)  11.143 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc96000003110000c0a82af94b4b4b4bcc93829d00142e5d000000000000000000000000
________________01__6a43________________________________________________________00000000000000000000000000000000000000000000000000000000

 4  [AS6805] bundle-ether5.0003.corx.01.ham.de.net.telefonica.de (62.53.14.28)  21.078 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc97000004110000c0a82af94b4b4b4bcc93829e00142e5c000000000000000000000000
________________01__6a42________________________________________________________0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020007fd900080101041c5b01

 5  [AS6805] ae6-0.0001.corx.01.off.de.net.telefonica.de (62.53.0.35)  19.715 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc98000005110000c0a82af94b4b4b4bcc93829f00142e5b000000000000000000000000
________________02__6941________________________________________________________000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000dfe600080101040efb01

 6  [AS6805] ae2-0.0001.inrx.04.str.de.net.telefonica.de (62.53.2.151)  18.245 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc99000006110000c0a82af94b4b4b4bcc9382a000142e5a000000000000000000000000
________________03__6840________________________________________________________000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000dfe600080101040efb01

 7  [AS6805] ae0-0.0001.prrx.02.dus.de.net.telefonica.de (62.53.13.221)  20.081 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc9a000007110000c0a82af94b4b4b4bcc9382a100142e59000000000000000000000000
________________01__6a3f________________________________

 8  *
 9  [AS12956] 213.140.36.245 (213.140.36.245)  29.769 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc9c000009110000c0a82af94b4b4b4bcc9382a300142e57000000000000000000000000
__34____________01__6abd________________________________

10  [AS12956] 213.140.35.238 (213.140.35.238)  105.953 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc9d00000a110000c0a82af94b4b4b4bcc9382a400142e56000000000000000000000000
__34____________01__6abc________________________________________________________00000000000000000000000000000000000000000000000000000000

11  [AS7922] be-204-pe13.ashburn.va.ibone.comcast.net (71.25.197.185)  105.751 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc9e00000b110000c0a82af94b4b4b4bcc9382a500142e55000000000000000000000000
__34____________01__6abb________________________________________________________00000000000000000000000000000000000000000000000000000000

12  [AS7922] be-3313-cs03.beaumeade.va.ibone.comcast.net (68.86.166.217)  105.551 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cc9f00000c110000c0a82af94b4b4b4bcc9382a600142e54000000000000000000000000
__20____________01__6ace________________________________________________________00000000000000000000000000000000000000000000000000000000

13  [AS7922] be-31411-arsc1.capitolhghts.md.bad.comcast.net (96.110.40.18)  109.026 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cca000000d110000c0a82af94b4b4b4bcc9382a700142e53000000000000000000000000
__20____________01__6acd________________________________________________________00000000000000000000000000000000000000000000000000000000

14  [AS7922] po-1-xar01.alexandria.va.bad.comcast.net (96.216.131.254)  108.005 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cca100000e110000c0a82af94b4b4b4bcc9382a800142e52000000000000000000000000
__20____________01__6acc________________________________________________________

15  [AS7922] po-200-rur201.alexandria.va.bad.comcast.net (68.86.204.102)  107.570 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cca200000f110000c0a82af94b4b4b4bcc9382a900142e51000000000000000000000000
__20____________01__6acb________________________________________________________

16  [AS7922] dns-sw01.alexandria.va.bad.comcast.net (68.85.113.126)  113.486 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cca3000010110000c0a82af94b4b4b4bcc9382aa00142e50000000000000000000000000
__20____________01__6aca________________________________________________________

17  [AS7922] cdns01.comcast.net (75.75.75.75)  108.596 ms
vhtslen id  off tlprsum srcip   dstip   spt dpt len sum
45b42800cca4000011110000c0a82af94b4b4b4bcc9382ab00142e4f000000000000000000000000
__20____________01__6ac9________________________________________________________


CS1 being traditional background category, that might make some sense in that access to comcast's DNS servers might be considered lower priority than for comcast customers (but I can not really test that hypothesis).

> 
>> Look, I understand that DSCPs do not currently traverse the internet reliably and robustly, but that is not the same as a reliable neutering of NQB over not NQB-aware paths. Delegating safety tor accidental configurations (that are not really aligned with IETF recommendations) seems neither robust nor reliable to me.
> 
> [JL] My observation as an operator is that every other network with which we connect is bleaching our inbound DSCP marks. That is one of the things that will make NQB challenging; we need to get networks to allow 45 marking inbound - so NQB will likely take more time for adoption that L4S, since in most cases ECN is not bleached on ingress.

[SM] Yes I :
a) applaud you for taking on the effort to make DSCPs, or specifically DSCP dec45 useful over more than a single link (I disagree with NQB's current draft and design, but I agree with it being quite attractive to make a few DSCPs capable of traversing end to end)
b) Getting a specific DSCP traverse the internet reliably un-changed is a requirement for making that DSCP really useful, but to make the expected re-marking a safety feature IMHO requires that remapping is almost universal, and I think I brought a 'black swan' to this discussion already. Still possible, that the likelihood of re-markung is high enough to consider that a back-stop, but I really would like to see some data assessing that re-marking probability per residential ISP.

Regards
	Sebastian


> 
>