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

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

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

Diffserv isn't traffic engineering, however.

   Brian

> 
> 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    [
>>>>
>>>
>>
>>
> 
>