[Cake] ieee vs ietf stds for dscp mappings

[Cake] ieee vs ietf stds for dscp mappings

[Dave Taht]

https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11e-01

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

Re: [Cake] ieee vs ietf stds for dscp mappings

[Dave Taht]

Just to keep confusing matters

https://tools.ietf.org/html/rfc7561#section-4.2
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Sat, Nov 14, 2015 at 1:42 PM, Dave Taht <dave.taht@gmail.com> wrote:
> https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11e-01
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi

Re: [Cake] ieee vs ietf stds for dscp mappings

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]


> On 14 Nov, 2015, at 14:43, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Just to keep confusing matters

Yeah, Diffserv is a complete and utter mess, isn’t it?


[-- Attachment #2: Untitled.pdf --]
[-- Type: application/pdf, Size: 39667 bytes --]

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


 - Jonathan Morton

Re: [Cake] ieee vs ietf stds for dscp mappings

[Dave Taht]

very good document. You should (or I can) forward it to the relevant lists.
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Sat, Nov 14, 2015 at 2:55 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 14 Nov, 2015, at 14:43, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Just to keep confusing matters
>
> Yeah, Diffserv is a complete and utter mess, isn’t it?
>
>
>
>  - Jonathan Morton
>
>

Re: [Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

Is anybody actually using any of that? The set of differences between the schemes as RFCd for the different technologies makes me believe nobody is ever using more than one of those domains. In my ignorance (as it is well known people completely out of their depth often feel they really understand complex issues, and their simplistic solutions are really great and thoughtful; I am no exception to that rule) I think the best thing to do would be define a reasonable set of 3 bits for our own use, and map these following one underlaying rationale to how many priority tiers we want to use. I would argue for leaving all legacy mappings behind… I believe the idea, I picked up in one of the email conversations on this list? (it certain is not my original idea, even though I forgot where I picked it up) to preserve the incoming markings (as good as possible in 3 bits) and restore them once/if the packet leaves our dscp domain again seems like the decent thing to do...
	On the wifi-side my limited understanding of the access rules tell me, that allowing clients to pick their qos marking can and will starve the AP of TxOps, so unless the AP can enforce a unified tier for all clients the AP should, in my humble opinion, actually pick its own marking (and medium access probability) adaptively, depending on what the clients use, in a nice BE environment stick to BE but if the clients start sending too many packets in the two higher classes (dynamically measured threshold might be required) the AP should up its game and switch its own packets to the same class. My rationale is that the AP is going to have a better vantage point of the competing clients and hence should be in a better position to guarantee some sort of fairness, than any one client. Since this seems so simple, there probably is a very good technical reason why this can not work, that I am just unable to see.

Best Regards
	Sebastian



On Nov 14, 2015, at 14:55 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 14 Nov, 2015, at 14:43, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> Just to keep confusing matters
> 
> Yeah, Diffserv is a complete and utter mess, isn’t it?
> 

[-- Attachment #2: Untitled.pdf --]
[-- Type: application/pdf, Size: 39667 bytes --]

[-- Attachment #3: Type: text/plain, Size: 172 bytes --]

> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] ieee vs ietf stds for dscp mappings

[Jonathan Morton]

> On 14 Nov, 2015, at 17:53, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Is anybody actually using any of that? The set of differences between the schemes as RFCd for the different technologies makes me believe nobody is ever using more than one of those domains.

That’s part of the problem.  The various recommendations conflict with each other and with actual practice.

Note in particular the different treatments just of CS0 (default, and defined as Best Effort) and CS1 (defined as Background Traffic) - RFC 7561 actually gets them backwards!  The Szigeti-Baker draft is relatively sane and comprehensive, even though it differs from Cake’s schema in detail.

The core of the problem is that Diffserv was originally specified without a complete, working implementation of its PHBs (Per Hop Behaviours).  AFAIK, no such implementation exists to date - certainly no public one.  So there are ad-hoc, locally-defined approximations all over the place, and my chart illustrates some of that.

As well as the PHBs being poorly defined, it has become general practice for *networks* to set the DSCPs on traffic passing through them, rather than applications setting them at the endpoints.  This makes it difficult for applications to express their traffic characteristics and transport needs in general.  However, I think this practice has arisen because applications have not bothered to set their own DSCPs, due to their having no effect in most networks.

Dave noted previously that a lot of traffic gets marked as CS1 in Comcast’s network.  I’ve recently noticed the same about the Elisa/Saunalahti network over here, having got myself a 4G-capable receiver that came with a prepaid 1-month Saunalahti SIM.  DNA, my usual network, does something different - not sure whether it just doesn’t bother changing DSCPs, or does something more complex.

 - Jonathan Morton

Re: [Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

Hi Jonathan,

thanks for the long reply.

On Nov 14, 2015, at 17:46 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 14 Nov, 2015, at 17:53, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Is anybody actually using any of that? The set of differences between the schemes as RFCd for the different technologies makes me believe nobody is ever using more than one of those domains.
> 
> That’s part of the problem.  The various recommendations conflict with each other and with actual practice.

	That is the base for my hypothesis that they are not used in conjunction, as that would not work too well. On the other hand maybe it works good enough/ better than without DSCP so people might just not care about the fine print?

> 
> Note in particular the different treatments just of CS0 (default, and defined as Best Effort) and CS1 (defined as Background Traffic) - RFC 7561 actually gets them backwards!  The Szigeti-Baker draft is relatively sane and comprehensive, even though it differs from Cake’s schema in detail.
> 
> The core of the problem is that Diffserv was originally specified without a complete, working implementation of its PHBs (Per Hop Behaviours).  AFAIK, no such implementation exists to date - certainly no public one.  So there are ad-hoc, locally-defined approximations all over the place, and my chart illustrates some of that.
> 
> As well as the PHBs being poorly defined, it has become general practice for *networks* to set the DSCPs on traffic passing through them, rather than applications setting them at the endpoints.  This makes it difficult for applications to express their traffic characteristics and transport needs in general.  However, I think this practice has arisen because applications have not bothered to set their own DSCPs, due to their having no effect in most networks.

	Well any equipment actually looking at the DSCP will need to consider whether the network owner approved of that marking. In other swords it might make a lot of sense to separate the 6b bits into 2 groups of 3 bits, one group for the current network’s effective markings and three for the endpoints to signal their intent. I realize that this still has the issue that one needs to trust the upstream enough to not have fudged the intent bits… but at least this idea realizes that the 6 bits have different parties interested in using them… I guess the only solution for the trust thing is a tunneled connection, then one only needs to trust the sender to accept the encrypted IP header’s DSCP markings.

> 
> Dave noted previously that a lot of traffic gets marked as CS1 in Comcast’s network.  I’ve recently noticed the same about the Elisa/Saunalahti network over here, having got myself a 4G-capable receiver that came with a prepaid 1-month Saunalahti SIM.  DNA, my usual network, does something different - not sure whether it just doesn’t bother changing DSCPs, or does something more complex.

	It might just do proper hygiene and rem app everything to DSCP 0 as not to leak internal network details outside DNA’s own network; I believe this is a functionality cake hold learn (I think Kevin implemented a branch allowing that…)

Best Regards
	Sebastian

> 
> - Jonathan Morton
> 

Re: [Cake] ieee vs ietf stds for dscp mappings

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> writes:

> 	On the wifi-side my limited understanding of the access rules tell me,
> that allowing clients to pick their qos marking can and will starve the AP of
> TxOps, so unless the AP can enforce a unified tier for all clients the AP
> should, in my humble opinion, actually pick its own marking (and medium access
> probability) adaptively, depending on what the clients use, in a nice BE
> environment stick to BE but if the clients start sending too many packets in the
> two higher classes (dynamically measured threshold might be required) the AP
> should up its game and switch its own packets to the same class. My rationale is
> that the AP is going to have a better vantage point of the competing clients and
> hence should be in a better position to guarantee some sort of fairness, than
> any one client. Since this seems so simple, there probably is a very good
> technical reason why this can not work, that I am just unable to see.

The problem with WiFi is that there are actually two effects of QoS:
There's the priority queueing (i.e. the four 802.11e queues work as
strict priority queues), and there's the retransmission and back-off
behaviour associated with each of the tiers.

The latter is what can cause starvation for other clients: Because
the transmission and back-off settings for the "latency-sensitive"
queues (VO and VI) are more aggressive, they will tend to starve out
other things. However, it's not guaranteed that the AP can detect that
this is happening (it would just see a lot of collisions). You could try
to infer it by looking at the markings of the packets, but in principle
there's no reason why a client can't use more aggressive transmission
settings for packets that are not diffserv marked at the IP layer.

-Toke

Re: [Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

Hi Toke,

On Nov 15, 2015, at 15:52 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> 	On the wifi-side my limited understanding of the access rules tell me,
>> that allowing clients to pick their qos marking can and will starve the AP of
>> TxOps, so unless the AP can enforce a unified tier for all clients the AP
>> should, in my humble opinion, actually pick its own marking (and medium access
>> probability) adaptively, depending on what the clients use, in a nice BE
>> environment stick to BE but if the clients start sending too many packets in the
>> two higher classes (dynamically measured threshold might be required) the AP
>> should up its game and switch its own packets to the same class. My rationale is
>> that the AP is going to have a better vantage point of the competing clients and
>> hence should be in a better position to guarantee some sort of fairness, than
>> any one client. Since this seems so simple, there probably is a very good
>> technical reason why this can not work, that I am just unable to see.
> 
> The problem with WiFi is that there are actually two effects of QoS:
> There's the priority queueing (i.e. the four 802.11e queues work as
> strict priority queues), and there's the retransmission and back-off
> behaviour associated with each of the tiers.

	Sure, not necessarily the best design, conflating two nominally orthogonal dimensions, no?

> 
> The latter is what can cause starvation for other clients: Because
> the transmission and back-off settings for the "latency-sensitive"
> queues (VO and VI) are more aggressive, they will tend to starve out
> other things.

	Yes, rrul tests between my macbook and my wndr3700v2 show this starvation issue nicely, the AP only gets the occasional TxOP… 

> However, it's not guaranteed that the AP can detect that
> this is happening (it would just see a lot of collisions).

	How not, in a non-ad-hoc network the AP should be able to see all packets, no? (Okay maybe not packets from other APs, is the wifi header encrypted?)

> You could try
> to infer it by looking at the markings of the packets,

	Yes, in its own network an AP (at least its wifi driver) should see the marking of all packets and hence should be able to tally them, I believe.

> but in principle
> there's no reason why a client can't use more aggressive transmission
> settings for packets that are not diffserv marked at the IP layer.

	Sure, but since (currently) wifi is half-duplex, that more aggressive transmission by one client is going to bring down the cumulative bandwidth for all connected clients. So I see this ripe for gaming, the one aggressive client gets a much larger share of a reduced bandwidth pool while everyone else is going to suffer, including the AP. Under the assumption that the AP is going to be the arbiter in the wireless network (due to its vantage point) I beleve the AP needs to compete aggressively for TxOPs itself, otherwise all fairness/control is lost. Now, if one controls all clients and one is certain that no client is going to game the system, the AP can stay “passive”, but that is a classic example for differences between cooperative and preemptive “multitasking/resource-sharing” the first works better in the good cases but is easily gamed by noncooperative behavior of individual “players” while the second sacrifices some best case performance” for a much better defined worst-case performance (at least that is my layman’s understanding of the trade-offs between the two).
	In the wifi case , I might add the co-operation approach is hindered by the fact that several APs / wireless networks might share the same frequency and hence TxOPs… As always, most likely I am missing relevant knowhow to realize the obvious ;)


Best Regards
	Sebastian
> 
> -Toke

Re: [Cake] ieee vs ietf stds for dscp mappings

[Stephen Hemminger]

On Sun, 15 Nov 2015 15:52:40 +0100
Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
> > 	On the wifi-side my limited understanding of the access rules tell me,
> > that allowing clients to pick their qos marking can and will starve the AP of
> > TxOps, so unless the AP can enforce a unified tier for all clients the AP
> > should, in my humble opinion, actually pick its own marking (and medium access
> > probability) adaptively, depending on what the clients use, in a nice BE
> > environment stick to BE but if the clients start sending too many packets in the
> > two higher classes (dynamically measured threshold might be required) the AP
> > should up its game and switch its own packets to the same class. My rationale is
> > that the AP is going to have a better vantage point of the competing clients and
> > hence should be in a better position to guarantee some sort of fairness, than
> > any one client. Since this seems so simple, there probably is a very good
> > technical reason why this can not work, that I am just unable to see.  
> 
> The problem with WiFi is that there are actually two effects of QoS:
> There's the priority queueing (i.e. the four 802.11e queues work as
> strict priority queues), and there's the retransmission and back-off
> behaviour associated with each of the tiers.
> 
> The latter is what can cause starvation for other clients: Because
> the transmission and back-off settings for the "latency-sensitive"
> queues (VO and VI) are more aggressive, they will tend to starve out
> other things. However, it's not guaranteed that the AP can detect that
> this is happening (it would just see a lot of collisions). You could try
> to infer it by looking at the markings of the packets, but in principle
> there's no reason why a client can't use more aggressive transmission
> settings for packets that are not diffserv marked at the IP layer.

In my experience with customers, they tend to put in hard
policing limits for any of the latency sensitive queues. I.e if the network
is 100mbit, they put in a policer to drop traffic over some limit (typically 25%
of the bandwidth). That way they are guaranteed to not stave regular classes.

Re: [Cake] ieee vs ietf stds for dscp mappings

[Jonathan Morton]

> On 15 Nov, 2015, at 23:20, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> typically 25% of the bandwidth

Coincidentally, this is also the threshold at which Cake deprioritises the “Voice" tin.

 - Jonathan Morton

Re: [Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

Hello Stephen,

On Nov 15, 2015, at 22:20 , Stephen Hemminger <stephen@networkplumber.org> wrote:

> On Sun, 15 Nov 2015 15:52:40 +0100
> Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> 	On the wifi-side my limited understanding of the access rules tell me,
>>> that allowing clients to pick their qos marking can and will starve the AP of
>>> TxOps, so unless the AP can enforce a unified tier for all clients the AP
>>> should, in my humble opinion, actually pick its own marking (and medium access
>>> probability) adaptively, depending on what the clients use, in a nice BE
>>> environment stick to BE but if the clients start sending too many packets in the
>>> two higher classes (dynamically measured threshold might be required) the AP
>>> should up its game and switch its own packets to the same class. My rationale is
>>> that the AP is going to have a better vantage point of the competing clients and
>>> hence should be in a better position to guarantee some sort of fairness, than
>>> any one client. Since this seems so simple, there probably is a very good
>>> technical reason why this can not work, that I am just unable to see.  
>> 
>> The problem with WiFi is that there are actually two effects of QoS:
>> There's the priority queueing (i.e. the four 802.11e queues work as
>> strict priority queues), and there's the retransmission and back-off
>> behaviour associated with each of the tiers.
>> 
>> The latter is what can cause starvation for other clients: Because
>> the transmission and back-off settings for the "latency-sensitive"
>> queues (VO and VI) are more aggressive, they will tend to starve out
>> other things. However, it's not guaranteed that the AP can detect that
>> this is happening (it would just see a lot of collisions). You could try
>> to infer it by looking at the markings of the packets, but in principle
>> there's no reason why a client can't use more aggressive transmission
>> settings for packets that are not diffserv marked at the IP layer.
> 
> In my experience with customers, they tend to put in hard
> policing limits for any of the latency sensitive queues. I.e if the network
> is 100mbit, they put in a policer to drop traffic over some limit (typically 25%
> of the bandwidth). That way they are guaranteed to not stave regular classes.

	Thank you very much for that information. How does this work, in a hem network environment in a dense neighborhood? In my home network I invite/allow my friend’s machines in, over which I have no control; also since wifi uses a shared medium and there are several APs around using the same 2.4GHz channels (there is like three competing APs in each of the useable bands, 1, 6, and 13, 5GHz is better though), I have no handle on what bandwidth is going to be available for me, nor how much of that bandwidth is used by others. (Also one of my SSIDs is open and unencrypted, something I would like more people to offer, but that ensures that I basically can nt trust even machines the are connected to my AP to behave friendly, so “all stations are hostile” is my default MO.)
 	I guess the point I am arguing is not that this can not be made to work in a controlled environment, but rather that most/many real world networks do not operate in a controlled environment, so I wold not be unhappy if my AP played temporally averaged tit-for-tat: start nicely as BE but escalate to VO or VI if the “competition” makes this a better strategy. 
	I have seen myself that one machine using VI and VO markings can make all machines on the same AP  pay a severe bandwidth and latency price (including the APs traffic to the stations, damn half-dplexicity). I can live well with the decreased bandwidth , but I dislike the increased latency ;) So I believe an AP with an adaptive strategy will work better (for my definition f good obviously). Since I do this as a hobby there is a more than decent chance that I am just missing the obvious, thinking myself way more knowledgeable about the issue at hand than I am.

Best Regards
	Sebastian