Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On Tue, May 12, 2015 at 9:17 PM, Simon Barber wrote: > Hi Wesley, > > Thanks for considering my comments, and apologies for being so late in the > process - I've only recently been able to put time into this area, and I > understand it may be too late in the process to hack things in. I replied to > John with where I'm concerned with the current -11 text. I am glad you are able to put time in, you have been a long way away. > Re: background / low priority streams. There are other ways to achieve a > 'lower priority', such as changing the AIMD parameters. Does not help if FQ > is involved though. There are many ways to do lower priority streams if fq is present. Simplest: 1) Send 3 packets back to back, timestamped. First packet arrives in an empty queue, gets sent out immediately, 2nd and third packet are affected by the total number of flows extant. (fq_codel) (or in SFQ all are affected by total number of flows) keep that to 1/2 OWD (or less) plus fuzz/smoothing and you have a solution for how much additional load you are willing to add to the network. 2) for coupled congestion control on say 6 flows from one app do the same sort of bunching and measure, then drop off when one or more of the flows experiences excessive delay. In both cases the timestamps would be received differently and in order via pure aqm or drop tail most of the time. It is relatively easy to get "low priority" in other words in a fq'd system. It is harder to get to an optimal bandwidth while still staying low priority and somewhat hard to figure out if you are being fq'd in the first place. > My concern is that implementing AQM removes a capability > from the network, so doing so without providing a mechanism to support low > priority is a negative for certain applications (backups, updates - and the > impact these have on other applications). Would be good for this to be at > least common knowledge. Is there any other document this could go in? see dart. > Simon > > > > On 5/12/2015 5:11 PM, Wesley Eddy wrote: >> >> On 5/8/2015 11:42 PM, Simon Barber wrote: >>> >>> I have a couple of concerns with the recommendations of this document as >>> they stand. Firstly - implementing AQM widely will reduce or even >>> possibly completely remove the ability to use delay based congestion >>> control in order to provide a low priority or background service. I >>> think there should be a recommendation that if you are implementing AQM >>> then you should also implement a low priority service using DSCP, e.g. >>> CS1. This will enable these low priority applications to continue to >>> work in an environment where AQM is increasingly deployed. Unlike DSCPs >>> that give higher priority access to the network, a background or low >>> priority DSCP is not going to be gamed to get better service! >>> >>> Secondly, there is a recommendation that AQM be implemented both within >>> classes of service, and across all classes of service. This does not >>> make sense. If you are implementing AQM across multiple classes of >>> service, then you are making marks or drops while ignoring what class >>> the data belongs to. This destroys the very unfairness that you wanted >>> to achieve by implementing the classes in the first place. >>> >> >> Hi Simon, thanks for your comments. >> >> These comments appear to be in response to version -04 of the document, >> from around 1 year ago. The document is currently on version -11, has >> past working group last call and IESG evaluation, and is in the RFC >> Editor's queue. I mention this, because it isn't clear to me how >> applicable your comments are with regard to the current copy. >> >> The current copy can be found at: >> https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >> >> The current revision does mention the impact to delay-based end-host >> algorithms as an area for future research. >> >> While I agree that in a lot of cases it seems like logically a good >> idea to have a DiffServ configuration like you mention, I don't think >> we have seen data on this yet in the working group. Looking into this >> could be part of that mentioned future work, though not something I'd >> want to see hacked into this document today, so late in its publication >> process. >> > > ___ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On Mon, 18 May 2015, Simon Barber wrote: Thank you Mikeal, these are useful observations about the choice of exact DSCP value and various potential impacts. I agree that ultimately without operator agreement non of this matters. I do think that an important step towards garnering that operator agreement is to have the concerns clearly elucidated in this group's recommendations. I found a study of the interaction between low priority background techniques, including LEDBAT and AQM. http://www.enst.fr/~drossi/paper/rossi12conext.pdf it's conclusion states: "Shortly, our investigation confirms the negative interference: while AQM fixes the bufferbloat, it destroys the relative priority among Cc protocols." Apparently a significant chunk of bittorrent traffic and Windows updates use these techniques to deprioritise their traffic. Widespread adoption of AQM will remove their ability to avoid impacting the network at peak times. Use of DSCP could be one way to mitigate this problem with AQM, and this merits further study. Does it matter? If such traffic doesn't interfere significantly with what the user is trying to do in the forground, it shouldn't matter that it's not being deprioritized as much. The big problem before was that such traffic would cause the buffers to build up and slow everything down. With AQM in place, that concern basically disappears and the only resulting problem would be that you are maxing out the available bandwidth unless you deprioritize such traffic. But if I'm sitting waiting for Windows to download an update, that's now forground traffic that is preventing me from doing anything else. I don't want it to be deprioritized behind other people in the house doing other things. I want it to get it's fair share of bandwidth. The vast majority of the time, users are going to have enough bandwidth to be able to share it with such update mechansims. Those of us stuck on low bandwidth links (I'm currently unable to upgrade beyond 3Mb on my DSL line), are going to have to accept that when we have multiple things going on, they are going to impact each other because the sum of the bandwidth each wants is higher than the available bandwidth. David Lang Simon Sent with AquaMail for Android http://www.aqua-mail.com On May 13, 2015 1:47:33 AM Mikael Abrahamsson wrote: On Tue, 12 May 2015, Simon Barber wrote: > Hi John, > > Where would be the best place to see if it would be possible to get agreement > on a global low priority DSCP? Currently the general assumption among ISPs is that DSCP should be zeroed between ISPs unless there is a commercial agreement saying that it shouldn't. This is generally accepted (there are NANOG mailing list threads on several occasions in the past 5-10 years where this was the outcome). The problem is quite complex if you actually want things to act on this DSCP value, as there are devices with default behaviour is 4 queue 802.1p, with 1 and 2 (which will match AF1x and AF2x) will have lower priority than 0 and 3 (BE and AF3x), and people doing DSCP based forwarding, usually does things the other way around. It might be possible to get the last DSCP bits to map into this, because for DSCP-ignorant quipment, this would still be standard BE to something only looking at CSx (precedence), but that would be lower than 00. So DSCP 000110 (high drop BE) might work, because it's incremental. Possibly DSCP 10 (low drop BE) might be able to get some agreement because it doesn't really cause any problems in the existing networks (most likely) and it could be enabled incrementally. I would suggest bringing this kind of proposal to operator organizations and the IETF. It needs to get sold to the ISPs mostly, because in this aspect the IETF decision will mostly be empty hand-waving unless the operators do something. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
> On 18 May, 2015, at 20:18, Dave Taht wrote: > > Since dart I have basically come to the conclusion we need at least > one new diffserv priority class for scavaging traffic. Scavenging traffic is, of course, the rationale behind assigning CS1 to the background class (which has lower priority than best-effort) in Cake. If another DSCP is recommended in future for this purpose, it would be straightforward to assign that to the background class as well. Something in the 000xxx range might be more compatible with legacy equipment. I’m therefore disappointed that existing recommendations for practical Diffserv deployment ignore the Low Priority class. But it’s important to note that assigning traffic to separate queues - whether by FQ or Diffserv - only matters at bottlenecks. Even if there is legacy equipment on the path that happens to interpret CS1 as “elevated priority”, it will have no effect if that isn’t a bottleneck link. Likewise, AQM only makes a difference at a bottleneck. It may be worthwhile to emphasise that deployment of AQM should be prioritised on links which are regularly saturated (on timescales of seconds, not minutes). Over-provisioned links can usually look after themselves, as well as probably presenting the most difficult technical challenge to implementing good AQM. Saturated links are usually slow enough (10Gbps and down) for AQM implementation to be a tractable problem, even in software. The most visible problems are usually at or near the last mile, which so far is 1Gbps and down, with the most important deployment locations involving 100Mbps and under. In fact, the lower the bandwidth of the link, the more important *and* the easier the implementation and deployment of good AQM. For most traffic patterns, Diffserv isn’t even necessary. The combination of AQM and FQ does an excellent job - *unless* there is a saturating application that uses many flows. In that case, FQ ends up giving that application a large share of the bandwidth, and can starve latency-sensitive applications that use only one flow. It is that scenario - which is exercised by the likes of BitTorrent - which convinced me to add Diffserv support to Cake. Then, whether the latency-sensitive application sets a high-priority DSCP or the many-flows saturator sets CS1 (or, preferably, both), the problem is resolved satisfactorily. - Jonathan Morton ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On Mon, May 18, 2015 at 8:54 AM, Jonathan Morton wrote: > >> On 18 May, 2015, at 18:27, Simon Barber wrote: >> >> Apparently a significant chunk of bittorrent traffic and Windows updates use >> these techniques to deprioritise their traffic. Widespread adoption of AQM >> will remove their ability to avoid impacting the network at peak times. Use >> of DSCP could be one way to mitigate this problem with AQM, and this merits >> further study. > > I’m working on a comprehensive algorithm (including AQM, FQ and Diffserv > support and a shaper in one neat package) which does address this problem, or > at least provides a platform for doing so. Some information here: > > http://www.bufferbloat.net/projects/codel/wiki/Cake This is partially an outgrowth of some of the ideas and problems I attempted to discuss at ietf90. https://www.ietf.org/proceedings/90/slides/slides-90-aqm-6.pdf Since then various other working groups (like dart) attempted to answer some of the same questions. I am pretty convinced (now) that inbound policing on cpe can be improved to better "fool" dumb upstream rate limiters (like those in cmtses), but haven't got around to doing the work (it's called "bobbie"). The biggest problem we have with applying a shaper + fq/aqm algorithm to inbound traffic on an already be-ing dumbly rate limited link is that a burst can backup in the upstream cmts and stay backed up - a rate differential of 90 to 100 takes a long time for an aqm to bring under control. Analysis of "smoothness" might also help. When the ratios are 10 or 1000s to 1 and there is only one bottleneck link, we do better. > This is working code, albeit still under development. I’m actively > dogfooding it, and I’m not the only one doing so. Pushing it into openwrt soon, we hope. As it stands cake is a win across the board on cpu cost and fairness, it does saner things with ecn, and so on... We have discussed a few more advanced ideas that are not currently in cake on the cake mailing list, including better coupling between flows, more rapid response to overload, etc. > The Diffserv layer provides a four-class system by default, corresponding in > principle with the 802.1p classes - background, best-effort, video and voice. > It does not inherit the naive mapping from DSCPs to those classes, though - > only CS1 (001000) is mapped to the background class. I see a ton of traffic remarked to CS1 from comcast. Others may be more lucky. Since dart I have basically come to the conclusion we need at least one new diffserv priority class for scavaging traffic. > An important part of the Diffserv support in Cake is that the enhanced > priority given to the video and voice classes applies only up to given shares > of the overall bandwidth. If traffic in those classes exceeds that allocated > share, deprioritisation occurs. This ensures that improperly marked traffic > cannot starve the link, and attempts to incentivise correct marking. > > - Jonathan Morton > > ___ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On Mon, May 18, 2015 at 8:27 AM, Simon Barber wrote: > Thank you Mikeal, these are useful observations about the choice of exact > DSCP value and various potential impacts. I agree that ultimately without > operator agreement non of this matters. I do think that an important step > towards garnering that operator agreement is to have the concerns clearly > elucidated in this group's recommendations. > > I found a study of the interaction between low priority background > techniques, including LEDBAT and AQM. > > http://www.enst.fr/~drossi/paper/rossi12conext.pdf That paper was continually extended and revised. (I have had very little to do with it since the first release.) http://perso.telecom-paristech.fr/~drossi/paper/rossi14comnet-b.pdf While it is pretty good... my fav part of that paper is table 3 where the authors ignore the 7 second delay on the link but otherwise showing the optimal ratio between real tcp and utp in their testbed. LEDBAT was probably my first concern and area of research before entering this project full time. I *knew* we were going to break ledbat, but the two questions were: how badly? (ans: pretty badly) and did it matter? (not that much, compared to saving seconds overall in induced delay) > it's conclusion states: > > "Shortly, our investigation confirms the negative interference: while AQM > fixes the bufferbloat, it destroys the relative priority among Cc > protocols." Yep. I do wish the paper was updated to account for 4 concepts 0) never got around to trying ns2/ns3 fq_codel or the sqm_scripts against it 1) utp has a lower IW. With the move to IW10 in linux tcp iw10 tcp knocks utp more out of the way (note that a ton of torrent clients still use tcp and thus they are getting an "advantage" now by using iw10 that they shouldn't be). Anyway, most web traffic knocks utp out of the way handily 2) ledbat when first proposed had a 25ms target for induced delay. I would not mind that tried again. 3) coupled congestion control (one app, many flows) > Apparently a significant chunk of bittorrent traffic and Windows updates use > these techniques to deprioritise their traffic. So, torrent and ledbat are different things. torrent has LOTS of flows (worst case 6 active/torrent, (50 or more connected, and switching one into an active state every 15 seconds)). ledbat is just a cc algorithm that torrent and some other heavy apps use. > Widespread adoption of AQM > will remove their ability to avoid impacting the network at peak times. No. A single ledbat flow will behave like a single tcp flow. Widespread adoption of AQM will make it easier for many flows to share the network with low latency. I don't see any impact from continued use of ledbat for applications like updates, backups, etc. My own recomendation is merely to try torrent today with your aqm or fq system of choice and see what happens. I did, and stopped worrying about ledbat. > Use > of DSCP could be one way to mitigate this problem with AQM, and this merits > further study. while we have long recommended CS1 be set on torrent, it turns out that a lot of gear actually prioritizes that over BE, still. It helps on the outbound where you can still control your dscp settings. Many torrent users have reported just setting their stuff to max outbound and rate limiting inbound, and observing no real effects on their link. > > Simon > > Sent with AquaMail for Android > http://www.aqua-mail.com > > > > On May 13, 2015 1:47:33 AM Mikael Abrahamsson wrote: > >> On Tue, 12 May 2015, Simon Barber wrote: >> >> > Hi John, >> > >> > Where would be the best place to see if it would be possible to get >> > agreement >> > on a global low priority DSCP? >> >> Currently the general assumption among ISPs is that DSCP should be zeroed >> between ISPs unless there is a commercial agreement saying that it >> shouldn't. This is generally accepted (there are NANOG mailing list >> threads on several occasions in the past 5-10 years where this was the >> outcome). >> >> The problem is quite complex if you actually want things to act on this >> DSCP value, as there are devices with default behaviour is 4 queue 802.1p, >> with 1 and 2 (which will match AF1x and AF2x) will have lower priority >> than 0 and 3 (BE and AF3x), and people doing DSCP based forwarding, >> usually does things the other way around. >> >> It might be possible to get the last DSCP bits to map into this, because >> for DSCP-ignorant quipment, this would still be standard BE to something >> only looking at CSx (precedence), but that would be lower than 00. So >> DSCP 000110 (high drop BE) might work, because it's incremental. Possibly >> DSCP 10 (low drop BE) might be able to get some agreement because it >> doesn't really cause any problems in the existing networks (most likely) >> and it could be enabled incrementally. >> >> I would suggest bringing this kind of proposal to operator organizations >> and the IETF. It needs to get sold to the ISPs mostly, b
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
I agree that if AQM is deployed it would be good to revisit this topic (and note that some methods include a notion of flow-queuing, which also interacts). Coincidentally this at a time when TSVWG is trying to help inter-domain diffserv connection... As I noted at the last IETF TSV WG meeting, this topic has the attention of "this" TSV WG Chair - and I think it would be useful to AT LEAST review where we have reached, although I suggest "what do we do next" discussions belong on the TSV mailing list. Feel free to take this topic up there! Gorry (TSVWG Co-Chair) > Hi, > > On 13.05.2015 at 07:01 Fred Baker (fred) wrote: >>> On May 12, 2015, at 9:06 PM, Simon Barber >>> wrote: >>> >>> Where would be the best place to see if it would be possible to >>> get agreement on a global low priority DSCP? >> >> Id suggest >> >> https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines >> for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August >> 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status: >> INFORMATIONAL) >> >> It refers to >> >> [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 >> Technical Report Proposed Service Definition, March 2001. >> >> (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and >> states that > > While QBSS may have gotten more attention the original idea is here: > https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00 > from there it finally went to a PDB definition in RFC 3662 as you > already found out, because the DiffServ chairs didn't want it to be > defined as PHB. > >>> Within QBone, traffic marked with DSCP 001000 (binary) shall be >>> considered in the QBSS class and should be given the service >>> described in this document. Notice that while DSCP values >>> generally have only local significance we are assigning global >>> significance to this particular codepoint within QBone. We refer >>> to packets marked with DSCP 001000 as being marked with the "QBSS >>> code point. >> >> >> Thats where we came up with recommending CS1 (001000) for the >> traffic class. > > CS1 is maybe a problem because originally (rfc 2474) CS1 means better > priority than CS0. At that point in time of RFC3662 the discussion was > to use CS1, because also in 802.1p 1 means "background". However, > this inconsistency makes it now hard to rely on any semantics of DSCP > CS1. IIRC the Diffserv chairs were opposed to spend another DSCP on LE > and therefore proposed to use an existing one. In retrospect, this > seems to have been a wrong decision given the problems of rtcweb and > so on these days. > >> Im pretty sure the latter ultimately resulted in an RFC, but for >> some reason Im not finding it. The closest thing I see is > > Yes, https://tools.ietf.org/html/rfc3662. > > Regards, > Roland > > ___ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
> On 18 May, 2015, at 18:27, Simon Barber wrote: > > Apparently a significant chunk of bittorrent traffic and Windows updates use > these techniques to deprioritise their traffic. Widespread adoption of AQM > will remove their ability to avoid impacting the network at peak times. Use > of DSCP could be one way to mitigate this problem with AQM, and this merits > further study. I’m working on a comprehensive algorithm (including AQM, FQ and Diffserv support and a shaper in one neat package) which does address this problem, or at least provides a platform for doing so. Some information here: http://www.bufferbloat.net/projects/codel/wiki/Cake This is working code, albeit still under development. I’m actively dogfooding it, and I’m not the only one doing so. The Diffserv layer provides a four-class system by default, corresponding in principle with the 802.1p classes - background, best-effort, video and voice. It does not inherit the naive mapping from DSCPs to those classes, though - only CS1 (001000) is mapped to the background class. An important part of the Diffserv support in Cake is that the enhanced priority given to the video and voice classes applies only up to given shares of the overall bandwidth. If traffic in those classes exceeds that allocated share, deprioritisation occurs. This ensures that improperly marked traffic cannot starve the link, and attempts to incentivise correct marking. - Jonathan Morton ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
Hi, On 13.05.2015 at 07:01 Fred Baker (fred) wrote: >> On May 12, 2015, at 9:06 PM, Simon Barber >> wrote: >> >> Where would be the best place to see if it would be possible to >> get agreement on a global low priority DSCP? > > I’d suggest > > https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines > for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August > 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status: > INFORMATIONAL) > > It refers to > > [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 > Technical Report Proposed Service Definition, March 2001. > > (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and > states that While QBSS may have gotten more attention the original idea is here: https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00 from there it finally went to a PDB definition in RFC 3662 as you already found out, because the DiffServ chairs didn't want it to be defined as PHB. >> Within QBone, traffic marked with DSCP 001000 (binary) shall be >> considered in the QBSS class and should be given the service >> described in this document. Notice that while DSCP values >> generally have only local significance we are assigning global >> significance to this particular codepoint within QBone. We refer >> to packets marked with DSCP 001000 as being marked with the "QBSS >> code point”. > > > That’s where we came up with recommending CS1 (001000) for the > traffic class. CS1 is maybe a problem because originally (rfc 2474) CS1 means better priority than CS0. At that point in time of RFC3662 the discussion was to use CS1, because also in 802.1p 1 means "background". However, this inconsistency makes it now hard to rely on any semantics of DSCP CS1. IIRC the Diffserv chairs were opposed to spend another DSCP on LE and therefore proposed to use an existing one. In retrospect, this seems to have been a wrong decision given the problems of rtcweb and so on these days. > I’m pretty sure the latter ultimately resulted in an RFC, but for > some reason I’m not finding it. The closest thing I see is Yes, https://tools.ietf.org/html/rfc3662. Regards, Roland ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
Hi, On 13.05.2015 at 07:01 Fred Baker (fred) wrote: >> On May 12, 2015, at 9:06 PM, Simon Barber >> wrote: >> >> Where would be the best place to see if it would be possible to >> get agreement on a global low priority DSCP? > > I’d suggest > > https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines > for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August > 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status: > INFORMATIONAL) > > It refers to > > [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 > Technical Report Proposed Service Definition, March 2001. > > (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and > states that While QBSS may have gotten more attention the original idea is here: https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00 from there it finally went to a PDB definition in RFC 3662 as you already found out, because the DiffServ chairs didn't want it to be defined as PHB. >> Within QBone, traffic marked with DSCP 001000 (binary) shall be >> considered in the QBSS class and should be given the service >> described in this document. Notice that while DSCP values >> generally have only local significance we are assigning global >> significance to this particular codepoint within QBone. We refer >> to packets marked with DSCP 001000 as being marked with the "QBSS >> code point”. > > > That’s where we came up with recommending CS1 (001000) for the > traffic class. CS1 is maybe a problem because originally (rfc 2474) CS1 means better priority than CS0. At that point in time of RFC3662 the discussion was to use CS1, because also in 802.1p 1 means "background". However, this inconsistency makes it now hard to rely on any semantics of DSCP CS1. IIRC the Diffserv chairs were opposed to spend another DSCP on LE and therefore proposed to use an existing one. In retrospect, this seems to have been a wrong decision given the problems of rtcweb and so on these days. > I’m pretty sure the latter ultimately resulted in an RFC, but for > some reason I’m not finding it. The closest thing I see is Yes, https://tools.ietf.org/html/rfc3662. Regards, Roland ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
Thank you Mikeal, these are useful observations about the choice of exact DSCP value and various potential impacts. I agree that ultimately without operator agreement non of this matters. I do think that an important step towards garnering that operator agreement is to have the concerns clearly elucidated in this group's recommendations. I found a study of the interaction between low priority background techniques, including LEDBAT and AQM. http://www.enst.fr/~drossi/paper/rossi12conext.pdf it's conclusion states: "Shortly, our investigation confirms the negative interference: while AQM fixes the bufferbloat, it destroys the relative priority among Cc protocols." Apparently a significant chunk of bittorrent traffic and Windows updates use these techniques to deprioritise their traffic. Widespread adoption of AQM will remove their ability to avoid impacting the network at peak times. Use of DSCP could be one way to mitigate this problem with AQM, and this merits further study. Simon Sent with AquaMail for Android http://www.aqua-mail.com On May 13, 2015 1:47:33 AM Mikael Abrahamsson wrote: On Tue, 12 May 2015, Simon Barber wrote: > Hi John, > > Where would be the best place to see if it would be possible to get agreement > on a global low priority DSCP? Currently the general assumption among ISPs is that DSCP should be zeroed between ISPs unless there is a commercial agreement saying that it shouldn't. This is generally accepted (there are NANOG mailing list threads on several occasions in the past 5-10 years where this was the outcome). The problem is quite complex if you actually want things to act on this DSCP value, as there are devices with default behaviour is 4 queue 802.1p, with 1 and 2 (which will match AF1x and AF2x) will have lower priority than 0 and 3 (BE and AF3x), and people doing DSCP based forwarding, usually does things the other way around. It might be possible to get the last DSCP bits to map into this, because for DSCP-ignorant quipment, this would still be standard BE to something only looking at CSx (precedence), but that would be lower than 00. So DSCP 000110 (high drop BE) might work, because it's incremental. Possibly DSCP 10 (low drop BE) might be able to get some agreement because it doesn't really cause any problems in the existing networks (most likely) and it could be enabled incrementally. I would suggest bringing this kind of proposal to operator organizations and the IETF. It needs to get sold to the ISPs mostly, because in this aspect the IETF decision will mostly be empty hand-waving unless the operators do something. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
