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.ohanlon@xxxxxxxxx> wrote: >>> >>>> >>>> On 6 Feb 2015, at 16:57, Michael Richardson wrote: >>>> >>>>> >>>>> Jim Gettys <jg@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on >>>>> rails [ >>>>> >>>> >>> >>> >> >> >