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

Piers O'Hanlon <p.ohanlon@gmail.com> Fri, 06 February 2015 19:57 UTC

Return-Path: <p.ohanlon@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB5A1A1BFA; Fri, 6 Feb 2015 11:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OICyvsTdBueA; Fri, 6 Feb 2015 11:57:50 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5807D1A1BC7; Fri, 6 Feb 2015 11:57:50 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id y19so15638055wgg.2; Fri, 06 Feb 2015 11:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qtkqw1uOxWWWas+wNR8PlHJ6424Ty6aJS1kNW/5LZBo=; b=XmExNsrvP3Ck7Bi9hiLPlP0KCi6D0tJ1yeeYeTtThce7j6NL73XKZ1Hw7YXMUI6iP/ Vh549H9eMdBC7OfkdF84GLuveJCMaySyM9pLcVizqXbHjihiHidtGMZG+sfJchnW7FOl QInn31gSI0KOGrxX4m567YqxqzyvW+WL8XY6QrABWrTh/RqdOW3TdY4F8X+m1I8fn3L3 AWUDs/KxzNB+uGQnPVeWZ8U+6UijjnxFEiAM2L7O9rF9F7bK6BVGtj1ydZOwdg79t53a WY06rRYh4QCjlR3+a/neAEjlEZmbyWhibNMp5O28iAz6M9b4LREMuHS61tX2Xaq5bS8e Ah2w==
X-Received: by 10.180.101.234 with SMTP id fj10mr6801271wib.20.1423252669132; Fri, 06 Feb 2015 11:57:49 -0800 (PST)
Received: from black.lan (bcddfef6.skybroadband.com. [188.221.254.246]) by mx.google.com with ESMTPSA id li10sm2795529wic.10.2015.02.06.11.57.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 11:57:47 -0800 (PST)
Subject: Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=utf-8
From: Piers O'Hanlon <p.ohanlon@gmail.com>
In-Reply-To: <54D515A3.5050104@gmail.com>
Date: Fri, 6 Feb 2015 19:57:45 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <05406547-5CFE-48FB-AB58-100299139304@gmail.com>
References: <D0F962E2.1E9B2%richard@shockey.us> <CAGhGL2AAda10+YY54GJRN4Af_pGC4ZaMv=97=6aNRzqKfJBqkg@mail.gmail.com> <28651.1423241869@sandelman.ca> <F60D7FE0-7EA9-4F07-8B7A-1F822DD34BDF@gmail.com> <D0FA7092.1EC23%richard@shockey.us> <33CECEE4-7C13-4C0C-A275-987DBF1D9837@gmail.com> <54D515A3.5050104@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1283)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/eeBhhzpCE2iZDVUcWIMAELxtFSE>
Cc: Michael Richardson <mcr@sandelman.ca>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Richard Shockey <richard@shockey.us>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 19:57:53 -0000

Hi Brian,

On 6 Feb 2015, at 19:27, Brian E Carpenter wrote:

> 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
> http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon
> 
Sure - I guess I was just pointing out that one can't generally use DSCPs end2end even if one wanted to try...

>> I guess they're also using things like MPLS, or SDN (e.g. Google B4) for traffic engineering.
> 
> Diffserv isn't traffic engineering, however.
> 
Agreed - that's yet another ballgame ;)

Piers

>   Brian
> 
>> 
>> Piers
>> 
>>> 
>>> 
>>> On 2/6/15, 12:28 PM, "Piers O'Hanlon" <p.ohanlon@gmail.com> wrote:
>>> 
>>>> 
>>>> On 6 Feb 2015, at 16:57, Michael Richardson wrote:
>>>> 
>>>>> 
>>>>> Jim Gettys <jg@freedesktop.org> 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:
>>>> http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Managemen
>>>> t_Algorithms_DOCSIS_3_0.pdf
>>>> 
>>>> Piers
>>>> 
>>>> 
>>>>> --
>>>>> ]               Never tell me the odds!                 | ipv6 mesh
>>>>> networks [
>>>>> ]   Michael Richardson, Sandelman Software Works        | network
>>>>> architect  [
>>>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
>>>>> rails    [
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>