On Sun, 2013-03-17 at 12:24 -0700, Stephen Hemminger wrote:
> On Sun, 17 Mar 2013 15:12:16 -0400
> Jim Gettys wrote:
>
> > As a result, at the last Linux Plumber's Conference in August, there was
> > general consensus that we could replace PFIFO_FAST as the default qdisc in
> > Linux, awaiting ju
On Sun, 17 Mar 2013 15:12:16 -0400
Jim Gettys wrote:
> As a result, at the last Linux Plumber's Conference in August, there was
> general consensus that we could replace PFIFO_FAST as the default qdisc in
> Linux, awaiting just our confidence that fq_codel (or something very
> similar) was mature
On Sun, 17 Mar 2013, Jim Gettys wrote:
Secondly, an extremely important factoid about why we got so excited
about fq_codel (which is really DRR, in term derived from SFQ, combined
with CoDel along with detecting thin vs. thick flows) is its
performance:
I can imagine! One thought, have tests
To begin with, I tend to use the term 'flow queuing' to distinguish what
we're doing with classic "fair queuing", which is overbound in most
people's minds, and some of what we do is "unfair" by some metrics.
Secondly, an extremely important factoid about why we got so excited about
fq_codel (whic
s
transmission behavior as if the packet had been dropped, but there's no
need to retransmit this packet."
Thanks,
--David (RFC 3168 co-author)
> -Original Message-
> From: tsv-area-boun...@ietf.org [mailto:tsv-area-boun...@ietf.org] On Behalf
> Of Mikael Abrahamsson
>
Hi,
Sorry in case I misunderstood. More below:
On Mar 14, 2013, at 6:54 AM, Fred Baker (fred) wrote:
>
> On Mar 14, 2013, at 12:43 AM, Michael Welzl wrote:
>
>> Great, I turn on ECN, and that gives me more delay, just what I want!
>> And, even better: the more people use ECN, the more delay
This will be my last note on the topic on tsvwg. I'd like to believe that by
tomorrow we will have all joined aqm@.
On Mar 14, 2013, at 6:54 AM, Fred Baker (fred) wrote:
>
> On Mar 14, 2013, at 12:43 AM, Michael Welzl wrote:
>
>> Great, I turn on ECN, and that gives me more delay, just what
On Mar 14, 2013, at 12:43 AM, Michael Welzl wrote:
> Great, I turn on ECN, and that gives me more delay, just what I want!
> And, even better: the more people use ECN, the more delay everybody gets.
>
> Seriously, I see the incentive idea behind this two-level marking idea, but
> one has to ca
On Thu, 14 Mar 2013, Michael Welzl wrote:
As I just said to Mikael, I don't think I worded that one well. I'm
envisaging two thresholds, testing two stress levels. It a lower one, one
marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher
one, one drops from all traffic. What
On Wed, 13 Mar 2013, Andrew McGregor wrote:
A Netgear WNDR3800 (680MHz MIPS) can handle fq_codel on two flat out
802.11n interfaces at the same time and still be very lightly loaded.
CPU is not a problem because fq_codel is a tiny fraction of the usage of
the firewall, connection tracking and
Clarification in line, sorry:
On Mar 14, 2013, at 12:43 AM, Michael Welzl wrote:
> Hi,
>
> About this two-level threshold idea:
>
>>> As I just said to Mikael, I don't think I worded that one well. I'm
>>> envisaging two thresholds, testing two stress levels. It a lower one, one
>>> marks ECN-
Hi,
About this two-level threshold idea:
>> As I just said to Mikael, I don't think I worded that one well. I'm
>> envisaging two thresholds, testing two stress levels. It a lower one, one
>> marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher
>> one, one drops from all tra
On Wed, 13 Mar 2013, Fred Baker (fred) wrote:
That depends on how FQ is implemented. The implementation I did in 1994
probably would have been high overhead. It has been minted by others,
and I believe rewritten to be a calendar queue implementation. For that,
I would not expect it was that mu
I think this is the kernel of something useful, a few comments in-line.
> On Mar 13, 2013, at 2:28 PM,
> wrote:
>
>> Fred,
>>
>> Comments below:
>>
>> Section 2, pt 2
>> "Deployed AQM SHOULD use ECN as well as loss, and set thresholds
>> to mark traffic earlier than it is lost."
>> - This is not
On Mar 13, 2013, at 2:28 PM,
wrote:
> Fred,
>
> Comments below:
>
> Section 2, pt 2
> "Deployed AQM SHOULD use ECN as well as loss, and set thresholds
> to mark traffic earlier than it is lost."
> - This is not clear, I agree SHOULD use ECN for ECT traffic, of course.
> - I'm not sure about t
On Mar 13, 2013, at 1:25 PM, Mikael Abrahamsson
wrote:
> On Wed, 13 Mar 2013, Fred Baker (fred) wrote:
>
>> Folks. I posted the email I sent yesterday as a draft, for discussion. I
>> welcome comments, and if substantive comments are made, suggested text.
>
> I voiced my opinion on the tsv-a
Fred,
Comments below:
Section 2, pt 2
"Deployed AQM SHOULD use ECN as well as loss, and set thresholds
to mark traffic earlier than it is lost."
- This is not clear, I agree SHOULD use ECN for ECT traffic, of course.
- I'm not sure about threshold question that sets ECN drop before ECN loss
- I
On Wed, 13 Mar 2013, Fred Baker (fred) wrote:
Folks. I posted the email I sent yesterday as a draft, for discussion. I
welcome comments, and if substantive comments are made, suggested text.
I voiced my opinion on the tsv-area meeting via jabber that AQM especially
on low/medium bw links (up
18 matches
Mail list logo
