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:tsvwg-bounces(_at_)ietf(_dot_)org] Im Auftrag von Richard
Shockey
Gesendet: Freitag, 6. Februar 2015 19:25
An: Piers O'Hanlon; Michael Richardson
Cc: tsvwg(_at_)ietf(_dot_)org; 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" <p(_dot_)ohanlon(_at_)gmail(_dot_)com>
wrote:
On 6 Feb 2015, at 16:57, Michael Richardson wrote:
Jim Gettys <jg(_at_)freedesktop(_dot_)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_Manage
men
t_Algorithms_DOCSIS_3_0.pdf
Piers
--
] Never tell me the odds! | ipv6 mesh
networks [
] Michael Richardson, Sandelman Software Works | network
architect [
] mcr(_at_)sandelman(_dot_)ca http://www.sandelman.ca/ | ruby
on
rails [