On Thu, Feb 26, 2015 at 2:44 AM, Mikael Abrahamsson wrote:
> On Thu, 26 Feb 2015, Toke Høiland-Jørgensen wrote:
>
>> Erm, how does that work? What part of the functionality can reasonably be
>> moved to the data center? The configuration web interface?
>
>
> Basically you extend the home L2 domain
On Thu, Feb 26, 2015 at 10:59 AM, Mikael Abrahamsson wrote:
> On Thu, 26 Feb 2015, Dave Taht wrote:
>
>> First, everyone saying that fq_codel can't be done in hardware is *wrong*
>> See my last point far below, I know I write over-long emails...
>
>
> What do you define as "hardware"?
>
>> YES, at
> We need to be careful to specify behaviors, as opposed to
implementations. If we start to specify implementation details, the process
will get bogged down in intractable differences.
I understand these sorts of requirements. Since I'm waiting for one of my
computers to do something substantial,
: Thursday, February 26, 2015 1:59 PM
To: Dave Taht
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] RED against bufferbloat
On Thu, 26 Feb 2015, Dave Taht wrote:
> First, everyone saying that fq_codel can't be done in hardware is
> *wrong* See my last point far below, I know I write over
On Thu, 26 Feb 2015, Dave Taht wrote:
First, everyone saying that fq_codel can't be done in hardware is
*wrong* See my last point far below, I know I write over-long emails...
What do you define as "hardware"?
YES, at the lowest level of the hardware, where packets turn into light
or fuzzy e
On Thu, Feb 26, 2015 at 9:04 AM, Dave Taht wrote:
> On Thu, Feb 26, 2015 at 7:18 AM, MUSCARIELLO Luca IMT/OLN
> wrote:
>> On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote:
>>
>> On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
>>
>> Done with the vendor itself with related NDA etc. It takes l
On Thu, Feb 26, 2015 at 7:18 AM, MUSCARIELLO Luca IMT/OLN
wrote:
> On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote:
>
> On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
>
> Done with the vendor itself with related NDA etc. It takes longer to set the
> agreement than coding the system. The pro
On 02/26/2015 03:18 PM, Mikael Abrahamsson wrote:
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
Done with the vendor itself with related NDA etc. It takes longer to
set the agreement than coding the system. The problem is that this
process is not ok. An ISP cannot maintain someone else
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
Done with the vendor itself with related NDA etc. It takes longer to set
the agreement than coding the system. The problem is that this process
is not ok. An ISP cannot maintain someone else product if it is closed.
Do you have a requiremen
On 02/26/2015 01:54 PM, Mikael Abrahamsson wrote:
On Wed, 25 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
MIPS based board with a central unit and several programmable asics
as accelerators. Fast path is not managed by the central unit.
And you made the programmable asics to FQ? I'd love to be a
On Thu, 26 Feb 2015, Jonathan Morton wrote:
However it does demonstrate that a quad Cortex A7 CPU cluster is now
very cheap to implement. One of those integrated with a couple of GMACs
and a couple of PCIe lanes for Wi-Fi would make a good router SoC.
I for instance think this looks promising
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
Also possibly that the whole SDN movement means hardware will get
standardized APIs so in case there is hardware acceleration on the CPE,
this can be handled by any kernel and not just the kernel that the vendor
has modified to work with the
On Wed, 25 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
MIPS based board with a central unit and several programmable asics as
accelerators. Fast path is not managed by the central unit.
And you made the programmable asics to FQ? I'd love to be able to pitch
this to vendors as an example what sh
> But do we know whether mobile phone SOCs actually make good routers?
Many of them probably don't, due to limited off chip I/O bandwidth, but
their CPU cores would be useful in an SoC which did have such bandwidth.
The BCM2435/6 used in the Raspberry Pi/2 is a classic example of such a
phone SoC
On 02/26/2015 11:39 AM, Mikael Abrahamsson wrote:
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
I wonder when we'll have software routers in residential networks to
innovate a little faster than what happens today just like how
already happens in some data centers.
Well, it would help
On 26 Feb 2015 12:45, "Mikael Abrahamsson" wrote:
> The only thing left in the home is basically L2 bridging between WAN, LAN
and Wifi and the possibiliy of configuring settings such as Wifi SSID,
crypto etc.
Funny, I thought that was what CPE was supposed to do in the first place.
The only thing
On Feb 26, 2015, at 11:44 , Mikael Abrahamsson wrote:
> On Thu, 26 Feb 2015, Toke Høiland-Jørgensen wrote:
>
>> Erm, how does that work? What part of the functionality can reasonably be
>> moved to the data center? The configuration web interface?
>
> Basically you extend the home L2 domain v
Mikael Abrahamsson writes:
> Basically you extend the home L2 domain via some kind of tunnel or
> vlan to a server, and run the CPE there.
>
> The only thing left in the home is basically L2 bridging between WAN,
> LAN and Wifi and the possibiliy of configuring settings such as Wifi
> SSID, crypt
Hi Mikael,
On Feb 26, 2015, at 11:39 , Mikael Abrahamsson wrote:
> On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
>
>> I wonder when we'll have software routers in residential networks to
>> innovate a little faster than what happens today just like how already
>> happens in some data
On Thu, 26 Feb 2015, Toke Høiland-Jørgensen wrote:
Erm, how does that work? What part of the functionality can reasonably
be moved to the data center? The configuration web interface?
Basically you extend the home L2 domain via some kind of tunnel or vlan to
a server, and run the CPE there.
Mikael Abrahamsson writes:
> Right now I hear more about "virtualised CPE" to save cost (ie move
> part of the CPE implementation to the data center) than to spend more
> money on features in the CPE.
Erm, how does that work? What part of the functionality can reasonably
be moved to the data cen
On Thu, 26 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
I wonder when we'll have software routers in residential networks to
innovate a little faster than what happens today just like how already
happens in some data centers.
Well, it would help if operators tried to buy CPEs taht were not only
Hi Bob,
On Feb 25, 2015, at 18:28 , Bob Briscoe wrote:
> Alex,
>
> At 09:31 25/02/2015, Alex Elsayed wrote:
>> It was less a criticism of your work itself, and more pointing out that Bob
>> Briscoe was applying research on symmetric paths to asymmetric paths without
>> questioning the applicab
On 02/25/2015 07:39 PM, Bill Ver Steeg (versteb) wrote:
Regarding the statement
We're not going to see FQ_CODEL on a 200 interface large router
designed to push 100 gigabit/s of traffic, at least not in any
interesting price point.
There are two points under the covers here. I would say a 2 mor
> On 25 Feb, 2015, at 21:25, Hal Murray wrote:
>
>> That's easy enough. You can fit an awful lot of linked list pointers into
>> the space of a single IP packet. Even if you're only assigning 64KB per
>> subscriber, you can store 43 full packets and still have pointers to spare.
>> A properly fu
> On 25. feb. 2015, at 20.04, David Lang wrote:
>
> On Wed, 25 Feb 2015, Michael Welzl wrote:
>
>> 2) Not everyone will always want FQ everywhere. There are potential
>> disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow
>> problem). What's necessary is to quantify them - to
> That's easy enough. You can fit an awful lot of linked list pointers into
> the space of a single IP packet. Even if you're only assigning 64KB per
> subscriber, you can store 43 full packets and still have pointers to spare.
> A properly functioning AQM should mostly keep the queue smaller than
On Wed, 25 Feb 2015, Michael Welzl wrote:
2) Not everyone will always want FQ everywhere. There are potential
disadvantanges (e.g. the often mentioned with-a-VPN-I'm-only-1-flow problem).
What's necessary is to quantify them - to see how the effect of FQ (or
FQ_CoDel's changed FQ) plays out, a
f Mikael Abrahamsson
Sent: Wednesday, February 25, 2015 9:06 AM
To: Toke Høiland-Jørgensen
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] RED against bufferbloat
On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:
> So you mean comparing the scenario where the AQM runs on both sides of
sts.bufferbloat.net
[mailto:bloat-boun...@lists.bufferbloat.net] On Behalf Of Toke Høiland-Jørgensen
Sent: Wednesday, February 25, 2015 6:05 AM
To: Mikael Abrahamsson
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] RED against bufferbloat
Mikael Abrahamsson writes:
> To me, FQ is import
On Wed, Feb 25, 2015 at 9:28 AM, Bob Briscoe wrote:
> Alex,
>
> At 09:31 25/02/2015, Alex Elsayed wrote:
>>
>> It was less a criticism of your work itself, and more pointing out that
>> Bob
>> Briscoe was applying research on symmetric paths to asymmetric paths
>> without
>> questioning the applic
On Wed, Feb 25, 2015 at 12:06 AM, Bob Briscoe wrote:
> Sahil,
>
> At 06:46 25/02/2015, Mikael Abrahamsson wrote:
>>
>> On Tue, 24 Feb 2015, sahil grover wrote:
>>
>>> (i) First of all,i want to know whether RED was implemented or not?
>>> if not then what were the reasons(major) ?
>>
>>
>> RED has
> A single FQ instantiation has to consume no more memory than a single
FIFO instantiation.
That's easy enough. You can fit an awful lot of linked list pointers into
the space of a single IP packet. Even if you're only assigning 64KB per
subscriber, you can store 43 full packets and still have poi
On 02/25/2015 05:09 PM, Mikael Abrahamsson wrote:
On Wed, 25 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
Doing FQ in silicon is easy. It must be very easy as I did myself in
a MIPS Ikanos Vx185 chipset and I am not an hardware expert. This was
for a CPE with a 5X1Gbps ports.
I guess we have di
Alex,
At 09:31 25/02/2015, Alex Elsayed wrote:
It was less a criticism of your work itself, and more pointing out that Bob
Briscoe was applying research on symmetric paths to asymmetric paths without
questioning the applicability of its conclusions.
Mea culpa.
Just one ambiguous inference and
Hi Mikael,
On Feb 25, 2015, at 14:36 , Mikael Abrahamsson wrote:
> On Wed, 25 Feb 2015, Sebastian Moeller wrote:
>
>> The only argument for ingress shaping on the CPE is that this allows
>> the end user to define her own QOS criteria independent of the ISPs wishes.
>> Best of both world
On Wed, 25 Feb 2015, MUSCARIELLO Luca IMT/OLN wrote:
Doing FQ in silicon is easy. It must be very easy as I did myself in a
MIPS Ikanos Vx185 chipset and I am not an hardware expert. This was for
a CPE with a 5X1Gbps ports.
I guess we have different definitions on what "silicon" is. Mine is
On 02/25/2015 02:36 PM, Mikael Abrahamsson wrote:
As I said before, doing FQ_CODEL in the AR is an expensive proposition
for medium and high speed access. So if this could successfully be
pushed to the CPE it would mean it would be more widely deployed.
I do not agree. Well, it depends on w
On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:
So you mean comparing the scenario where the AQM runs on both sides of
the bottleneck to one where it runs as an ingress shaper on one side
only?
Yes. How much lower speed/rate would the CPE ingress (internet->CPE) AQM
have to run at to have
Mikael Abrahamsson writes:
> I am very much aware that this is being done (I have done it myself),
> but my question was if someone had actually done this in a lab and
> found out how well it works in RRUL tests etc.
So you mean comparing the scenario where the AQM runs on both sides of
the bott
On Wed, 25 Feb 2015, Sebastian Moeller wrote:
The only argument for ingress shaping on the CPE is that this
allows the end user to define her own QOS criteria independent of the
ISPs wishes. Best of both worlds would be user configurable QOS-shaping
on the slam/bras/whatever…
As I said befo
Hallo Mikael,
On Feb 25, 2015, at 11:47 , Mikael Abrahamsson wrote:
> On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:
>
>> While the academic side of me enjoys studying AQMs (and I'm still far from
>> anything resembling a thorough understanding of them), the practical "I just
>> want my n
To add my tuppence to this discussion:
I don't believe real world topologies and workloads are incompatible with
academic experimentation. All you have to do is replicate the same workload
and other conditions across each of the qdiscs you're testing, ie to change
only the qdisc between test runs.
Michael Welzl writes:
> +1, certainly it has a big influence. This has been well known for
> many years though, and documented broadly, perhaps most notably by Jim
> Roberts.
Being "well known for many years" in the academic community
unfortunately doesn't translate into deployment. Which is why
Mikael Abrahamsson writes:
> To me, FQ is important especially for lower speeds. This also maps
> well into the CPU based nature of FQ (that it's hard to do in
> "silicon").
Well my research has been mainly focused on the consumer / edge case.
I.e. things a Linux box can drive in hardware, so up
Michael Welzl wrote:
>
>> On 25 Feb 2015, at 10:31, Alex Elsayed
>> wrote:
>>
>> Michael Welzl wrote:
>>
>>> Two points,
>>>
>>> below...
>>>
>>> On 25 Feb 2015, at 09:42, Alex Elsayed
>>> mailto:eternaleye-
>> re5jqeeqqe8avxtiumw...@public.gmane.org>>
>>> wrote:
>>
>>> Why exactly did you
> On 25 Feb 2015, at 11:24, t...@toke.dk wrote:
>
> Michael Welzl writes:
>
>> but that's FQ (or FQ_CoDel's changed FQ variant), much more than the
>> AQM mechanism in use (as we have also seen presented by Toke at the
>> last ICCRG meeting).
>
> Well, actually, that presentation did also incl
On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:
While the academic side of me enjoys studying AQMs (and I'm still far
from anything resembling a thorough understanding of them), the
practical "I just want my network to work" side of me has become
increasingly convinced (in part by doing the
> On 25 Feb 2015, at 10:31, Alex Elsayed wrote:
>
> Michael Welzl wrote:
>
>> Two points,
>>
>> below...
>>
>> On 25 Feb 2015, at 09:42, Alex Elsayed
>> mailto:eternaleye-
> re5jqeeqqe8avxtiumw...@public.gmane.org>>
>> wrote:
>
>> Why exactly did you think we should have looked at asymmetric
Michael Welzl writes:
> but that's FQ (or FQ_CoDel's changed FQ variant), much more than the
> AQM mechanism in use (as we have also seen presented by Toke at the
> last ICCRG meeting).
Well, actually, that presentation did also include an evaluation of the
AQMs in an asymmetrical scenario. And
> On 25 Feb 2015, at 10:29, Sebastian Moeller wrote:
>
> Hi Michael,
>
> On Feb 25, 2015, at 10:18 , Michael Welzl wrote:
>
>> Two points,
>>
>> below...
>>
>> [...]
>> Why exactly did you think we should have looked at asymmetric paths? To
>> study what?
>> ( I'm not debating that asymmet
Michael Welzl wrote:
> Two points,
>
> below...
>
> On 25 Feb 2015, at 09:42, Alex Elsayed
> mailto:eternaleye-
re5jqeeqqe8avxtiumw...@public.gmane.org>>
> wrote:
> Why exactly did you think we should have looked at asymmetric paths? To
> study what? ( I'm not debating that asymmetric paths pla
Hi Michael,
On Feb 25, 2015, at 10:18 , Michael Welzl wrote:
> Two points,
>
> below...
>
> [...]
> Why exactly did you think we should have looked at asymmetric paths? To study
> what?
> ( I'm not debating that asymmetric paths play out different in behavior. I'm
> just saying that one need
Two points,
below...
On 25 Feb 2015, at 09:42, Alex Elsayed
mailto:eternal...@gmail.com>> wrote:
Bob Briscoe wrote:
Sahil,
At 06:46 25/02/2015, Mikael Abrahamsson wrote:
On Tue, 24 Feb 2015, sahil grover wrote:
(i) First of all,i want to know whether RED was implemented or not?
if not then w
Bob Briscoe wrote:
> Sahil,
>
> At 06:46 25/02/2015, Mikael Abrahamsson wrote:
>>On Tue, 24 Feb 2015, sahil grover wrote:
>>
>>>(i) First of all,i want to know whether RED was implemented or not?
>>>if not then what were the reasons(major) ?
>>
>>RED has been available on most platforms, but it w
David Lang wrote:
> On Wed, 25 Feb 2015, Mikael Abrahamsson wrote:
>
>> On Tue, 24 Feb 2015, sahil grover wrote:
>>
>>> (i) First of all,i want to know whether RED was implemented or not?
>>> if not then what were the reasons(major) ?
>>
>> RED has been available on most platforms, but it was gen
Sahil,
At 06:46 25/02/2015, Mikael Abrahamsson wrote:
On Tue, 24 Feb 2015, sahil grover wrote:
(i) First of all,i want to know whether RED was implemented or not?
if not then what were the reasons(major) ?
RED has been available on most platforms, but it was generally not
turned on. It also
On Tue, 24 Feb 2015, David Lang wrote:
more importantly (as I understand it), if you use RED while the rest of
the users on the network stick with stock systems, you will keep
yielding to them and only get to use a fraction of the available
bandwidth.
I have a hard time imagining a setup whe
On Wed, 25 Feb 2015, Mikael Abrahamsson wrote:
On Tue, 24 Feb 2015, sahil grover wrote:
(i) First of all,i want to know whether RED was implemented or not?
if not then what were the reasons(major) ?
RED has been available on most platforms, but it was generally not turned on.
It also needs
On Tue, 24 Feb 2015, sahil grover wrote:
(i) First of all,i want to know whether RED was implemented or not?
if not then what were the reasons(major) ?
RED has been available on most platforms, but it was generally not turned
on. It also needs configuration from an operator, and it's hard to
Good, point. I like to think of the original RED as more 1) noting that all
those full buffers weren't doing anyone any good and 2) noting that one
could perhaps be aware of creeping congestion and "gently" prevent it.
Those two items are still important it's just that making 2) work has more
"ah
(i) First of all,i want to know whether RED was implemented or not?
if not then what were the reasons(major) ?
anyone please tell me in simple words here only,because i don't want to
read any paper like "RED in a different light".
(ii)Second, as we all know RED controls the average queue size fro
62 matches
Mail list logo
