On Thu, Mar 5, 2015 at 6:15 AM, Mikael Abrahamsson <[email protected]> wrote:
> On Wed, 4 Mar 2015, [email protected] wrote: > > DSCP should not be changed en route, so the receiver of the echo reply >> should be able to know what DSCP was used on the reply packet. >> > > Changing the DSCP bits by the ISP is definitely not unheard of, so don't > count on it. > > Out of curiousity, why would you assume DSCP should not be changed en route? My understanding is within a given DSCP administrative domain, the DSCP value is expected to be passed unchanged, but at administrative boundaries (common ones would be between the customer and their ISP, or between two ISPs at a peering point or private cross connect) it's common to (re)classify or simply rewrite to a known value, unless there is a specific agreement negotiated either between ISPs or between the customer and the ISP. I'm no RFC expert, but this seems to be discussed in a bit more detail in RFC 3260, Section 6 (Unknown/Improperly Mapped DSCPs). Certainly RFC aside, I wouldn't be trusting DSCP markings of IX peers, and in the case of interconnects used for VoIP, I'd be reclassifying based on appropriate access lists negotiated between parties so that only traffic destined between SIP SBCs would be accepted into the higher classes. Everything else I would expect to rewrite to a known value. I guess my point is I wouldn't personally be setting DSCP values from my home DSL router and expecting them to last past my ISPs upstream router. Perhaps that's just me though? Regards, Sam
_______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
