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

[<[e-mail]>]

As Brian pointed out, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/ proposes a method "how to get the labeling/queueing across the AS boundary". Input is welcome.

Commercial DiffServ interconnection products are available. They may however not be be widespread. 

If you however ask the question how to transit the complete QoS concept and codepoints of a sending domain to a customer connected to another domain - that hasn't been standardized yet.  
If your expectation is that a consumer (device) sets priorities of packets and carriers honour these markings, a technical and commercial model accepted by all parties is required. I'm not aware of one (I'm not interested in discussing how to get one on this list).
There's also no generally specified set of packet marks within the Best Effort class, which can transparently cross carrier boundaries on an end to end basis. That might offer a separation of WAN and LAN or application QoS marks (should this be useful).

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Richard Shockey
Gesendet: Freitag, 6. Februar 2015 19:25
An: Piers O'Hanlon; Michael Richardson
Cc: [e-mail]; Phillip Hallam-Baker; Jim Gettys; IETF Discussion Mailing List
Betreff: Re: [tsvwg] Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.


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.



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