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

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