Re: [aqm] AQM in every buffer?
Just to clarify, this was someone else's words from the list. They don't appear in this ID. I agree with what you have said below. I personally think in addition that trying to manage every buffer isn't desirable, because using AQM implies enforcing a traffic policy (e.g. with respect to flow bustiness, no of flows and path RTT), and it would be unfortunate if this policy were embedded in all equipment, becasue it would in some cases constrain performance when there is no need. The draft motivates that key params should be externalised. Gorry > In the other long thread, gorry said something that didn't quite ring > true with me: > > "Our goal should be AQM in every buffer". > > Well, that's somewhat desirable but not doable (at least in my world) - > > 1) The device has sufficient buffering to get at least one packet out. > 2) There's a tx ring which puts packets for the device to pick up from > 3) In linux now (and some older cisco boxes) there is this thing > called "byte queue limits" which moderates the tx ring to only have > enough data in it to keep the device busy > 4) These layers gives the upper portions of the stack time to think > harder about what to put on the tx ring. > > *Ideally* an AQM should have a picture of the total buffering in the > system all the way to the wire, but in practice, at higher speeds, > once things are controlled by BQL, it's a trivial amount of extra > buffering. > > (this is partially why I get non-plussed by people dissing "drop head", > when > what's on the TX ring is already past the "drop head" point of the AQM > layer ) > > Now, I imagine that at least some hardware switches *could* have a > picture all the way to the wire, but doubt that it's feasible, also. > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > > ___ > 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] AQM in every buffer?
Just to clarify, this was someone else's words from the list. They don't appear in this ID. I agree with what you have said below. I personally think in addition that this isn't desirable, because using AQM implies enforcing a traffic policy (e.g. with respect to flow bustiness, no of flows and path RTT), and it would be unfortunate if this policy were embedded in all equipment, it would in some cases constrain performance when there is no need. The draft motivates that key params should be externalised. Gorry > In the other long thread, gorry said something that didn't quite ring > true with me: > > "Our goal should be AQM in every buffer". > > Well, that's somewhat desirable but not doable (at least in my world) - > > 1) The device has sufficient buffering to get at least one packet out. > 2) There's a tx ring which puts packets for the device to pick up from > 3) In linux now (and some older cisco boxes) there is this thing > called "byte queue limits" which moderates the tx ring to only have > enough data in it to keep the device busy > 4) These layers gives the upper portions of the stack time to think > harder about what to put on the tx ring. > > *Ideally* an AQM should have a picture of the total buffering in the > system all the way to the wire, but in practice, at higher speeds, > once things are controlled by BQL, it's a trivial amount of extra > buffering. > > (this is partially why I get non-plussed by people dissing "drop head", > when > what's on the TX ring is already past the "drop head" point of the AQM > layer ) > > Now, I imagine that at least some hardware switches *could* have a > picture all the way to the wire, but doubt that it's feasible, also. > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > > ___ > 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] AQM in every buffer?
In the other long thread, gorry said something that didn't quite ring true with me: "Our goal should be AQM in every buffer". Well, that's somewhat desirable but not doable (at least in my world) - 1) The device has sufficient buffering to get at least one packet out. 2) There's a tx ring which puts packets for the device to pick up from 3) In linux now (and some older cisco boxes) there is this thing called "byte queue limits" which moderates the tx ring to only have enough data in it to keep the device busy 4) These layers gives the upper portions of the stack time to think harder about what to put on the tx ring. *Ideally* an AQM should have a picture of the total buffering in the system all the way to the wire, but in practice, at higher speeds, once things are controlled by BQL, it's a trivial amount of extra buffering. (this is partially why I get non-plussed by people dissing "drop head", when what's on the TX ring is already past the "drop head" point of the AQM layer ) Now, I imagine that at least some hardware switches *could* have a picture all the way to the wire, but doubt that it's feasible, also. -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
