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 <[e-mail]>]

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. But agreements of use across boundaries aren't that clear and probably wouldn't generally be extended to end users. I guess they're also using things like MPLS, or SDN (e.g. Google B4) for traffic engineering.

Piers

> 
> 
> On 2/6/15, 12:28 PM, "Piers O'Hanlon" <[e-mail]> wrote:
> 
>> 
>> On 6 Feb 2015, at 16:57, Michael Richardson wrote:
>> 
>>> 
>>> Jim Gettys <[e-mail]> 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  [
>>> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
>>> rails    [
>>> 
>> 
> 
>