Re: [Bloat] [Cerowrt-devel] intel gives up on home gateways

[Joel Wirāmu Pauling]

Good riddance; most of the current platforms are using Lantiq Wireless
which they got from some acquizition/cross-licence deal and are poorly
documented at worst and completely innoperable.

I doubt this will impact any of their Industrial IO and Edge stuff which is
actually good and anyone sensible might base their design on.

-Joel



On Wed, 29 Apr 2020 at 04:57, Dave Taht  wrote:

> H/T sebastian:
>
>
> https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
>
> Gawd knows what this means.
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> ___
> Cerowrt-devel mailing list
> cerowrt-de...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

[Sebastian Moeller]

> On Apr 28, 2020, at 21:26, Gorry Fairhurst  wrote:
> 
> This seems all interesting, but isn't this true of any network technology. If 
> I use a UDP app with my own style of CC I can just take all the capacity if I 
> want.
> 
> A solution could be to apply a circuit-breaker/policer in the network to 
> perform admission control, but I don't see the link to L4S. Have I missed 
> something ?

Maybe that the purposefully shallow LL-queue will make it especially 
easy to drive it into overload-reactive pure dropping mode? The designed-in 
(lack of) burst tolerance* really is not to expect bursts in the LL-queue. 
Disruption will be possible with surprisingly small bursts directed at the 
LL-queue (and due to ECT(1) without admission control this will be a target 
even skript kiddies can not miss) which will make the circuit-breaker/policer 
interventions a bit of a gamble (if you throttle all traffic you basically 
compromises low-latency, low-loss and throughput, but if you try to isolate the 
offenders, you are in FQ territory and that is verboten for L4S). 
But we have discussed the almost naive thread modelling of the L4S rfc's 
before. To which the response was, a user can always implement queue protection 
and (D)DOS is possible even today,so L4S is not making the situation worse 
(which is a) a low bar to clear, and b) more than can be said about 
RTT-dependence). 


Best Regards
Sebastian



*) The dual queue coupled AQM removed PIE's additional burst tolerance mode; I 
do not claim that that in itself is a problem, and that that mode would buy 
much more resilience but it demonstrates a rather haphazard approach to 
engineering iMHO. But see Pete's recent message about how L4S copes with bursty 
traffic.


> 
> Gorry
> 
> On 28/04/2020 20:04, Luca Muscariello wrote:
>> Hi Jake,
>> 
>> Thanks for the notes. Very useful.
>> The other issue with the meeting was that the virtual mic queue control 
>> channel was the WebEx Meeting chat that does not exist in WebEx Teams. So, I 
>> had to switch to Meetings and lost some pieces of the discussion. 
>> 
>> Yes there might be a terminology difference. Elastic traffic is usually used 
>> in the sense of bandwidth sharing not just to define variable bit rates.
>> 
>> The point is that there are incentives to cheat in L4S.
>> 
>> There is a priority queue that my application can enter by providing as 
>> input ECT(1). 
>> Applications such as on-line meetings will have a relatively low and highly 
>> paced rate.
>> 
>> This traffic is conformant to dualQ L queue but is unresponsive to 
>> congestion notifications.  
>> 
>> This is especially true for FEC streams which could be used to ameliorate 
>> the media quality in presence of losses(e.g. Wi-Fi)
>> or increased jitter.
>> 
>> 
>> That was one more point on why using ECT(1) as input assumes trust or a 
>> black list after being caught.
>> 
>> In both cases the ECT(1) as input is DoSable.
>> 
>> 
>> 
>> On Tue, Apr 28, 2020 at 7:12 PM Holland, Jake  wrote:
>> Hi Luca,
>> 
>>  
>> To your point about the discussion being difficult to follow: I tried to 
>> capture the intent of everyone who commented while taking notes:
>> 
>> https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03
>> 
>>  
>> I think this was intended to take the place of a need for everyone to 
>> re-send the same points to the list, but of course some of the most crucial 
>> points could probably use fleshing out with on-list follow up.
>> 
>>  
>> It got a bit rough in places because I was disconnected a few times and had 
>> to cut over to a local text file, and I may have failed to correctly 
>> understand or summarize some of the comments, so there’s chances I might 
>> have missed something, but I did my best to capture them all.
>> 
>>  
>> I encourage people to review comments and check whether they came out more 
>> or less correct, and to offer formatting and cleanup suggestions if there’s 
>> a good way to make it easier to follow.
>> 
>>  
>> I had timestamps at the beginning of each main point of discussion, with the 
>> intent that after the video is published it would be easier to go back and 
>> check precisely what was said. It looks like someone has been making cleanup 
>> edits that removed the first half of those so far, but my local text file 
>> still has most of those and I can go back and re-insert them if it seems 
>> useful.
>> 
>>  
>> @Luca: during your comments in particular I think there might have been a 
>> disruption--I had a “first comment missed, please check video” placeholder 
>> and I may have misunderstood the part about video elasticity, but my 
>> interpretation at the time was that Stuart was claiming that video was 
>> elastic in that it would adjust downward to avoid overflowing a loaded link, 
>> and I thought you were claiming that it was not elastic in that it would not 
>> exceed a maximum rate, which I summarized as perhaps a semantic 
>> disagreement, but if 

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

[Jonathan Morton]

> On 28 Apr, 2020, at 10:43 pm, Black, David  wrote:
> 
> And I also noted this at the end of the meeting:  “queue protection that 
> might apply the disincentive”
>  
> That would send cheaters to the L4S conventional queue along with all the 
> other queue-building traffic.

Alas, we have not yet seen an integrated implementation of the queue protection 
mechanism, so that we can test its effectiveness.  I think it is part of the 
extra evidence that would be needed before a decision could be taken in favour 
of using ECT(1) as an input.

I would also note in this context that mere volume of data, or length of 
development, are not marks that should be taken in favour of a proposal.  The 
relevance, quality, thoroughness and results of data collection must be 
carefully evaluated, and it could easily be argued that a lengthy development 
cycle that still has not produced reliable results should be retired, to avoid 
throwing good money after bad.  The fact that we were able to find serious 
problems with the (only?) reference implementation of L4S using a relatively 
small, but independently selected test suite does not lend confidence in its 
maturity.

Reputable engineers know that it is necessary to establish a robust design 
first.  Only then can a robust implementation be hoped for.  It is the basic 
design decision, over the semantics of each ECN codepoint, that we were trying 
to discuss yesterday.  I'm not certain that everyone in the room understood 
that.

 - Jonathan Morton

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

[Black, David]

And I also noted this at the end of the meeting:  “queue protection that might 
apply the disincentive”

That would send cheaters to the L4S conventional queue along with all the other 
queue-building traffic.

Thanks, --David

From: tsvwg  On Behalf Of Luca Muscariello
Sent: Tuesday, April 28, 2020 3:39 PM
To: Gorry Fairhurst
Cc: tsvwg IETF list; bloat
Subject: Re: [tsvwg] [Bloat] my backlogged comments on the ECT(1) interim call


[EXTERNAL EMAIL]
The link is that the L queue starves the other queue, and indeed the envisaged 
queue protection mechanism
is supposed to react to that behavior by black-listing the misbehaving sender.
This would be the third coupled component in L4S (the senders, the AQM and the 
policer). Which is currently non-mandatory.

The level of starvation is a parameter in dualQ as the service ratio between 
the two queues has to be set
but the AQM owner. How to set this ratio is yet another knob that is unclear 
how to optimally set
under a general traffic mix,  that includes unresponsive traffic.

I have already raised this issue in the past.



On Tue, Apr 28, 2020 at 9:26 PM Gorry Fairhurst 
mailto:go...@erg.abdn.ac.uk>> wrote:

This seems all interesting, but isn't this true of any network technology. If I 
use a UDP app with my own style of CC I can just take all the capacity if I 
want.

A solution could be to apply a circuit-breaker/policer in the network to 
perform admission control, but I don't see the link to L4S. Have I missed 
something ?

Gorry
On 28/04/2020 20:04, Luca Muscariello wrote:
Hi Jake,

Thanks for the notes. Very useful.
The other issue with the meeting was that the virtual mic queue control channel 
was the WebEx Meeting chat that does not exist in WebEx Teams. So, I had to 
switch to Meetings and lost some pieces of the discussion.

Yes there might be a terminology difference. Elastic traffic is usually used in 
the sense of bandwidth sharing not just to define variable bit rates.

The point is that there are incentives to cheat in L4S.

There is a priority queue that my application can enter by providing as input 
ECT(1).
Applications such as on-line meetings will have a relatively low and highly 
paced rate.

This traffic is conformant to dualQ L queue but is unresponsive to congestion 
notifications.

This is especially true for FEC streams which could be used to ameliorate the 
media quality in presence of losses(e.g. Wi-Fi)
or increased jitter.


That was one more point on why using ECT(1) as input assumes trust or a black 
list after being caught.

In both cases the ECT(1) as input is DoSable.



On Tue, Apr 28, 2020 at 7:12 PM Holland, Jake 
mailto:jholl...@akamai..com>> wrote:
Hi Luca,

To your point about the discussion being difficult to follow: I tried to 
capture the intent of everyone who commented while taking notes:
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03

I think this was intended to take the place of a need for everyone to re-send 
the same points to the list, but of course some of the most crucial points 
could probably use fleshing out with on-list follow up.

It got a bit rough in places because I was disconnected a few times and had to 
cut over to a local text file, and I may have failed to correctly understand or 
summarize some of the comments, so there’s chances I might have missed 
something, but I did my best to capture them all.

I encourage people to review comments and check whether they came out more or 
less correct, and to offer formatting and cleanup suggestions if there’s a good 
way to make it easier to follow.

I had timestamps at the beginning of each main point of discussion, with the 
intent that after the video is published it would be easier to go back and 
check precisely what was said. It looks like someone has been making cleanup 
edits that removed the first half of those so far, but my local text file still 
has most of those and I can go back and re-insert them if it seems useful.

@Luca: during your comments in particular I think there might have been a 
disruption--I had a “first comment missed, please check video” placeholder and 
I may have misunderstood the part about video elasticity, but my interpretation 
at the time was that Stuart was claiming that video was elastic in that it 
would adjust downward to avoid overflowing a loaded link, and I thought you 
were claiming that it was not elastic in that it would not exceed a maximum 
rate, which I summarized as perhaps a semantic disagreement, but if you’d like 
to help clean that up, it might be useful.

From this message, it sounds like the key point you were making was that it 
also will not go below a certain rate, and perhaps that quality can stay 
relatively good in spite of high network loss?

Best regards,
Jake

From: Luca Muscariello mailto:muscarie...@ieee.org>>
Date: Tuesday, April 28, 2020 at 1:54 AM
To: Dave Taht mailto:dave.t...@gmail.com>>
Cc: 

Re: [Bloat] intel gives up on home gateways

[Stephen Hemminger]

On Tue, 28 Apr 2020 09:57:26 -0700
Dave Taht  wrote:

> H/T sebastian:
> 
> https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
> 
> Gawd knows what this means.
> 

It means somebody is getting a bonus, and somebody is out of a job
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [tsvwg] my backlogged comments on the ECT(1) interim call

[Luca Muscariello]

The link is that the L queue starves the other queue, and indeed the
envisaged queue protection mechanism
is supposed to react to that behavior by black-listing the misbehaving
sender.
This would be the third coupled component in L4S (the senders, the AQM and
the policer). Which is currently non-mandatory.

The level of starvation is a parameter in dualQ as the service ratio
between the two queues has to be set
but the AQM owner. How to set this ratio is yet another knob that is
unclear how to optimally set
under a general traffic mix,  that includes unresponsive traffic.

I have already raised this issue in the past.



On Tue, Apr 28, 2020 at 9:26 PM Gorry Fairhurst 
wrote:

> This seems all interesting, but isn't this true of any network technology.
> If I use a UDP app with my own style of CC I can just take all the capacity
> if I want.
>
> A solution could be to apply a circuit-breaker/policer in the network to
> perform admission control, but I don't see the link to L4S. Have I missed
> something ?
>
> Gorry
> On 28/04/2020 20:04, Luca Muscariello wrote:
>
> Hi Jake,
>
> Thanks for the notes. Very useful.
> The other issue with the meeting was that the virtual mic queue control
> channel was the WebEx Meeting chat that does not exist in WebEx Teams. So,
> I had to switch to Meetings and lost some pieces of the discussion.
>
> Yes there might be a terminology difference. Elastic traffic is usually
> used in the sense of bandwidth sharing not just to define variable bit
> rates.
>
> The point is that there are incentives to cheat in L4S.
>
> There is a priority queue that my application can enter by providing as
> input ECT(1).
> Applications such as on-line meetings will have a relatively low and
> highly paced rate.
>
> This traffic is conformant to dualQ L queue but is unresponsive to
> congestion notifications.
>
> This is especially true for FEC streams which could be used to ameliorate
> the media quality in presence of losses(e.g. Wi-Fi)
> or increased jitter.
>
>
> That was one more point on why using ECT(1) as input assumes trust or a
> black list after being caught.
>
> In both cases the ECT(1) as input is DoSable.
>
>
>
> On Tue, Apr 28, 2020 at 7:12 PM Holland, Jake  wrote:
>
>> Hi Luca,
>>
>>
>>
>> To your point about the discussion being difficult to follow: I tried to
>> capture the intent of everyone who commented while taking notes:
>>
>> https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03
>>
>>
>>
>> I think this was intended to take the place of a need for everyone to
>> re-send the same points to the list, but of course some of the most crucial
>> points could probably use fleshing out with on-list follow up.
>>
>>
>>
>> It got a bit rough in places because I was disconnected a few times and
>> had to cut over to a local text file, and I may have failed to correctly
>> understand or summarize some of the comments, so there’s chances I might
>> have missed something, but I did my best to capture them all.
>>
>>
>>
>> I encourage people to review comments and check whether they came out
>> more or less correct, and to offer formatting and cleanup suggestions if
>> there’s a good way to make it easier to follow.
>>
>>
>>
>> I had timestamps at the beginning of each main point of discussion, with
>> the intent that after the video is published it would be easier to go back
>> and check precisely what was said. It looks like someone has been making
>> cleanup edits that removed the first half of those so far, but my local
>> text file still has most of those and I can go back and re-insert them if
>> it seems useful.
>>
>>
>>
>> @Luca: during your comments in particular I think there might have been a
>> disruption--I had a “first comment missed, please check video” placeholder
>> and I may have misunderstood the part about video elasticity, but my
>> interpretation at the time was that Stuart was claiming that video was
>> elastic in that it would adjust downward to avoid overflowing a loaded
>> link, and I thought you were claiming that it was not elastic in that it
>> would not exceed a maximum rate, which I summarized as perhaps a semantic
>> disagreement, but if you’d like to help clean that up, it might be useful.
>>
>>
>>
>> From this message, it sounds like the key point you were making was that
>> it also will not go below a certain rate, and perhaps that quality can stay
>> relatively good in spite of high network loss?
>>
>>
>>
>> Best regards,
>>
>> Jake
>>
>>
>>
>> *From: *Luca Muscariello 
>> *Date: *Tuesday, April 28, 2020 at 1:54 AM
>> *To: *Dave Taht 
>> *Cc: *tsvwg IETF list , bloat <
>> bloat@lists.bufferbloat.net>
>> *Subject: *Re: [Bloat] my backlogged comments on the ECT(1) interim call
>>
>>
>>
>> Hi Dave and list members,
>>
>>
>>
>> It was difficult to follow the discussion at the meeting yesterday.
>>
>> Who  said what in the first place.
>>
>>
>>
>> There have been a lot of non-technical comments such as: this solution
>>
>> is better than 

Re: [Bloat] my backlogged comments on the ECT(1) interim call

[Luca Muscariello]

Hi Jake,

Thanks for the notes. Very useful.
The other issue with the meeting was that the virtual mic queue control
channel was the WebEx Meeting chat that does not exist in WebEx Teams. So,
I had to switch to Meetings and lost some pieces of the discussion.

Yes there might be a terminology difference. Elastic traffic is usually
used in the sense of bandwidth sharing not just to define variable bit
rates.

The point is that there are incentives to cheat in L4S.

There is a priority queue that my application can enter by providing as
input ECT(1).
Applications such as on-line meetings will have a relatively low and highly
paced rate.

This traffic is conformant to dualQ L queue but is unresponsive to
congestion notifications.

This is especially true for FEC streams which could be used to ameliorate
the media quality in presence of losses(e.g. Wi-Fi)
or increased jitter.


That was one more point on why using ECT(1) as input assumes trust or a
black list after being caught.

In both cases the ECT(1) as input is DoSable.



On Tue, Apr 28, 2020 at 7:12 PM Holland, Jake  wrote:

> Hi Luca,
>
>
>
> To your point about the discussion being difficult to follow: I tried to
> capture the intent of everyone who commented while taking notes:
>
> https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03
>
>
>
> I think this was intended to take the place of a need for everyone to
> re-send the same points to the list, but of course some of the most crucial
> points could probably use fleshing out with on-list follow up.
>
>
>
> It got a bit rough in places because I was disconnected a few times and
> had to cut over to a local text file, and I may have failed to correctly
> understand or summarize some of the comments, so there’s chances I might
> have missed something, but I did my best to capture them all.
>
>
>
> I encourage people to review comments and check whether they came out more
> or less correct, and to offer formatting and cleanup suggestions if there’s
> a good way to make it easier to follow.
>
>
>
> I had timestamps at the beginning of each main point of discussion, with
> the intent that after the video is published it would be easier to go back
> and check precisely what was said. It looks like someone has been making
> cleanup edits that removed the first half of those so far, but my local
> text file still has most of those and I can go back and re-insert them if
> it seems useful.
>
>
>
> @Luca: during your comments in particular I think there might have been a
> disruption--I had a “first comment missed, please check video” placeholder
> and I may have misunderstood the part about video elasticity, but my
> interpretation at the time was that Stuart was claiming that video was
> elastic in that it would adjust downward to avoid overflowing a loaded
> link, and I thought you were claiming that it was not elastic in that it
> would not exceed a maximum rate, which I summarized as perhaps a semantic
> disagreement, but if you’d like to help clean that up, it might be useful.
>
>
>
> From this message, it sounds like the key point you were making was that
> it also will not go below a certain rate, and perhaps that quality can stay
> relatively good in spite of high network loss?
>
>
>
> Best regards,
>
> Jake
>
>
>
> *From: *Luca Muscariello 
> *Date: *Tuesday, April 28, 2020 at 1:54 AM
> *To: *Dave Taht 
> *Cc: *tsvwg IETF list , bloat  >
> *Subject: *Re: [Bloat] my backlogged comments on the ECT(1) interim call
>
>
>
> Hi Dave and list members,
>
>
>
> It was difficult to follow the discussion at the meeting yesterday.
>
> Who  said what in the first place.
>
>
>
> There have been a lot of non-technical comments such as: this solution
>
> is better than another in my opinion. "better" has often been used
>
> as when evaluating the taste of an ice cream: White chocolate vs black
> chocolate.
>
> This has taken a significant amount of time at the meeting. I haven't
> learned
>
> much from that kind of discussion and I do not think that helped to make
>
> much progress.
>
>
>
> If people can re-make their points in the list it would help the debate.
>
>
>
> Another point that a few raised is that we have to make a decision as fast
> as possible.
>
> I dismissed entirely that argument. Trading off latency with resilience of
> the Internet
>
> is entirely against the design principle of the Internet architecture
> itself.
>
> Risk analysis is something that we should keep in mind even when
> deploying any experiment
>
> and should be a substantial part of it.
>
>
>
> Someone claimed that on-line meeting traffic is elastic. This is not true,
> I tried to
>
> clarify this. These applications (WebEx/Zoom) are low rate, a typical
> maximum upstream
>
> rate is 2Mbps and is not elastic. These applications have often a
> stand-alone app
>
> that is not using the browser WebRTC stack (the standalone app typically
> works better).
>
>
>
> A client sends upstream one or two video qualities unless 

Re: [Bloat] my backlogged comments on the ECT(1) interim call

[Holland, Jake via Bloat]

--- Begin Message ---
Hi Luca,

To your point about the discussion being difficult to follow: I tried to 
capture the intent of everyone who commented while taking notes:
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03

I think this was intended to take the place of a need for everyone to re-send 
the same points to the list, but of course some of the most crucial points 
could probably use fleshing out with on-list follow up.

It got a bit rough in places because I was disconnected a few times and had to 
cut over to a local text file, and I may have failed to correctly understand or 
summarize some of the comments, so there’s chances I might have missed 
something, but I did my best to capture them all.

I encourage people to review comments and check whether they came out more or 
less correct, and to offer formatting and cleanup suggestions if there’s a good 
way to make it easier to follow.

I had timestamps at the beginning of each main point of discussion, with the 
intent that after the video is published it would be easier to go back and 
check precisely what was said. It looks like someone has been making cleanup 
edits that removed the first half of those so far, but my local text file still 
has most of those and I can go back and re-insert them if it seems useful.

@Luca: during your comments in particular I think there might have been a 
disruption--I had a “first comment missed, please check video” placeholder and 
I may have misunderstood the part about video elasticity, but my interpretation 
at the time was that Stuart was claiming that video was elastic in that it 
would adjust downward to avoid overflowing a loaded link, and I thought you 
were claiming that it was not elastic in that it would not exceed a maximum 
rate, which I summarized as perhaps a semantic disagreement, but if you’d like 
to help clean that up, it might be useful.

From this message, it sounds like the key point you were making was that it 
also will not go below a certain rate, and perhaps that quality can stay 
relatively good in spite of high network loss?

Best regards,
Jake

From: Luca Muscariello 
Date: Tuesday, April 28, 2020 at 1:54 AM
To: Dave Taht 
Cc: tsvwg IETF list , bloat 
Subject: Re: [Bloat] my backlogged comments on the ECT(1) interim call

Hi Dave and list members,

It was difficult to follow the discussion at the meeting yesterday.
Who  said what in the first place.

There have been a lot of non-technical comments such as: this solution
is better than another in my opinion. "better" has often been used
as when evaluating the taste of an ice cream: White chocolate vs black 
chocolate.
This has taken a significant amount of time at the meeting. I haven't learned
much from that kind of discussion and I do not think that helped to make
much progress.

If people can re-make their points in the list it would help the debate.

Another point that a few raised is that we have to make a decision as fast as 
possible.
I dismissed entirely that argument. Trading off latency with resilience of the 
Internet
is entirely against the design principle of the Internet architecture itself.
Risk analysis is something that we should keep in mind even when deploying any 
experiment
and should be a substantial part of it.

Someone claimed that on-line meeting traffic is elastic. This is not true, I 
tried to
clarify this. These applications (WebEx/Zoom) are low rate, a typical maximum 
upstream
rate is 2Mbps and is not elastic. These applications have often a stand-alone 
app
that is not using the browser WebRTC stack (the standalone app typically works 
better).

A client sends upstream one or two video qualities unless the video camera is 
switched off.
In presence of losses, FEC is used but it is still non elastic.
Someone claimed (at yesterday's meeting) that fairness is not an issue (who 
cares, I heard!)
Well, fairness can constitute a differentiation advantage between two companies 
that are
commercializing on-line meetings products. Unless at the IETF we accept
"law-of-the-jungle" behaviours from Internet applications developers, we should 
be careful
about making such claims.
Any opportunity to cheat, that brings a business advantage WILL be used.

/Luca

TL;DR
To Dave: you asked several times what  Cisco does on latency reduction in
network equipment. I tend to be very shy when replying on these questions
as this is not vendor neutral. If chairs think this is not appropriate for
the list, please say it and I'll reply privately only.

What I write below can be found in Cisco products data sheets and is not
trade secret. There are very good blog posts explaining details.
Not surprisingly Cisco implements the state of the art on the topic
and it is totally feasible to do-the-right-thing in software and hardware.

Cisco implements AFD (one queue + a flow table) accompanied by a priority queue 
for
flows that have a certain profile in rate and size. The concept is well known 
and well
studied in 

[Bloat] intel gives up on home gateways

[Dave Taht]

H/T sebastian:

https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform

Gawd knows what this means.

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] my backlogged comments on the ECT(1) interim call

[Luca Muscariello]

Hi Dave and list members,

It was difficult to follow the discussion at the meeting yesterday.
Who  said what in the first place.

There have been a lot of non-technical comments such as: this solution
is better than another in my opinion. "better" has often been used
as when evaluating the taste of an ice cream: White chocolate vs black
chocolate.
This has taken a significant amount of time at the meeting. I haven't
learned
much from that kind of discussion and I do not think that helped to make
much progress.

If people can re-make their points in the list it would help the debate.

Another point that a few raised is that we have to make a decision as fast
as possible.
I dismissed entirely that argument. Trading off latency with resilience of
the Internet
is entirely against the design principle of the Internet architecture
itself.
Risk analysis is something that we should keep in mind even when
deploying any experiment
and should be a substantial part of it.

Someone claimed that on-line meeting traffic is elastic. This is not true,
I tried to
clarify this. These applications (WebEx/Zoom) are low rate, a typical
maximum upstream
rate is 2Mbps and is not elastic. These applications have often a
stand-alone app
that is not using the browser WebRTC stack (the standalone app typically
works better).

A client sends upstream one or two video qualities unless the video camera
is switched off.
In presence of losses, FEC is used but it is still non elastic.
Someone claimed (at yesterday's meeting) that fairness is not an issue (who
cares, I heard!)
Well, fairness can constitute a differentiation advantage between two
companies that are
commercializing on-line meetings products. Unless at the IETF we accept
"law-of-the-jungle" behaviours from Internet applications developers, we
should be careful
about making such claims.
Any opportunity to cheat, that brings a business advantage WILL be used.

/Luca

TL;DR
To Dave: you asked several times what  Cisco does on latency reduction in
network equipment. I tend to be very shy when replying on these questions
as this is not vendor neutral. If chairs think this is not appropriate for
the list, please say it and I'll reply privately only.

What I write below can be found in Cisco products data sheets and is not
trade secret. There are very good blog posts explaining details.
Not surprisingly Cisco implements the state of the art on the topic
and it is totally feasible to do-the-right-thing in software and hardware.

Cisco implements AFD (one queue + a flow table) accompanied by a priority
queue for
flows that have a certain profile in rate and size. The concept is well
known and well
studied in the literature. AFD is safe and can well serve a complex traffic
mix when
accompanied by a priority queue. This prio-queue should not be confused
with a strict
priority queue (e.g. EF in diffserv). There are subtleties related to the
DOCSIS
shared medium which would be too long to describe here.

This is available in Cisco CMTS for the DOCSIS segment. Bottleneck traffic
does not negatively impact non-bottlenecked-traffic such as an on-line
meeting like
the WebEx call we had yesterday. It is safe from a network neutrality
point-of-view
and no applications get hurt.

Cisco implements AFD+prio also for some DC switches such as the Nexus 9k.
There
is a blog post written by Tom Edsal online that explains pretty well how
that works.
This includes mechanisms such as p-fabric to approximate SRPT (shortest
remaining processing time)
and minimize flow completion time for many DC workloads. The mix of the two
brings FCT minimization AND latency minimization. This is silicon and
scales at any speed.
For those who are not familiar with these concepts, please search the
research work of Balaji
Prabhakar and Ron Pang at Stanford.

Wi-Fi: Cisco does airtime fairness in Aironet but I think in the Meraki
series too.
The concept is similar to what described above but there are several
queues, one per STA.
Packets are enqueued in the access (category) queue at dequeue time from
the air-time
packet scheduler.

On Mon, Apr 27, 2020 at 9:24 PM Dave Taht  wrote:

> It looks like the majority of what I say below is not related to the
> fate of the "bit". The push to take the bit was
> strong with this one, and me... can't we deploy more of what we
> already got in places where it matters?
>
> ...
>
> so: A) PLEA: From 10 years now, of me working on bufferbloat, working
> on real end-user and wifi traffic and real networks
>
> I would like folk here to stop benchmarking two flows that run for a long
> time
> and in one direction only... and thus exclusively in tcp congestion
> avoidance mode.
>
> Please. just. stop. Real traffic looks nothing like that. The internet
> looks nothing like that.
> The netops folk I know just roll their eyes up at benchmarks like this
> that prove nothing and tell me to go to ripe meetings instead.
> When y'all talk about "not looking foolish for not mandating ecn now",
>