Hi Greg,
On 2019-03-20, 13:55, "Greg White" wrote:
In normal conditions, L4S offers "Maximize Throughput" + "Minimize Loss" +
"Minimize Latency" all at once. It doesn't require an application to have to
make that false choice (hence the name "Low Latency Low Loss Scalable
throughput").
Hi Sebastian,
+1 on "approximate classifier" and CE. This does have me worried,
particularly in the case of multiple AQMs inline.
I think we mostly agree here, and my default position is still
that because SCE is cleaner, I like it better unless L4S can
demonstrate significant value over SCE.
> On 21 Mar, 2019, at 1:29 am, Bob Briscoe wrote:
>
>> But more importantly, the L4S usage couples the minimized latency use
>> case to any possibility of getting a high fidelity explicit congestion
>> signal, so the "maximize throughput" use case can't ever get it.
> Eh? There's definitely a
Hi Jake,
> On Mar 21, 2019, at 00:11, Holland, Jake wrote:
>
> I think it's a fair point that even as close as the non-home side
> of the access network, fq would need a lot of queues, and if you
> want something in hardware it's going to be tricky. I hear
> they're up to an average of ~6k
Jake,
On 20/03/2019 19:04, Holland, Jake wrote:
Hi Bob & Greg,
I agree there has been a reasonably open conversation about the L4S
work, and thanks for all your efforts to make it so.
However, I think there's 2 senses in which "private" might be fair that
I didn't see covered in your
> On 21 Mar, 2019, at 1:11 am, Holland, Jake wrote:
>
> I think it's a fair point that even as close as the non-home side
> of the access network, fq would need a lot of queues, and if you
> want something in hardware it's going to be tricky. I hear
> they're up to an average of ~6k homes per
Super, much appreciated!
My thoughts about "effective lifetime" just got a long tail, possibly
sufficient to wag the dog (:-))
Do you think we should be shifting to v6, and keeping v4 nearly
invariant to address the long tail?
--dave
On 2019-03-20 6:28 p.m., Jonathan Morton wrote:
> I still
I think it's a fair point that even as close as the non-home side
of the access network, fq would need a lot of queues, and if you
want something in hardware it's going to be tricky. I hear
they're up to an average of ~6k homes per OLT.
I don't think the default assumption here should be that
> On 21 Mar, 2019, at 12:56 am, Sebastian Moeller wrote:
>
> What they should have done, IMHO is teach their AQM something like SCE so it
> can easily react to CE and drops in a standard compliant TCP-friendly
> fashion, and only do the clever window/rate adjustments if the AQM signals
>
On Wed, 20 Mar 2019, David Collier-Brown wrote:
On 2019-03-20 4:29 p.m., David Lang wrote:
On Wed, 20 Mar 2019, David Collier-Brown wrote:
On 2019-03-20 10:28 a.m., Mikael Abrahamsson wrote:
This isn't a resource problem, it's a code problem. The IETF wants 10-15
year old hosts to be
> On Mar 20, 2019, at 23:31, Jonathan Morton wrote:
>
>> On 21 Mar, 2019, at 12:12 am, Sebastian Moeller wrote:
>>
>> they see 20ms queue delay with a 7ms base link delay @ 40 Mbps
>
> At 40Mbps you might as well be running Cake, and thereby getting 1ms
> inter-flow induced delay; an order
> On 21 Mar, 2019, at 12:12 am, Sebastian Moeller wrote:
>
> they see 20ms queue delay with a 7ms base link delay @ 40 Mbps
At 40Mbps you might as well be running Cake, and thereby getting 1ms inter-flow
induced delay; an order of magnitude better. And we achieved that o a
shoestring budget
I still have a functioning "UFO"-style Apple Airport Base Station from about
2000. I no longer have a convenient means of reconfiguring it (relies on a
real Mac within a certain range of vintages), let alone updating its firmware,
if Apple bothered to do that any more.
A lot of those died
Hi ECN-sane,
I reduced the CC list as I do not expect this to further the discussion much,
but since I feel I invested too much time reading the L4S RFCs and papers I
still want to air this here to get some feedback.
> On Mar 20, 2019, at 21:55, Greg White wrote:
>
> In normal conditions,
> On 20 Mar, 2019, at 11:48 pm, Greg White wrote:
>
> the dual queue mechanism is not the only way to support L4S and TCP Prague.
> As we’ve mentioned a time or two, an fq_codel system can also support L4S and
> TCP Prague. I’m not aware that anyone has implemented it to test it out yet
>
I responded to point 2 separately. In response to point 1, the dual queue
mechanism is not the only way to support L4S and TCP Prague. As we’ve
mentioned a time or two, an fq_codel system can also support L4S and TCP
Prague. I’m not aware that anyone has implemented it to test it out yet
On 2019-03-20 4:29 p.m., David Lang wrote:
On Wed, 20 Mar 2019, David Collier-Brown wrote:
On 2019-03-20 10:28 a.m., Mikael Abrahamsson wrote:
This isn't a resource problem, it's a code problem. The IETF wants
10-15 year old hosts to be able to connect to a network and perform
basic
In normal conditions, L4S offers "Maximize Throughput" + "Minimize Loss" +
"Minimize Latency" all at once. It doesn't require an application to have to
make that false choice (hence the name "Low Latency Low Loss Scalable
throughput").
If an application would prefer to "Minimize Cost",
On Wed, 20 Mar 2019, David Collier-Brown wrote:
On 2019-03-20 10:28 a.m., Mikael Abrahamsson wrote:
This isn't a resource problem, it's a code problem. The IETF wants 10-15
year old hosts to be able to connect to a network and perform basic
networking. It might not be very optimized, but
On 2019-03-20, 12:58, "Stephen Hemminger" wrote:
Has anyone done a detailed investigation for prior art?
I don't know, but for serendipitous reasons I recently came across this,
which may be interesting to those who would be interested in digging
further on that question:
> On 20 Mar, 2019, at 9:39 pm, Gorry Fairhurst wrote:
>
> Concerning "Maximize Throughput", if you don't need scalability to very high
> rates, then is your requirement met by TCP-like semantics, as in TCP with
> SACK/loss or even better TCP with ABE/ECT(0)?
My intention with "Maximise
On 2019-03-20, 12:40, "Gorry Fairhurst" wrote:
Concerning "Maximize Throughput", if you don't need scalability to very
high rates, then is your requirement met by TCP-like semantics, as in
TCP with SACK/loss or even better TCP with ABE/ECT(0)?
[JH] A problem with TCP with BE/ECT(0)
On Wed, 20 Mar 2019 19:04:17 +
"Holland, Jake" wrote:
> Hi Bob & Greg,
>
> I agree there has been a reasonably open conversation about the L4S
> work, and thanks for all your efforts to make it so.
>
> However, I think there's 2 senses in which "private" might be fair that
> I didn't see
Hi Bob & Greg,
I agree there has been a reasonably open conversation about the L4S
work, and thanks for all your efforts to make it so.
However, I think there's 2 senses in which "private" might be fair that
I didn't see covered in your rebuttals (merging forks and including
Greg's rebuttal by
On 2019-03-20 10:28 a.m., Mikael Abrahamsson wrote:
On Mon, 18 Mar 2019, Dave Taht wrote:
Another ietf idea that makes me crazy is the motto of "no host
changes" in homenet, and "dumb endpoints" - when we live in an age
where we have quad cores and AI coprocessors in everybody's hands.
Dumb
On Mon, 18 Mar 2019, Dave Taht wrote:
Another ietf idea that makes me crazy is the motto of "no host changes"
in homenet, and "dumb endpoints" - when we live in an age where we have
quad cores and AI coprocessors in everybody's hands.
This isn't a resource problem, it's a code problem. The
Dear All,
> On Mar 20, 2019, at 00:59, Dave Taht wrote:
>
> On Tue, Mar 19, 2019 at 5:44 AM Greg White wrote:
>> [...]
>> But, L4S has been demonstrated in real equipment and in simulation, and
>> leverages an existing congestion
>
> Not under circumstances I can control. That's Not
27 matches
Mail list logo
