thing that http heartbeat (the core of
> heartbleed) was designed to provide.
>
> It's not perfect, you can see where you really get the response from (vi
> the traceroute), and if you are going through a MITM (i.e. transparent
> proxy), all you are ever going to be able to test is the network between
> yourself and the proxy. It's up to the people who own the proxy to test
> beyond that.
>
> David Lang
>
>
> ___
> aqm mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
--
Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
So far as I'm concerned, Minstrel is as widely adopted as we could want; it
could go further, but it doesn't need any help with that. It could be
better, however, and that's a fairly straightforward change. One of the
problems with rate selection is that the standard itself has a bit to say
on wh
I think I have a good idea how to do it, actually. Or at least, I had a
design sketched out that was kind of plausible.
In essence, we have a good way of controlling queues in the IP stack, that
being fq_codel. But aggregating wifi drivers have to pull all the traffic
straight through that and q
Possibly a better simulation environment than netem would be ns-3's NSC
(network simulation cradle), which lets you connect up multiple VMs over an
emulated network in userspace... obviously, you better have a multicore
system with plenty of resources available, but it works very nicely and
needs n
Strict priority plays very badly with unmanaged devices... HTB or DRR will
have many fewer 'the network is broken' corner cases.
Or indeed, fq_codel extended with more queue lists and a matrix of
transition rules.
On Thu, May 9, 2013 at 8:54 AM, Eric Dumazet wrote:
> On Wed, 2013-05-08 at 15:2
It is quite reasonable for edge devices to not use SFQ but actual FQ with
one queue per flow (and some reasonable garbage collection heuristic). Or
to use a few thousand queues.
Most of the time connection tracking will be enabled on an edge router
anyway, so the device is paying that overhead al
On 3/12/2012, at 10:37 AM, Toke Høiland-Jørgensen wrote:
> Eric Dumazet writes:
>
>> This can help if you really want to avoid a thick flow sharing a thin
>> flow bucket, but given that all packets are going eventually into the
>> Internet (or equivalent crowded network), its not really a clea
On 28/11/2012, at 11:54 AM, "Paul E. McKenney"
wrote:
> On Tue, Nov 27, 2012 at 02:31:53PM -0800, David Lang wrote:
>> On Tue, 27 Nov 2012, Jim Gettys wrote:
>>
>>> 2) "fairness" is not necessarily what we ultimately want at all; you'd
>>> really like to penalize those who induce congestion th
On 25/11/2012, at 5:19 AM, Dave Taht wrote:
> On Sat, Nov 24, 2012 at 1:07 AM, Toke Høiland-Jørgensen wrote:
>> "Paul E. McKenney" writes:
>>
>
> Indirectly observing the web load effects on that graph, while timing
> web page completion, would be good, when comparing pfifo_fast and
> variou
