Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.

Brian E Carpenter <> Fri, 06 February 2015 19:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FAF81A1A59; Fri, 6 Feb 2015 11:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wJRg0YDuwGcz; Fri, 6 Feb 2015 11:27:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9152C1A1A40; Fri, 6 Feb 2015 11:27:32 -0800 (PST)
Received: by pdjy10 with SMTP id y10so16587458pdj.7; Fri, 06 Feb 2015 11:27:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NxUw2eillpnwbS04QFG/dL55HTlBwG/JVrSKFetlz4A=; b=Cdo11YnlqjGAVkpsqEbQf4XMcvIjKCAhH5DxMiIeas32mokn0E/qEs+qGpz2Uf0KHj UTFIwj1XrHmhencJ48S/q1ej8pQvxdYdlHXA4gmMJ//fPNaF3qJjf8tXX/Hw02z29yCI 7LimK6sJp9s9iV2PKGtj/m+OScxaCcFr0MukjL/hL30SIJ13AtV2v/Jtt/GlLCr2D3Qq 1JSeBLkrEuEDoYUZvo440VyEZGeNyGGApez45lvZD3m5AkRbSPp5SqHBq1YqmX7SbC4k oUjUmKm9nDFPRcNQgUIpi+AncumNiGAvoVpLvvYihcOXd5l/lLzu4u27JQCLrHDDks7c iS6A==
X-Received: by with SMTP id kh7mr8147196pab.21.1423250851986; Fri, 06 Feb 2015 11:27:31 -0800 (PST)
Received: from ?IPv6:2406:e007:5239:1:28cc:dc4c:9703:6781? ([2406:e007:5239:1:28cc:dc4c:9703:6781]) by with ESMTPSA id g11sm8886470pat.24.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 11:27:30 -0800 (PST)
Message-ID: <>
Date: Sat, 07 Feb 2015 08:27:31 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Piers O'Hanlon <>, Richard Shockey <>
Subject: Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Michael Richardson <>, Phillip Hallam-Baker <>, "" <>, IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Feb 2015 19:27:35 -0000

On 07/02/2015 08:05, Piers O'Hanlon wrote:
> On 6 Feb 2015, at 18:24, Richard Shockey wrote:
>> Fine now how do you get the labeling/queueing across the AS boundary?  I
>> don’t know any ISP that accepts or recognizes the packet labeling of
>> another AS.
> Sure - that's another whole ballgame! A number of ISPs blow away the DSCP bits in packets from and to the home, as I understand they use their own set of DSCPs internally. 

That is entirely in keeping with the diffserv architecture, which is
explicit that DSCPs are domain-specific and that traffic may be
reclassified at domain boundaries. (Which is what operators wanted
when diffserv was designed.)

> But agreements of use across boundaries aren't that clear and probably wouldn't generally be extended to end users. 

Agreements across boundaries require mutual trust, so it's to be
expected that ISPs will reclassify traffic arriving from subscribers.
For ISP/ISP boundaries, see

> I guess they're also using things like MPLS, or SDN (e.g. Google B4) for traffic engineering.

Diffserv isn't traffic engineering, however.


> Piers
>> On 2/6/15, 12:28 PM, "Piers O'Hanlon" <> wrote:
>>> On 6 Feb 2015, at 16:57, Michael Richardson wrote:
>>>> Jim Gettys <> wrote:
>>>>> ​What effect does this algorithm have in practice? Here are some
>>>>> examples:
>>>>> o real time isochronous traffic​ (such as VOIP, skype, etc) won't build
>>>>> a queue, so will be scheduled in preference to your bulk data.
>>>>> o your DNS traffic will be prioritized.
>>>>> o your TCP open handshakes will be prioritized
>>>>> o your DHCP & RA handshakes will be prioritized
>>>>> o your handshakes for TLS will be prioritized
>>>>> o any simple request/response protocol with small messages.
>>>>> o the first packet or so of a TCP transfer will be prioritized:
>>>>> remember,
>>>>> that packet may have the size information needed for web page layout
>>>>> in it.
>>>>> o There is a *positive* incentive for flows to pace their traffic (i.e.
>>>>> to be a good network citizen, rather than always transmitting at line
>>>>> rate).
>>>>> *All without needing any explicit classification.  No identification of
>>>>> what application is running is being performed at all in this
>>>>> algorithm.*
>>>> This last part is I think the part that needs to be shouted at
>>>> residential
>>>> ISPs on a regular basis.  I wish that the IETF and ISOC was better able
>>>> to
>>>> do this... in particular to ISPs which do not tend to send the right
>>>> people
>>>> to NANOG/RIPE/etc.
>>> Explicit class-based queueing is seeing fairly substantial deployment in
>>> some places - such as the UK - where for a few years now the default home
>>> routers (Thomson/Technicolor TG587/582 etc) for a number of the big ISPs
>>> (Plusnet, O2/Sky, Talk-talk and others) have shipped preconfigured with 5
>>> queuing classes that classify traffic and provide for differing
>>> treatment. They also have some ALGs that work with SIP/H.323. I'm not
>>> aware of AQM enabled on the individual queues but at least they separate
>>> the traffic into different queues - albeit based on port number or ALG
>>> classifiers. Better than nothing anyway.
>>> Also the DOCSIS3.1 standard now mandates the use an AQM - namely PIE,
>>> though others can be implemented. I'm not sure where that is in terms of
>>> deployment though. There's a good report on it here:
>>> t_Algorithms_DOCSIS_3_0.pdf
>>> Piers
>>>> --
>>>> ]               Never tell me the odds!                 | ipv6 mesh
>>>> networks [
>>>> ]   Michael Richardson, Sandelman Software Works        | network
>>>> architect  [
>>>> ]        |   ruby on
>>>> rails    [