Re: [Cake] bufferbloat still misunderstood & ignored

[Dave Taht]

I so wish that the network nuetrality debate included discussions such as these.

On Wed, Mar 28, 2018 at 5:53 PM, Jonathan Morton  wrote:
>> On 29 Mar, 2018, at 3:26 am, Dave Taht  wrote:
>>
>> A finicky bit would be who to penalize when the underlying medium
>> (shared cable) is oversubscribed.
>
> Two obvious reasonable solutions: share equally per subscriber, or share 
> proportionately to provisioned bandwidth per subscriber.  Either should be 
> fairly straightforward to implement in an integrated qdisc, and either would 
> penalise the (instantaneously) heaviest users before affecting normal or 
> light users.
>
> Equal sharing has the interesting side-effect that subscribers on lower tiers 
> don't notice backhaul congestion at all until higher tiers have been forced 
> down to their level.  This potentially gives ISPs an incentive to avoid such 
> extreme congestion (by upgrading backhaul to match demand), since rational 
> customers won't pay for bandwidth they can't use.  It also ensures that all 
> subscribers retain a reasonable, basic level of service during abnormal 
> congestion events.
>
> Conversely, proportional sharing might give a perverse incentive, since 
> paying more gives a larger share of the pie, no matter how cramped it is.  
> Artificial scarcity could then be used to aid up-selling in an anti-consumer 
> manner, similar to what's been seen with Netflix.  It would be naive to 
> assume that ISPs won't do this, given the opportunity, so it would be better 
> to build only the more consumer-friendly option into the software.
>
> Theoretically, a middle ground could be to assign a sharing weight separately 
> from the provisioned bandwidth.  This would permit, for example, subscribers 
> provisioned at 100:1 bandwidths to receive 4:1 service under congested 
> conditions.  However, this would be under ISPs' control and fully documented, 
> and would therefore be a little too tempting to abuse.
>
>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] bufferbloat still misunderstood & ignored

[Jonathan Morton]

> On 29 Mar, 2018, at 3:26 am, Dave Taht  wrote:
> 
> A finicky bit would be who to penalize when the underlying medium
> (shared cable) is oversubscribed.

Two obvious reasonable solutions: share equally per subscriber, or share 
proportionately to provisioned bandwidth per subscriber.  Either should be 
fairly straightforward to implement in an integrated qdisc, and either would 
penalise the (instantaneously) heaviest users before affecting normal or light 
users.

Equal sharing has the interesting side-effect that subscribers on lower tiers 
don't notice backhaul congestion at all until higher tiers have been forced 
down to their level.  This potentially gives ISPs an incentive to avoid such 
extreme congestion (by upgrading backhaul to match demand), since rational 
customers won't pay for bandwidth they can't use.  It also ensures that all 
subscribers retain a reasonable, basic level of service during abnormal 
congestion events.

Conversely, proportional sharing might give a perverse incentive, since paying 
more gives a larger share of the pie, no matter how cramped it is.  Artificial 
scarcity could then be used to aid up-selling in an anti-consumer manner, 
similar to what's been seen with Netflix.  It would be naive to assume that 
ISPs won't do this, given the opportunity, so it would be better to build only 
the more consumer-friendly option into the software.

Theoretically, a middle ground could be to assign a sharing weight separately 
from the provisioned bandwidth.  This would permit, for example, subscribers 
provisioned at 100:1 bandwidths to receive 4:1 service under congested 
conditions.  However, this would be under ISPs' control and fully documented, 
and would therefore be a little too tempting to abuse.

 - Jonathan Morton

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] bufferbloat still misunderstood & ignored

[Dave Taht]

On Wed, Mar 28, 2018 at 5:04 PM, Jonathan Morton  wrote:
>> On 28 Mar, 2018, at 10:32 pm, Dave Taht  wrote:
>>
>> The two line method is quite common among gamers.
>
> I'm pretty sure a single A ADSL connection costs less than two from a 
> bargain-basement ISP, what with line rental factoring into the total price.  
> Of course, not everyone is lucky enough to live in the UK and thus have 
> access to A (myself included).
>
> Something else to shoehorn into the Cake paper: as future work, an 
> ISP-focused qdisc (or even a whole middlebox using commodity hardware) using 
> a rearranged version of the technology proven in Cake.  Cake itself is 
> focused on managing a single link, whereas an ISP must deal with many 
> subscriber links (with a finite variety of service tiers) sharing a backhaul 
> link, with the link interface hardware itself being unable to avoid 
> bufferbloat or to share bandwidth fairly when congestion occurs.  The 
> backhaul link might be to a local exchange, a shared cable medium, or a 
> satellite hop.

Everything can be solved with one more level of indirection. In this
case a full solution would be to be able to cleanly pattern match
against nexthop mac, or the set of ipv4 and ipv6 addresses the
subscriber has, and feed each unique match into a queue that feeds
into a cake-like instance. A cake of cakes.

A partial solution could be one virtual interface per subscriber.

A finicky bit would be who to penalize when the underlying medium
(shared cable) is oversubscribed.

>
>  - Jonathan Morton



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] bufferbloat still misunderstood & ignored

[Jonathan Morton]

> On 28 Mar, 2018, at 10:32 pm, Dave Taht  wrote:
> 
> The two line method is quite common among gamers.

I'm pretty sure a single A ADSL connection costs less than two from a 
bargain-basement ISP, what with line rental factoring into the total price.  Of 
course, not everyone is lucky enough to live in the UK and thus have access to 
A (myself included).

Something else to shoehorn into the Cake paper: as future work, an ISP-focused 
qdisc (or even a whole middlebox using commodity hardware) using a rearranged 
version of the technology proven in Cake.  Cake itself is focused on managing a 
single link, whereas an ISP must deal with many subscriber links (with a finite 
variety of service tiers) sharing a backhaul link, with the link interface 
hardware itself being unable to avoid bufferbloat or to share bandwidth fairly 
when congestion occurs.  The backhaul link might be to a local exchange, a 
shared cable medium, or a satellite hop.

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

[Cake] gcc 7.3.1 issue on arch

[Bret Towe]

for anyone seeing a compile error like the below on Arch Linux

  CC [M]  /root/sch_cake/sch_cake.o
In file included from ./include/linux/list.h:9:0,
 from ./include/linux/module.h:9,
 from /root/sch_cake/sch_cake.c:42:
./include/linux/kernel.h:6:10: fatal error: stdarg.h: No such file or directory
 #include 
  ^~
compilation terminated.


the workaround is below

diff --git a/Makefile b/Makefile
index 2c473e3..428ffbf 100644
--- a/Makefile
+++ b/Makefile
@@ -2,6 +2,7 @@ obj-m := sch_cake.o
 KERNEL_VERSION := $(shell uname -r)
 IDIR := /lib/modules/$(KERNEL_VERSION)/kernel/net/sched/
 KDIR := /lib/modules/$(KERNEL_VERSION)/build
+ccflags-y=-I/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 PWD := $(shell pwd)
 VERSION := $(shell git rev-parse HEAD 2>/dev/null)
 default:
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] bufferbloat still misunderstood & ignored

[Dave Taht]

The two line method is quite common among gamers.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] bufferbloat still misunderstood & ignored

[Toke Høiland-Jørgensen]

Kevin Darbyshire-Bryant via Cake  writes:

> From: Kevin Darbyshire-Bryant 
> Subject: bufferbloat still misunderstood & ignored
> To: Cake List 
> Date: Wed, 28 Mar 2018 15:46:47 +
>
> http://forums.thinkbroadband.com/talktalk/t/4587923-sensible-discussion-with-talktalk-about-bufferbloat.html
>
> The thing that bothers me more than anything….. the first reply comes
> from a staff member of ‘thinkbroadband’.

"Solution is two get two lines, so if a big download is using up one
they can do latency sensitive stuff on the other."

Lovely; an ISP that found a way to monetise bufferbloat... :/

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] bufferbloat still misunderstood & ignored

[Kevin Darbyshire-Bryant via Cake]

--- Begin Message ---
http://forums.thinkbroadband.com/talktalk/t/4587923-sensible-discussion-with-talktalk-about-bufferbloat.html

The thing that bothers me more than anything….. the first reply comes from a 
staff member of ‘thinkbroadband’.

Cheers,

Kevin D-B

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



signature.asc
Description: Message signed with OpenPGP
--- End Message ---
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake