Hi Jason, > On 9. Mar 2024, at 15:38, Livingood, Jason via Nnagain > <nnagain@lists.bufferbloat.net> wrote: > > On 3/8/24, 22:02, "Nnagain on behalf of David Lang via Nnagain" > <nnagain-boun...@lists.bufferbloat.net > <mailto:nnagain-boun...@lists.bufferbloat.net> on behalf of > nnagain@lists.bufferbloat.net <mailto:nnagain@lists.bufferbloat.net>> wrote: > >> In practice, priority bits are ignored on the Internet. There are no legal > limits on what bits can be generated, and no reason to trust priority bits > that > come from a different network. >> As I understand the current state of the art, best practice is to zero out > priorities at organizational boundries > > [JL] Quite true: each network tends to use DSCP marks on a private/internal > basis and so will bleach the DSCP marks on ingress from peers. This will, > however, change with the upcoming IETF RFC on Non-Queue-Building (NQB) Per > Hop Behavior - h++ps://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb.
[SM] In all respect, that is wishful thinking. Just because an IETF RFC states/recommends something does not mean it actually is implemented that way in the existing internet... Current in-effect RFCs already recommend that ISPs should not change DSCPs that they do not need to use for their own PHB-needs but simply treat them to default forwarding, but that is not what ISPs actually do. Case in point, a big (probably the biggest) DOCSIS ISP in the USA had been remarking a noticeable fraction of packets to CS1 for years (which at a time was defined to mean background or lower priority and is treated as such by default WiFi APs) causing issues at end users' home networks. (Said ISP, to its credit, did fix the issue recently, but it tool a few years...). Just becyause something is writen in an RFC does not make it reality. And given the hogwash that some RFCs contain, that is not even a bad thing per se. (Examples on request ;) ) > And I can report that we at Comcast now permit DSCP-45 inbound for NQB > packets, in case developers would like to experiment with this (we just > finished updating router configs last week for residential users on DOCSIS; > FTTP and commercial are still in process). [SM] Since I have your attention, if I try comcast's bespoke networkQuality server (from your L4S tests): networkQuality -C https://rpm-nqtest-st.comcast.net/.well-known/nq -k -s -f h3,L4S I saw ECT(1) marking on my egressing packets, but none on the ingressing packets... that does not seem to be in line with the L4S RFCs (giving another example why RFC text alone is not sufficient for much). (Sidenote: if all L4S testing is happening in isolated networks, why wait for L4S becoming RFCs before starting these tests?) > > > > > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > h++ps://lists.bufferbloat.net/listinfo/nnagain _______________________________________________ Nnagain mailing list Nnagain@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/nnagain
