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