Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
raffic that uses CS6 is likely to terminate at or close to the edge of the receiving network - see Section 3.2 of draft-geib: http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-intercon-08#section-3 I welcome any suggestions for improving that text. Thanks, --David > -Original Message- > From: Sebastian Moeller [mailto:moell...@gmx.de] > Sent: Friday, November 14, 2014 9:02 AM > To: Dave Täht > Cc: cerowrt-devel@lists.bufferbloat.net; Black, David > Subject: Re: [Cerowrt-devel] SQM: tracking some diffserv related internet > drafts better > > Hi Dave, > > I probably do not understand the topic fully, but... > > On Nov 13, 2014, at 18:26 , Dave Taht wrote: > > > This appears to be close to finalization, or finalized: > > > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > > > And this is complementary: > > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > > Oha, that's 15 priority levels (out of ~64 possible?) right there for a > browser to mark packets with depending on media type. Now, not all need to map > to real queues but that seems a lot, so that I would expect in real life a > bunch of those will map to the same queues. > If I understand correctly we already have a problems getting decent AQM > implemented at core switching/routing equipment, how realistic is it to expect > that these devices implement differential packet drop probabilities per > diffserv markings? I f the answer is not realistic the last three DS bits > become functionally equal. . Also CS1 for audio/video? I thought this to be > the scavenger class and hence not suitable for anything but bulk background > traffic if there is even the slightest contention on the path. (on second > thought this will allow to turn a CS1 internet radio in a decent congestion > monitor, if the audio skips you know the network is starting to develop > issues.). > > > > > While wading through all this is tedious, and much of the advice > contradictory, > > there are a few things that could be done more right in the sqm system > > that I'd like to discuss. (feel free to pour a cup of coffee and read > > the drafts) > > > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > > the last person that uses ssh or plays games? > > Are we free in cerowrt/SQM to just ignore this and just keep imm (CS2?) > above the best effort queue? > > > > > 0) Key to this draft is expecting that the AF code points on a single > > 5-tuple not be re-ordered, which means dumping AF41 into a priority > > queue and AF42 into the BE queue is incorrect. > > So what about sticking to the class selectors only in SQM? If I > understand correctly we can match on the CS bits only and ignore the other > bits; I think each AFNx map to the same CS(M) class. Looking at section > "4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence > Compatibility" of http://tools.ietf.org/html/rfc2474#page-11 seems to confirm > that interpretation. > > > > > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > > which I had tools doing classification, like ssh). Doing so with tc > > rules is very inefficient presently. I had basically planned on > > rolling a new tc and/or iptables filter to "do the right thing" to map > > into all 64 codepoints via a simple lookup table (as what is in the > > wifi code already), rather than use the existing mechanism... and > > hesitated > > as nobody had nailed down the definitions of each one. > > Well, "tc filter" hurts us badly as I figured out implementing filters > to look into PPP encapsulated packets to get to the TOS bits. But in theory > all tests for the individual code points can be turned into a hawh operation > in tc filter so that we only pay the price for each encapsulation type (IPv4 > IPv6, IPv$ in PPP, IPv6 in PPP, to poke through the PPP layer costs a few > additional ANDed match tests, but I really really hope that tc filter is smart > enough to stop filter processing on the first mismatch.) On my TODO list for > SQM is to use tc filter's hash functionality to process all code points in one > operation per packet. This should also allow/require mapping each of the 64 > diffserve markings to our queues so that any "ietf-recommendation-of-the-day" > can be a easily implemented by changing our mapping table... > > > > > That said, I have not measured recently the impact of the extra tc > > filters and iptables rules required. > > As far as I can tell tc filter is costly, in a "non-scientific&qu
Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
Replying to Sebastian's shorter message first ;-). > Well for cerowrt's egress queue it is nice to be able to select the > priority by modifying the DS bits of the packet as some applications can do > this directly; the alternative (bear with me here I am a layman) would be deep > packet inspection at the router with the problem that even without that the > wndrs are having a hard time routing current link speeds even without needing > to perform DPI plus I have no idea how to DPI an encrypted connection. So I > think that the use of the DS bits inside cerowrt is justified for cero's core > job as a home router. +1 - while that sort of DPI is done today (although I suspect that specialized middleboxes are more common than router integration), the encryption backlash to use and abuse of DPI (and other technologies) is only just beginning ... ... and please keep cc:'ing me, as I'm not on the cerowrt-devel list ... Thanks, --David > -Original Message- > From: Sebastian Moeller [mailto:moell...@gmx.de] > Sent: Friday, November 14, 2014 9:15 AM > To: dpr...@reed.com > Cc: Dave Täht; Black, David; cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] SQM: tracking some diffserv related internet > drafts better > > Hi David, > > On Nov 14, 2014, at 03:41 , dpr...@reed.com wrote: > > > The IETF used to require rough consensus and *working code*. The latter > seems to be out of fashion - especially with a zillion code points for which > no working code has been produced, and worse yet, no real world testing has > demonstrated any value whatsoever. > > > > It's also true that almost no actual agreements exist at peering points > about what to do at those points. That's why diffserv appears to be a lot of > energy wasted on something that has little to do with inter-networking. > > > > "intserv" was a plausible idea, because within a vertically integrated > system, one can enforce regularity and consistency. > > > > So my view, for what it is worth, is that there are a zillion better things > to put effort into than incorporating diffserv into CeroWRT! > > Well for cerowrt's egress queue it is nice to be able to select the > priority by modifying the DS bits of the packet as some applications can do > this directly; the alternative (bear with me here I am a layman) would be deep > packet inspection at the router with the problem that even without that the > wndrs are having a hard time routing current link speeds even without needing > to perform DPI plus I have no idea how to DPI an encrypted connection. So I > think that the use of the DS bits inside cerowrt is justified for cero's core > job as a home router. Whether implementing the full DS set is needed of > whether the 15 DS bits per browser will help anything is a different question, > but sincere we want to handle the bits already it should not be too much work. > (For the current SQM system we need to switch DS to queue mapping from > independent tc filter invocations to a hashed filter as we run to many filters > already and then the only additional work will be mapping 64 codes to 3 queues > instead of just 8 or so ;) ) > > > > > Cui bono? > > > > > > > > On Thursday, November 13, 2014 12:26pm, "Dave Taht" > said: > > > > > This appears to be close to finalization, or finalized: > > > > > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > > > > > And this is complementary: > > > > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > > > > > > While wading through all this is tedious, and much of the advice > contradictory, > > > there are a few things that could be done more right in the sqm system > > > that I'd like to discuss. (feel free to pour a cup of coffee and read > > > the drafts) > > > > > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > > > the last person that uses ssh or plays games? > > > > > > 0) Key to this draft is expecting that the AF code points on a single > > > 5-tuple not be re-ordered, which means dumping AF41 into a priority > > > queue and AF42 into the BE queue is incorrect. > > > > > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > > > which I had tools doing classification, like ssh). Doing so with tc > > > rules is very inefficient presently. I had basically planned on > > > rolling a new tc and/or iptables filter to "do the right thing" to map > > > into all 64 codepoints via a simple loo
Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
Hi David, On Nov 14, 2014, at 03:41 , dpr...@reed.com wrote: > The IETF used to require rough consensus and *working code*. The latter > seems to be out of fashion - especially with a zillion code points for which > no working code has been produced, and worse yet, no real world testing has > demonstrated any value whatsoever. > > It's also true that almost no actual agreements exist at peering points about > what to do at those points. That's why diffserv appears to be a lot of > energy wasted on something that has little to do with inter-networking. > > "intserv" was a plausible idea, because within a vertically integrated > system, one can enforce regularity and consistency. > > So my view, for what it is worth, is that there are a zillion better things > to put effort into than incorporating diffserv into CeroWRT! Well for cerowrt’s egress queue it is nice to be able to select the priority by modifying the DS bits of the packet as some applications can do this directly; the alternative (bear with me here I am a layman) would be deep packet inspection at the router with the problem that even without that the wndrs are having a hard time routing current link speeds even without needing to perform DPI plus I have no idea how to DPI an encrypted connection. So I think that the use of the DS bits inside cerowrt is justified for cero’s core job as a home router. Whether implementing the full DS set is needed of whether the 15 DS bits per browser will help anything is a different question, but sincere we want to handle the bits already it should not be too much work. (For the current SQM system we need to switch DS to queue mapping from independent tc filter invocations to a hashed filter as we run to many filters already and then the only additional work will be mapping 64 codes to 3 queues instead of just 8 or so ;) ) > > Cui bono? > > > > On Thursday, November 13, 2014 12:26pm, "Dave Taht" > said: > > > This appears to be close to finalization, or finalized: > > > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > > > And this is complementary: > > > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > > > > While wading through all this is tedious, and much of the advice > > contradictory, > > there are a few things that could be done more right in the sqm system > > that I'd like to discuss. (feel free to pour a cup of coffee and read > > the drafts) > > > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > > the last person that uses ssh or plays games? > > > > 0) Key to this draft is expecting that the AF code points on a single > > 5-tuple not be re-ordered, which means dumping AF41 into a priority > > queue and AF42 into the BE queue is incorrect. > > > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > > which I had tools doing classification, like ssh). Doing so with tc > > rules is very inefficient presently. I had basically planned on > > rolling a new tc and/or iptables filter to "do the right thing" to map > > into all 64 codepoints via a simple lookup table (as what is in the > > wifi code already), rather than use the existing mechanism... and > > hesitated > > as nobody had nailed down the definitions of each one. > > > > That said, I have not measured recently the impact of the extra tc > > filters and iptables rules required. > > > > 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left > > over from my test patches against mosh - mosh ran with AF42 for a > > while until they crashed a couple routers with it) > > > > The relevant lines are here: > > > > https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411 > > > > 1b) The cake code presently does it pretty wrong, which is eminately > > fixable. > > > > 1c) And given that the standards are settling, it might be time to > > start baking them into a new tc or iptables filter. This would be a > > small, interesting project for someone who wants to get their feet wet > > writing this sort of thing, and examples abound of how to do it. > > > > 2) A lot of these diffserv specs - notably all the AFxx codepoints - > > are all about variable drop probability. (Not that this concept has > > been proven to work in the real world) We don't do variable drop > > probability... and I haven't the slightest clue as to how to do it in > > fq_codel. But keeping variable diffserv codepoints in order on the > > same 5 tuple seems to be the way things are going. Still I have > > trouble folding these ideas into the 3 basic queue system fq_codel > > uses, it looks to me as most of the AF codepoints end up in the > > current best effort queue, as the priority queue is limited to 30% of > > the bandwidth by default. > > > > > > 3) Squashing inbound dscp should still be the default option... > > > > 4) My patch set to the wifi code for diffserv support disables the VO >
Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
Hi Dave, I probably do not understand the topic fully, but... On Nov 13, 2014, at 18:26 , Dave Taht wrote: > This appears to be close to finalization, or finalized: > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > And this is complementary: > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 Oha, that’s 15 priority levels (out of ~64 possible?) right there for a browser to mark packets with depending on media type. Now, not all need to map to real queues but that seems a lot, so that I would expect in real life a bunch of those will map to the same queues. If I understand correctly we already have a problems getting decent AQM implemented at core switching/routing equipment, how realistic is it to expect that these devices implement differential packet drop probabilities per diffserv markings? I f the answer is not realistic the last three DS bits become functionally equal… . Also CS1 for audio/video? I thought this to be the scavenger class and hence not suitable for anything but bulk background traffic if there is even the slightest contention on the path… (on second thought this will allow to turn a CS1 internet radio in a decent congestion monitor, if the audio skips you know the network is starting to develop issues…). > > While wading through all this is tedious, and much of the advice > contradictory, > there are a few things that could be done more right in the sqm system > that I'd like to discuss. (feel free to pour a cup of coffee and read > the drafts) > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > the last person that uses ssh or plays games? Are we free in cerowrt/SQM to just ignore this and just keep imm (CS2?) above the best effort queue? > > 0) Key to this draft is expecting that the AF code points on a single > 5-tuple not be re-ordered, which means dumping AF41 into a priority > queue and AF42 into the BE queue is incorrect. So what about sticking to the class selectors only in SQM? If I understand correctly we can match on the CS bits only and ignore the other bits; I think each AFNx map to the same CS(M) class… Looking at section "4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence Compatibility” of http://tools.ietf.org/html/rfc2474#page-11 seems to confirm that interpretation… > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > which I had tools doing classification, like ssh). Doing so with tc > rules is very inefficient presently. I had basically planned on > rolling a new tc and/or iptables filter to "do the right thing" to map > into all 64 codepoints via a simple lookup table (as what is in the > wifi code already), rather than use the existing mechanism... and > hesitated > as nobody had nailed down the definitions of each one. Well, "tc filter” hurts us badly as I figured out implementing filters to look into PPP encapsulated packets to get to the TOS bits… But in theory all tests for the individual code points can be turned into a hawh operation in tc filter so that we only pay the price for each encapsulation type (IPv4 IPv6, IPv$ in PPP, IPv6 in PPP, to poke through the PPP layer costs a few additional ANDed match tests, but I really really hope that tc filter is smart enough to stop filter processing on the first mismatch…) On my TODO list for SQM is to use tc filter’s hash functionality to process all code points in one operation per packet. This should also allow/require mapping each of the 64 diffserve markings to our queues so that any “ietf-recommendation-of-the-day” can be a easily implemented by changing our mapping table... > > That said, I have not measured recently the impact of the extra tc > filters and iptables rules required. As far as I can tell tc filter is costly, in a “non-scientific” test with netperf-wrapper’s RRUL test I saw the ICMP-CDF “robust-range” (the delay span in which the CDF went from ~5% to 95%) incase from 10ms to 30ms. No idea about the iptables rules (well, the internet seems to argue iptables being much cheaper than tc filter). > > 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left > over from my test patches against mosh - mosh ran with AF42 for a > while until they crashed a couple routers with it) Why? We could just switch to stash all CS4 packets into this queue and be compliant again to the recommendation to treat packets in each AFN set equally? > > The relevant lines are here: > > https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411 > > 1b) The cake code presently does it pretty wrong, which is eminately fixable. > > 1c) And given that the standards are settling, it might be time to > start baking them into a new tc or iptables filter. This would be a > small, interesting project for someone who wants to get their feet wet > writing this sort of thi
Re: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
The IETF used to require rough consensus and *working code*. The latter seems to be out of fashion - especially with a zillion code points for which no working code has been produced, and worse yet, no real world testing has demonstrated any value whatsoever. It's also true that almost no actual agreements exist at peering points about what to do at those points. That's why diffserv appears to be a lot of energy wasted on something that has little to do with inter-networking. "intserv" was a plausible idea, because within a vertically integrated system, one can enforce regularity and consistency. So my view, for what it is worth, is that there are a zillion better things to put effort into than incorporating diffserv into CeroWRT! Cui bono? On Thursday, November 13, 2014 12:26pm, "Dave Taht" said: > This appears to be close to finalization, or finalized: > > http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > And this is complementary: > > http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 > > While wading through all this is tedious, and much of the advice > contradictory, > there are a few things that could be done more right in the sqm system > that I'd like to discuss. (feel free to pour a cup of coffee and read > the drafts) > > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > the last person that uses ssh or plays games? > > 0) Key to this draft is expecting that the AF code points on a single > 5-tuple not be re-ordered, which means dumping AF41 into a priority > queue and AF42 into the BE queue is incorrect. > > 1) SQM only prioritizes a few diffserv codepoints (just the ones for > which I had tools doing classification, like ssh). Doing so with tc > rules is very inefficient presently. I had basically planned on > rolling a new tc and/or iptables filter to "do the right thing" to map > into all 64 codepoints via a simple lookup table (as what is in the > wifi code already), rather than use the existing mechanism... and > hesitated > as nobody had nailed down the definitions of each one. > > That said, I have not measured recently the impact of the extra tc > filters and iptables rules required. > > 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left > over from my test patches against mosh - mosh ran with AF42 for a > while until they crashed a couple routers with it) > > The relevant lines are here: > > https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411 > > 1b) The cake code presently does it pretty wrong, which is eminately fixable. > > 1c) And given that the standards are settling, it might be time to > start baking them into a new tc or iptables filter. This would be a > small, interesting project for someone who wants to get their feet wet > writing this sort of thing, and examples abound of how to do it. > > 2) A lot of these diffserv specs - notably all the AFxx codepoints - > are all about variable drop probability. (Not that this concept has > been proven to work in the real world) We don't do variable drop > probability... and I haven't the slightest clue as to how to do it in > fq_codel. But keeping variable diffserv codepoints in order on the > same 5 tuple seems to be the way things are going. Still I have > trouble folding these ideas into the 3 basic queue system fq_codel > uses, it looks to me as most of the AF codepoints end up in the > current best effort queue, as the priority queue is limited to 30% of > the bandwidth by default. > > > 3) Squashing inbound dscp should still be the default option... > > 4) My patch set to the wifi code for diffserv support disables the VO > queue almost entirely in favor of punting things to the VI queue > (which can aggregate), but I'm not sure if I handled AFxx > appropriately. > > 5) So far as I know, no browser implements any of this stuff yet. So > far as I know nobody actually deployed a router that tries to do smart > things with this stuff yet. > > 6) I really wish there were more codepoints for background traffic than cs1. > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] SQM: tracking some diffserv related internet drafts better
This appears to be close to finalization, or finalized: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 And this is complementary: http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 While wading through all this is tedious, and much of the advice contradictory, there are a few things that could be done more right in the sqm system that I'd like to discuss. (feel free to pour a cup of coffee and read the drafts) -1) They still think the old style tos imm bit is obsolete. Sigh. Am I the last person that uses ssh or plays games? 0) Key to this draft is expecting that the AF code points on a single 5-tuple not be re-ordered, which means dumping AF41 into a priority queue and AF42 into the BE queue is incorrect. 1) SQM only prioritizes a few diffserv codepoints (just the ones for which I had tools doing classification, like ssh). Doing so with tc rules is very inefficient presently. I had basically planned on rolling a new tc and/or iptables filter to "do the right thing" to map into all 64 codepoints via a simple lookup table (as what is in the wifi code already), rather than use the existing mechanism... and hesitated as nobody had nailed down the definitions of each one. That said, I have not measured recently the impact of the extra tc filters and iptables rules required. 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left over from my test patches against mosh - mosh ran with AF42 for a while until they crashed a couple routers with it) The relevant lines are here: https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411 1b) The cake code presently does it pretty wrong, which is eminately fixable. 1c) And given that the standards are settling, it might be time to start baking them into a new tc or iptables filter. This would be a small, interesting project for someone who wants to get their feet wet writing this sort of thing, and examples abound of how to do it. 2) A lot of these diffserv specs - notably all the AFxx codepoints - are all about variable drop probability. (Not that this concept has been proven to work in the real world) We don't do variable drop probability... and I haven't the slightest clue as to how to do it in fq_codel. But keeping variable diffserv codepoints in order on the same 5 tuple seems to be the way things are going. Still I have trouble folding these ideas into the 3 basic queue system fq_codel uses, it looks to me as most of the AF codepoints end up in the current best effort queue, as the priority queue is limited to 30% of the bandwidth by default. 3) Squashing inbound dscp should still be the default option... 4) My patch set to the wifi code for diffserv support disables the VO queue almost entirely in favor of punting things to the VI queue (which can aggregate), but I'm not sure if I handled AFxx appropriately. 5) So far as I know, no browser implements any of this stuff yet. So far as I know nobody actually deployed a router that tries to do smart things with this stuff yet. 6) I really wish there were more codepoints for background traffic than cs1. -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
