[tsvwg] Re: NQB claim of DSCP-

[Sebastian Moeller <[e-mail]>]

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


> 
>