[Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

And seems likely to be adopted.

There seems to be an urge to make this codepoint starvable, which
since I ascribe to nagle's dictum "every application has a right to
one packet in the network" - doesn't work for me - but the draft is
vaguely worded enough to just start dumping this codepoint into the
background queue of both sqm and cake and worry about it in a decade
or three.

it's 000001 which I guess is:

diff --git a/sch_cake.c b/sch_cake.c
index 3a26db0..67263b3 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
 };

 static const u8 diffserv3[] = {
-       0, 0, 0, 0, 2, 0, 0, 0,
+       0, 1, 0, 0, 2, 0, 0, 0,
        1, 0, 0, 0, 0, 0, 0, 0,
        0, 0, 0, 0, 0, 0, 0, 0,
        0, 0, 0, 0, 0, 0, 0, 0,

(or is that reversed? my big endian/little endian chops scuks, and
nobody modified the gen_cake_const tool to match what cake expects
now)

on my off days I kind of wish the diffserv lookup we do in cake had
managed to make it into the linux mqprio/prio stuff by default.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Jonathan Morton]

> On 3 Feb, 2019, at 8:39 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> it's 000001 which I guess is:
> 
> diff --git a/sch_cake.c b/sch_cake.c
> index 3a26db0..67263b3 100644
> --- a/sch_cake.c
> +++ b/sch_cake.c
> @@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
> };
> 
> static const u8 diffserv3[] = {
> -       0, 0, 0, 0, 2, 0, 0, 0,
> +       0, 1, 0, 0, 2, 0, 0, 0,
>        1, 0, 0, 0, 0, 0, 0, 0,
>        0, 0, 0, 0, 0, 0, 0, 0,
>        0, 0, 0, 0, 0, 0, 0, 0,
> 
> (or is that reversed? my big endian/little endian chops scuks, and
> nobody modified the gen_cake_const tool to match what cake expects
> now)

That looks correct to me, though it should also be added to the other Diffserv modes including a bulk tin.  Fields in TCP/IP are all laid out in "network order" which is most-significant bit/byte first, the same way you'd *normally* write a number down.

The TOS field can sometimes be confusing because the DSCP field is the upper 6 bits and the ECN field the lower 2, and the BSD Sockets API gives you the while byte to work with while DSCPs are quoted as just their own 6 bits.  So you have to shift the latter left two bits before applying them to the former.

 - Jonathan Morton

Re: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[David P. Reed]

Well, you all know that I think of diffserv as an abortion. It's based on thinking that assumes central, hierachical adminstrative agreements among what should be autonomous systems.

Yeah, at layer 2 for packets that stay within an administratively uniform domain, diffserv can be useful.

But even "Paris Metro" scheduling (2 classes, priced dynamically) is highly unstable.

And the nature of networks is that they MUST operate almost all the time well below their capacity. (This is true of packet nets, railroads, highways, ...). It's called the "Mother's Day problem". When Mother's Day happens, you should have enough capacity to absorb vast demand. Therefore what you do all the other days doesn't matter. And on Mother's Day, if you have congestion, there's no way in hell that anybody is happy.

This fairy story about traffic giving way to higher priority traffic being a normal mode of operation is just that. A made up story, largely used by folks who want to do selective pricing based on what customers are willing to pay, not on value received. (that's a business story, thouhg - like the Xerox machines that were supposed to charge more for billion dollar real estate contract copies and less for notices to put up near coffee machines - Xerox wanted a share of the real-estate business cash flow).

Which doesn't mean that there might not be better ways to do large scale traffic engineering balancing of flows - but that's not an end-to-end problem. It's a network management problem that involves changing routing tables.

-----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Sunday, February 3, 2019 1:39pm
To: "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>, "Cake List" <cake@lists.bufferbloat.net>
Subject: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

And seems likely to be adopted.

There seems to be an urge to make this codepoint starvable, which
since I ascribe to nagle's dictum "every application has a right to
one packet in the network" - doesn't work for me - but the draft is
vaguely worded enough to just start dumping this codepoint into the
background queue of both sqm and cake and worry about it in a decade
or three.

it's 000001 which I guess is:

diff --git a/sch_cake.c b/sch_cake.c
index 3a26db0..67263b3 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
 };

 static const u8 diffserv3[] = {
-       0, 0, 0, 0, 2, 0, 0, 0,
+       0, 1, 0, 0, 2, 0, 0, 0,
        1, 0, 0, 0, 0, 0, 0, 0,
        0, 0, 0, 0, 0, 0, 0, 0,
        0, 0, 0, 0, 0, 0, 0, 0,

(or is that reversed? my big endian/little endian chops scuks, and
nobody modified the gen_cake_const tool to match what cake expects
now)

on my off days I kind of wish the diffserv lookup we do in cake had
managed to make it into the linux mqprio/prio stuff by default.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

On Sun, Feb 3, 2019 at 2:42 PM David P. Reed <dpreed@deepplum.com> wrote:
>
> Well, you all know that I think of diffserv as an abortion. It's based on thinking that assumes central, hierachical adminstrative agreements among what should be autonomous systems.

I too think diffserv is terrible. On the other hand, I do think there
is room for 4 levels of priority in a network - priority (for packets
like link layer control and urgent network/maint packets), best
effort, background, and - as this specifies - least effort.

Cake, I think, makes the best possible tradeoffs by layering the
diffserv spec into 3 or 4 priorities by default, and optimizing for
"sparse" flows always. Even without diffserv it accomplishes what's
needed.

It would have been nice to have more bits for ECN and less for diffserv.

> Yeah, at layer 2 for packets that stay within an administratively uniform domain, diffserv can be useful.

The problem with repurposing CS1 for "background" is that many
networks to this day give CS1 more priority than CS0. So the new LE
codepoint - so long as it is not treated as "starve this" e2e - seems
useful.

>
> But even "Paris Metro" scheduling (2 classes, priced dynamically) is highly unstable.

If you would like to evaluate these

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/

it would help. Earlier this month I plowed through the current state
of this and decided that it was perhaps, time, to
pursue the "some congestion experienced" and ELR proposals jonathan
had for the ECN bits.

> And the nature of networks is that they MUST operate almost all the time well below their capacity. (This is true of packet nets, railroads, highways, ...). It's called the "Mother's Day problem". When Mother's Day happens, you should have enough capacity to absorb vast demand. Therefore what you do all the other days doesn't matter. And on Mother's Day, if you have congestion, there's no way in hell that anybody is happy.
>
> This fairy story about traffic giving way to higher priority traffic being a normal mode of operation is just that. A made up story, largely used by folks who want to do selective pricing based on what customers are willing to pay, not on value received. (that's a business story, thouhg - like the Xerox machines that were supposed to charge more for billion dollar real estate contract copies and less for notices to put up near coffee machines - Xerox wanted a share of the real-estate business cash flow).

That's a great background story. Got a source?

> Which doesn't mean that there might not be better ways to do large scale traffic engineering balancing of flows - but that's not an end-to-end problem. It's a network management problem that involves changing routing tables.
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Sunday, February 3, 2019 1:39pm
> To: "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>, "Cake List" <cake@lists.bufferbloat.net>
> Subject: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call
>
> And seems likely to be adopted.
>
> There seems to be an urge to make this codepoint starvable, which
> since I ascribe to nagle's dictum "every application has a right to
> one packet in the network" - doesn't work for me - but the draft is
> vaguely worded enough to just start dumping this codepoint into the
> background queue of both sqm and cake and worry about it in a decade
> or three.
>
> it's 000001 which I guess is:
>
> diff --git a/sch_cake.c b/sch_cake.c
> index 3a26db0..67263b3 100644
> --- a/sch_cake.c
> +++ b/sch_cake.c
> @@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
>  };
>
>  static const u8 diffserv3[] = {
> -       0, 0, 0, 0, 2, 0, 0, 0,
> +       0, 1, 0, 0, 2, 0, 0, 0,
>         1, 0, 0, 0, 0, 0, 0, 0,
>         0, 0, 0, 0, 0, 0, 0, 0,
>         0, 0, 0, 0, 0, 0, 0, 0,
>
> (or is that reversed? my big endian/little endian chops scuks, and
> nobody modified the gen_cake_const tool to match what cake expects
> now)
>
> on my off days I kind of wish the diffserv lookup we do in cake had
> managed to make it into the linux mqprio/prio stuff by default.
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Jonathan Morton]

> On 4 Feb, 2019, at 12:42 am, David P. Reed <dpreed@deepplum.com> wrote:
> 
> This fairy story about traffic giving way to higher priority traffic being a normal mode of operation is just that. A made up story, largely used by folks who want to do selective pricing based on what customers are willing to pay, not on value received.

Honestly, I can believe that selective pricing was the original motivation behind Diffserv (and the older TOS definition).  I think it probably originated from the way telegrams were handled at the time.

In telegraph networks, there is a real cost to handling each message, because traffic volume correlates directly with the number of human operators involved.  The telegraph network was therefore perpetually congested, as the network sought to balance costs and revenue.

In modern packet-switched networks, it's traffic *capacity* which bears a *capital* cost, not so much in terms of running maintenance costs.  That's where the difference lies; in the latter case, selective pricing leads to perverse incentives in that inducing congestion can lead to higher revenue without higher costs, but with poorer service delivered.

Hence the present fight over Net Neutrality and, perhaps, the resistance of hardware manufacturers to properly tackling bufferbloat.  After all, if congestion doesn't lead to obvious signs of poor performance, there is less incentive to buy newer and faster network hardware and/or service plans.

> When Mother's Day happens, you should have enough capacity to absorb vast demand. Therefore what you do all the other days doesn't matter. And on Mother's Day, if you have congestion, there's no way in hell that anybody is happy.

You're clearly looking at this from a core-network perspective - which has its place.  My philosophy on core and backhaul networks is that they should be sized so that congestion is rare, and they should *also* degrade gracefully when congestion does in fact occur.  Application of simple AQM algorithms, to keep latency low and spread the pain more-or-less fairly, seems sufficient there.

Last-mile links have different characteristics; they spend long periods completely idle, and also significant periods completely saturated.  That's because they don't have the high degree of statistical multiplexing that you see deeper in the network.  This is, therefore, where putting intelligence into the network has maximum advantage - hence the all-singing, all-dancing design of Cake.

Consumer ISPs tend to run their backhaul networks much fuller on average than the core.  Some are congested as much as 50% of the time; most are reliably congested at certain times of the day or week, and performance degrades noticeably when exceptional demand occurs (such as a sporting event or newsworthy disaster, or simply the release of a blockbuster AAA game).  Whatever the reason, these networks are *not* prepared for Mother's Day.

Diffserv, as currently specified, does not reliably help.  It is too rarely implemented, by either consumer-grade ISPs, CPE or applications, to gain much traction.  Cake's interpretation is starting to trickle into CPE, but it's too soon to tell whether that'll have much practical effect.

And you're right that strict priority is the wrong approach - it's too easy to abuse.  That's why Cake doesn't do strict priority, and actively tries to avoid starving any class of traffic.

In my view, there are just four classes of traffic with global meaning, though additional classes may have local meaning:

 - High Throughput; what we now call Best Effort.  Latency and packet loss are relatively minor concerns for this traffic.

 - Low Latency; throughput and packet loss are less important than immediacy.  Attempting high throughput in this class should be penalised, so that overall throughput is less under congested conditions than if High Throughput were requested; this forms a natural incentive to choose the correct class for the traffic.

 - High Reliability; packet loss would hurt performance more than latency or throughput limitations.  This might be suitable for simple request-response protocols such as DNS.  Long queues with fairness metrics are appropriate here, with a similar throughput handicap as Low Latency.

 - Low Priority; this traffic volunteers to "get out of the way" when congestion occurs.  It receives a relatively small guaranteed throughput under congested conditions, but may fill otherwise-unused capacity when the situation eases.

If networks were widely designed to respect and preserve these four classifications of traffic, which could be represented using a two-bit codepoint rather than the present six bits, I'm certain that applications would start to use those classes appropriately.  Expanding to three bits would allow representing locally-valid traffic classes such as Network Control and Isochronous Audio/Video, which might reasonably have strict priority over the global classes but which Should Not be sent over the core network, and Should be interpreted as Low Priority if encountered by a device not specifically configured to understand them.

 - Jonathan Morton

Re: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Mikael Abrahamsson]

On Sun, 3 Feb 2019, David P. Reed wrote:

> This fairy story about traffic giving way to higher priority traffic 
> being a normal mode of operation is just that. A made up story, largely 
> used by folks who want to do selective pricing based on what customers 
> are willing to pay, not on value received. (that's a business story,

The point of PHB LE is so that the customer access shaper can background 
the customer LE traffic. It's not intended to be used by ISPs on their 
core links, it's intended for use on the customer access port.

If the customer buys 10 megabit/s Internet access then it's beneficial for 
the customer if the software update download doesn't affect the netflix 
stream and the kids' gameplay. Thus why we're trying to differentiate 
between BE and LE. FQ or CAKE can solve the gameplay, but it can't make 
the netflix stream get 90% of the rest of the capacity and give 5% to the 
software download. LE marking the software download traffic can do that.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

Mikael Abrahamsson <swmike@swm.pp.se> writes:

> On Sun, 3 Feb 2019, David P. Reed wrote:
>
>> This fairy story about traffic giving way to higher priority traffic
>> being a normal mode of operation is just that. A made up story,
>> largely used by folks who want to do selective pricing based on what
>> customers are willing to pay, not on value received. (that's a
>> business story,
>
> The point of PHB LE is so that the customer access shaper can
> background the customer LE traffic. It's not intended to be used by
> ISPs on their core links, it's intended for use on the customer access
> port.
>
> If the customer buys 10 megabit/s Internet access then it's beneficial
> for the customer if the software update download doesn't affect the
> netflix stream and the kids' gameplay. Thus why we're trying to
> differentiate between BE and LE. FQ or CAKE can solve the gameplay,
> but it can't make the netflix stream get 90% of the rest of the
> capacity and give 5% to the software download. LE marking the software
> download traffic can do that.

Well, (I just checked, let me know if you want the captures) comcast
still re-marks all codepoints it does not recognize, to become CS1,
including this one. So the smartest thing a comcast customer can do is
wash it out on entrance to their domain.

The second problem with LE in this direction is that you AND your
software download provider have to trust your ISP to not A) remark this
traffic B) maltreat it by introducing starvation tactics.

In the US, at least, there is no trust of the ISP to be had and it is
best to not mark your traffic at all. I don't think trust can ever be
obtained, here, at least.

Within and exiting your home domain, you might have some hope, but even
then I might lean to washing out your markings pending the death of NN.
(I have no idea how comcast's remarking policy escaped NN litigation in
the first place)

The best that I think can be hoped for is that your netflix stream gets
50% and your download 50% in this two host example. Which is what cake
does, without markings, and why the wash option exists in cake.

Certainly I'd like to see multi-stream downloads for non-critical
things like steam die a horrible death, and I'd like uploads to places
like dropbox to not kill your network.

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Mikael Abrahamsson]

On Sun, 3 Feb 2019, Dave Taht wrote:

> Well, (I just checked, let me know if you want the captures) comcast 
> still re-marks all codepoints it does not recognize, to become CS1, 
> including this one. So the smartest thing a comcast customer can do is 
> wash it out on entrance to their domain.

If I didn't think we ever could change things, I wouldn't support 
documents like these.

The idea is to go to the ISP community and say "Please treat LE as BE in 
your core/peering links, and only act on it on the customer access shaper 
(optional). Please don't bleach it."

000001 has never been in use before, so the hope is that people will allow 
this to happen. CS1 has had different meanings over time so it's harder to 
handle.

The problem with CAKE/FQ and background traffic is that it can't tell if 
there is congestion or not, and things like LEDBAT can't backoff and try 
to avoid causing congestion. So your previous email about allowing some 
congestion to take place on LE would be good as then protocols that try to 
avoid causing congestion would have a way to do so.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

On Sun, Feb 3, 2019 at 11:11 PM Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> On Sun, 3 Feb 2019, Dave Taht wrote:
>
> > Well, (I just checked, let me know if you want the captures) comcast
> > still re-marks all codepoints it does not recognize, to become CS1,
> > including this one. So the smartest thing a comcast customer can do is
> > wash it out on entrance to their domain.
>
> If I didn't think we ever could change things, I wouldn't support
> documents like these.

I support this document. I note sqm and cake are the *only* QOS
systems out there that have ever bothered to pay attention to the
diffserv standards. I don't think netduma's "anti-bufferbloat" does,
nor does the mq, prio, etc qdiscs in linux.


>
> The idea is to go to the ISP community and say "Please treat LE as BE in
> your core/peering links, and only act on it on the customer access shaper
> (optional). Please don't bleach it."

It's not a please. It's a three way contract with network services,
isps, and users. And of these, the users request should be paramount.

short of a lawsuit I don't see any way comcast can be coerced to
remove the *one* line in their cmts config files that remarks traffic.
... but hey, miracles happen.

passing CS1 through to wifi really sucks. Bleaching all diffserv from
comcast at the edge makes sense until that miracle happens.

>
> 000001 has never been in use before, so the hope is that people will allow
> this to happen. CS1 has had different meanings over time so it's harder to
> handle.

I agree. CS1 has caused no end of trouble for a good idea.

> The problem with CAKE/FQ and background traffic is that it can't tell if
> there is congestion or not, and things like LEDBAT can't backoff and try
> to avoid causing congestion. So your previous email about allowing some
> congestion to take place on LE would be good as then protocols that try to
> avoid causing congestion would have a way to do so.

I do not like that the standard allows for total starvation. I would
prefer it had a minimum of 5%.

>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Mikael Abrahamsson]

On Mon, 4 Feb 2019, Dave Taht wrote:

>> The problem with CAKE/FQ and background traffic is that it can't tell if
>> there is congestion or not, and things like LEDBAT can't backoff and try
>> to avoid causing congestion. So your previous email about allowing some
>> congestion to take place on LE would be good as then protocols that try to
>> avoid causing congestion would have a way to do so.
>
> I do not like that the standard allows for total starvation. I would
> prefer it had a minimum of 5%.

I fully agree, and that would work even if all LE traffic was put into 
single queue with 5% of total bw, and even if that had a 1 second FIFO 
with tail drop.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

On Mon, Feb 4, 2019 at 2:34 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> On Mon, 4 Feb 2019, Dave Taht wrote:
>
> >> The problem with CAKE/FQ and background traffic is that it can't tell if
> >> there is congestion or not, and things like LEDBAT can't backoff and try
> >> to avoid causing congestion. So your previous email about allowing some
> >> congestion to take place on LE would be good as then protocols that try to
> >> avoid causing congestion would have a way to do so.
> >
> > I do not like that the standard allows for total starvation. I would
> > prefer it had a minimum of 5%.
>
> I fully agree, and that would work even if all LE traffic was put into
> single queue with 5% of total bw, and even if that had a 1 second FIFO
> with tail drop.

We don't quite agree.

"Every application has the right to one packet in the network" - John Nagle

Cake adheres to that as closely as possible, yet still keeps latency
low for all applications background, priority or best effort. fq_codel
doesn't, which leads to shorter queue lengths when ECN is in heavy
use. I wish cake would more aggressively drop ECN packets.

Sadly cake's uptake is a bit slow, as it is a bit slow.

>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

Just ressurrecting this old thread for review now that this is an
official RFC. I note also that the NQB diffserv codepoint is entering
last call also.

https://tools.ietf.org/html/draft-white-tsvwg-nqb-02

On Sun, Feb 3, 2019 at 10:39 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> And seems likely to be adopted.
>
> There seems to be an urge to make this codepoint starvable, which
> since I ascribe to nagle's dictum "every application has a right to
> one packet in the network" - doesn't work for me - but the draft is
> vaguely worded enough to just start dumping this codepoint into the
> background queue of both sqm and cake and worry about it in a decade
> or three.
>
> it's 000001 which I guess is:
>
> diff --git a/sch_cake.c b/sch_cake.c
> index 3a26db0..67263b3 100644
> --- a/sch_cake.c
> +++ b/sch_cake.c
> @@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
>  };
>
>  static const u8 diffserv3[] = {
> -       0, 0, 0, 0, 2, 0, 0, 0,
> +       0, 1, 0, 0, 2, 0, 0, 0,
>         1, 0, 0, 0, 0, 0, 0, 0,
>         0, 0, 0, 0, 0, 0, 0, 0,
>         0, 0, 0, 0, 0, 0, 0, 0,
>
> (or is that reversed? my big endian/little endian chops scuks, and
> nobody modified the gen_cake_const tool to match what cake expects
> now)
>
> on my off days I kind of wish the diffserv lookup we do in cake had
> managed to make it into the linux mqprio/prio stuff by default.
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]

Maybe attached patch is more comprehensive?

KDB

> On 21 Aug 2019, at 16:07, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Just ressurrecting this old thread for review now that this is an
> official RFC. I note also that the NQB diffserv codepoint is entering
> last call also.
> 
> https://tools.ietf.org/html/draft-white-tsvwg-nqb-02
> 
> On Sun, Feb 3, 2019 at 10:39 AM Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> And seems likely to be adopted.
>> 
>> There seems to be an urge to make this codepoint starvable, which
>> since I ascribe to nagle's dictum "every application has a right to
>> one packet in the network" - doesn't work for me - but the draft is
>> vaguely worded enough to just start dumping this codepoint into the
>> background queue of both sqm and cake and worry about it in a decade
>> or three.
>> 
>> it's 000001 which I guess is:
>> 
>> diff --git a/sch_cake.c b/sch_cake.c
>> index 3a26db0..67263b3 100644
>> --- a/sch_cake.c
>> +++ b/sch_cake.c
>> @@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
>> };
>> 
>> static const u8 diffserv3[] = {
>> -       0, 0, 0, 0, 2, 0, 0, 0,
>> +       0, 1, 0, 0, 2, 0, 0, 0,
>>        1, 0, 0, 0, 0, 0, 0, 0,
>>        0, 0, 0, 0, 0, 0, 0, 0,
>>        0, 0, 0, 0, 0, 0, 0, 0,
>> 
>> (or is that reversed? my big endian/little endian chops scuks, and
>> nobody modified the gen_cake_const tool to match what cake expects
>> now)
>> 
>> on my off days I kind of wish the diffserv lookup we do in cake had
>> managed to make it into the linux mqprio/prio stuff by default.
>> 
>> --
>> 
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-205-9740
> 
> 
> 
> --
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

[-- Attachment #1.2: 0001-RFC-8622-diffserv3-4-8-LE-PHB-support.patch --]
[-- Type: application/octet-stream, Size: 1633 bytes --]

From 1f460443d1bd54d269e3efda6999c0bbd91f7a03 Mon Sep 17 00:00:00 2001
From: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Date: Mon, 4 Feb 2019 21:27:58 +0000
Subject: [PATCH] RFC 8622 diffserv3, 4 & 8 LE PHB support

Change tin mapping on diffserv3, 4 & 8 for LE PHB support,
in essence make LE a member of the Bulk tin.

Bulk has the least priority and minimum of 1/16th total bandwidth in the
face of higher priority traffic.

NB: Diffserv 3 & 4 swap tin 0 & 1 priorities from the default order as
found in diffserv8, in case anyone is wondering why it looks a bit odd.

Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
---
 sch_cake.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sch_cake.c b/sch_cake.c
index 93c0c8a..81950ad 100644
--- a/sch_cake.c
+++ b/sch_cake.c
@@ -333,8 +333,8 @@ static const u8 precedence[] = {
 };
 
 static const u8 diffserv8[] = {
-	2, 5, 1, 2, 4, 2, 2, 2,
-	0, 2, 1, 2, 1, 2, 1, 2,
+	2, 0, 1, 2, 4, 2, 2, 2,
+	1, 2, 1, 2, 1, 2, 1, 2,
 	5, 2, 4, 2, 4, 2, 4, 2,
 	3, 2, 3, 2, 3, 2, 3, 2,
 	6, 2, 3, 2, 3, 2, 3, 2,
@@ -344,7 +344,7 @@ static const u8 diffserv8[] = {
 };
 
 static const u8 diffserv4[] = {
-	0, 2, 0, 0, 2, 0, 0, 0,
+	0, 1, 0, 0, 2, 0, 0, 0,
 	1, 0, 0, 0, 0, 0, 0, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
 	2, 0, 2, 0, 2, 0, 2, 0,
@@ -355,7 +355,7 @@ static const u8 diffserv4[] = {
 };
 
 static const u8 diffserv3[] = {
-	0, 0, 0, 0, 2, 0, 0, 0,
+	0, 1, 0, 0, 2, 0, 0, 0,
 	1, 0, 0, 0, 0, 0, 0, 0,
 	0, 0, 0, 0, 0, 0, 0, 0,
 	0, 0, 0, 0, 0, 0, 0, 0,
-- 
2.20.1 (Apple Git-117)


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Dave Taht]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

> Maybe attached patch is more comprehensive?

Yep! why was diffserv8 5 in the first place?

>
> KDB
>
>> On 21 Aug 2019, at 16:07, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> Just ressurrecting this old thread for review now that this is an
>> official RFC. I note also that the NQB diffserv codepoint is entering
>> last call also.
>> 
>> https://tools.ietf.org/html/draft-white-tsvwg-nqb-02
>> 
>> On Sun, Feb 3, 2019 at 10:39 AM Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> And seems likely to be adopted.
>>> 
>>> There seems to be an urge to make this codepoint starvable, which
>>> since I ascribe to nagle's dictum "every application has a right to
>>> one packet in the network" - doesn't work for me - but the draft is
>>> vaguely worded enough to just start dumping this codepoint into the
>>> background queue of both sqm and cake and worry about it in a decade
>>> or three.
>>> 
>>> it's 000001 which I guess is:
>>> 
>>> diff --git a/sch_cake.c b/sch_cake.c
>>> index 3a26db0..67263b3 100644
>>> --- a/sch_cake.c
>>> +++ b/sch_cake.c
>>> @@ -343,7 +343,7 @@ static const u8 diffserv4[] = {
>>> };
>>> 
>>> static const u8 diffserv3[] = {
>>> -       0, 0, 0, 0, 2, 0, 0, 0,
>>> +       0, 1, 0, 0, 2, 0, 0, 0,
>>>        1, 0, 0, 0, 0, 0, 0, 0,
>>>        0, 0, 0, 0, 0, 0, 0, 0,
>>>        0, 0, 0, 0, 0, 0, 0, 0,
>>> 
>>> (or is that reversed? my big endian/little endian chops scuks, and
>>> nobody modified the gen_cake_const tool to match what cake expects
>>> now)
>>> 
>>> on my off days I kind of wish the diffserv lookup we do in cake had
>>> managed to make it into the linux mqprio/prio stuff by default.
>>> 
>>> --
>>> 
>>> Dave Täht
>>> CTO, TekLibre, LLC
>>> http://www.teklibre.com
>>> Tel: 1-831-205-9740
>> 
>> 
>> 
>> --
>> 
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-831-205-9740
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
> Cheers,
>
> Kevin D-B
>
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
>
> From 1f460443d1bd54d269e3efda6999c0bbd91f7a03 Mon Sep 17 00:00:00 2001
> From: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
> Date: Mon, 4 Feb 2019 21:27:58 +0000
> Subject: [PATCH] RFC 8622 diffserv3, 4 & 8 LE PHB support
>
> Change tin mapping on diffserv3, 4 & 8 for LE PHB support,
> in essence make LE a member of the Bulk tin.
>
> Bulk has the least priority and minimum of 1/16th total bandwidth in the
> face of higher priority traffic.
>
> NB: Diffserv 3 & 4 swap tin 0 & 1 priorities from the default order as
> found in diffserv8, in case anyone is wondering why it looks a bit odd.
>
> Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
> ---
>  sch_cake.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sch_cake.c b/sch_cake.c
> index 93c0c8a..81950ad 100644
> --- a/sch_cake.c
> +++ b/sch_cake.c
> @@ -333,8 +333,8 @@ static const u8 precedence[] = {
>  };
>  
>  static const u8 diffserv8[] = {
> -	2, 5, 1, 2, 4, 2, 2, 2,
> -	0, 2, 1, 2, 1, 2, 1, 2,
> +	2, 0, 1, 2, 4, 2, 2, 2,
> +	1, 2, 1, 2, 1, 2, 1, 2,
>  	5, 2, 4, 2, 4, 2, 4, 2,
>  	3, 2, 3, 2, 3, 2, 3, 2,
>  	6, 2, 3, 2, 3, 2, 3, 2,
> @@ -344,7 +344,7 @@ static const u8 diffserv8[] = {
>  };
>  
>  static const u8 diffserv4[] = {
> -	0, 2, 0, 0, 2, 0, 0, 0,
> +	0, 1, 0, 0, 2, 0, 0, 0,
>  	1, 0, 0, 0, 0, 0, 0, 0,
>  	2, 0, 2, 0, 2, 0, 2, 0,
>  	2, 0, 2, 0, 2, 0, 2, 0,
> @@ -355,7 +355,7 @@ static const u8 diffserv4[] = {
>  };
>  
>  static const u8 diffserv3[] = {
> -	0, 0, 0, 0, 2, 0, 0, 0,
> +	0, 1, 0, 0, 2, 0, 0, 0,
>  	1, 0, 0, 0, 0, 0, 0, 0,
>  	0, 0, 0, 0, 0, 0, 0, 0,
>  	0, 0, 0, 0, 0, 0, 0, 0,

Re: [Cerowrt-devel] [Cake] https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is in last call

[Mikael Abrahamsson]

On Wed, 21 Aug 2019, Dave Taht wrote:

> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
>> Maybe attached patch is more comprehensive?
>
> Yep! why was diffserv8 5 in the first place?

"diffserve8 is 5"? I don't understand. Do you mean 001000?

https://tools.ietf.org/html/rfc3662

3.2.  PHB configuration

    Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use
    (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]
    may be used as the PHB for the LE traffic aggregate.  This document
    does not specify the exact DSCP to use inside a domain, but instead
    specifies the necessary properties of the PHB selected by the DSCP.
    If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.

So CS1 is the original PHB for LE. However, it has problems and was never 
really deployed and I was one who pushed for a specific codepoint within 
000xxx for LE, that might have a chance to be deployed internet-wide. 
000001 seems as good as any.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se