jlivingood
commented
1 year ago What I meant by no remarking was to mark when the app didn’t mark at all – essentially trying to infer or guess the app’s needs. That does not preclude any internal-only remarking from 45 to something else and back again on egress, or the reverse on ingress.
As well I think there is a temporary case to permit “translation” of 46/40 to 45 until such time as the NQB RFC is issued and IANA reserves 45. It can be IMO justified since there’s no RFC as of yet and that the app has already marked for LL – just with an older code point from earlier standards discussion.
In the memo you say that the network should not mark, the application should and I do agree with this principle, but are you arguing against transposing a NQB marking when it crosses a service providers network?
Internally, we have decided it would be best if we transpose DSCP 45 to DSCP 5 in the downstream across our core and remark to DSCP 45 before delivering the NQB packet to the customer. Then in the upstream do the exact opposite, but with the kink that we will need to remark DSCP 40, 45, 46, and 56 to DSCP 5, but deliver that across the peering interconnect as DSCP 45.
The main reason is due to MPLS encapsulation. If we leave NQB packets marked as DSCP 45 then they will be marked as EXP 5 and get higher priority treatment across our core which is not the desired behavior.
From your document it’s not clear if you intend to transpose across your core.