From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5F1FE21F408 for ; Thu, 5 Mar 2015 14:27:16 -0800 (PST) Received: by widem10 with SMTP id em10so39583101wid.0 for ; Thu, 05 Mar 2015 14:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4mmqjj7sSyTrGNnERx+RjkpOvDEXuWK+9x76h+Z+8aQ=; b=xnw/DSrdU+OIqRQ0otm5JB5GcZO9FWECyF3TAL85TmZBBS1YcS8Lu2EMolpiFQXiRT 8aSfrosNai+8NtzZyiugFi/VVECsVaiJdyKV21u2Tbk73CnoTFXsLliqcsIB++GKq8LZ FWarsE9hWLJBoduhAAfavgT36qUj41r7WdcdvCx0crv9Ed9Of9ak+PKQ23xqn6hzCn/O 1UwKcHwDuW9rBj7OpnWlR1t9Qm6M1aEAT+PVu9YnBZDspGQyZcdiwioe0RISDuBbovYF lvX2jIy/AuChhJ4dqUupwzoayopkjvUpHxE2akXZ6SMfl0Osy6YWcUDu5bxxXf683MqL TqYA== MIME-Version: 1.0 X-Received: by 10.180.19.9 with SMTP id a9mr27054472wie.85.1425594433883; Thu, 05 Mar 2015 14:27:13 -0800 (PST) Received: by 10.194.188.116 with HTTP; Thu, 5 Mar 2015 14:27:13 -0800 (PST) In-Reply-To: References: <54F5EF7B.4000006@mti-systems.com> <1425490481.842932044@apps.rackspace.com> Date: Fri, 6 Mar 2015 08:57:13 +1030 Message-ID: From: Sam Silvester To: bloat Content-Type: multipart/alternative; boundary=bcaec53d5a93d3541705109211c2 Subject: Re: [Bloat] [aqm] [Cerowrt-devel] ping loss "considered harmful" X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:27:44 -0000 --bcaec53d5a93d3541705109211c2 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 5, 2015 at 6:15 AM, Mikael Abrahamsson 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 --bcaec53d5a93d3541705109211c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, 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 shou= ld 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 yo= u assume DSCP should not be changed en route?

My understanding is wi= thin a given DSCP administrative domain, the DSCP value is expected to be p= assed unchanged, but at administrative boundaries (common ones would be bet= ween 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 betw= een 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= 9;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 w= ould 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 person= ally be setting DSCP values from my home DSL router and expecting them to l= ast past my ISPs upstream router. Perhaps that's just me though?
Regards,

Sam
--bcaec53d5a93d3541705109211c2--