Re: [Bloat] [aqm] [Cerowrt-devel] ping loss "considered harmful"

[Sam Silvester <sam.silvester@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On Thu, Mar 5, 2015 at 6:15 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Wed, 4 Mar 2015, dpreed@reed.com 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

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]