> On 29 Nov 2018, at 13:52, Jonathan Morton wrote:
>
>> On 29 Nov, 2018, at 2:06 pm, Michael Welzl wrote:
>>
>>> That's my proposal.
>>
>> - and it's an interesting one. Indeed, I wasn't aware that you're thinking
>> of a DCTCP-style signal from a string of packets.
>>
>> Of course, this
On Fri, 30 Nov 2018, Jonathan Morton wrote:
Ah, so you're thinking in terms of link-layers which perform local
retransmission, like wifi. So the optimisation is to not delay packets
"behind" a corrupted packet while the latter is retransmitted.
Yes.
It's possible for a TCP to interpret a
On Thu, 29 Nov 2018, Stephen Hemminger wrote:
The problem is that any protocol is mostly blind to the underlying
network (and that can change). To use dave's analogy it is like being
put in the driver seat of a vehicle blind folded. When you step on the
gas you don't know if it is a
On Wed, Nov 28, 2018 at 11:36 PM Jonathan Morton wrote:
>
> > On 29 Nov, 2018, at 9:28 am, Mikael Abrahamsson wrote:
> >
> > This is one thing about L4S, ETC(1) is the last "codepoint" in the header
> > not used, that can statelessly identify something. If anyone sees a better
> > way to use
>> I have to ask, why would the network care? What optimisations can be
>> obtained by reordering packets *within* a flow, when it's usually just as
>> easy to deliver them in order?
>
> Because most implementations aren't flow aware at all and might have 4
> queues, saying "oh, this single
Mario,
putting aside LoLa for a second,
I'm not quite sure that the theorem you cite is valid.
According to the model R_i is the sending rate.
The sum across all flows bottlenecked at the link does not need to be equal
to the link capacity.
The input rate can be instantaneously below or above
On Thu, Nov 29, 2018 at 10:43 AM Stephen Hemminger
wrote:
>
> On Wed, 28 Nov 2018 23:35:53 -0800
> Dave Taht wrote:
>
> > > As someone who works with moving packets, it's perplexing to me to
> > > interact with transport peeps who seem enormously focused on
> > > "goodput". My personal opinion
On Wed, 28 Nov 2018 23:35:53 -0800
Dave Taht wrote:
> > As someone who works with moving packets, it's perplexing to me to
> > interact with transport peeps who seem enormously focused on
> > "goodput". My personal opinion is that most people would be better off
> > with 80% of their available
His thesis is more clear:
https://sites.google.com/site/yuriyarbitman/Home/de-amortizedcuckoohashing
He did exclude the cost of a resize, but, still... I find the core
idea very attractive.
We swapped an email and he said:
> In general, I would say that a cryptographic hash function will do.
Hi Luca,
I'm answering on behalf of Roland, since I am a co-author of the paper.
This is an excellent question, since it goes right at the heart of how
LoLa works.
Indeed, the paper is a first of a series. A second one, looking deeper
into the fair flow balancing mechanism, is currently
Hi Roland,
It took me quite a lot of time to find this message in the thread...
I read the paper you sent and I guess this is the first of a series as many
things stay uncovered.
Just a quick question: why is X(t) always increasing with t?
On Tue, Nov 27, 2018 at 11:26 AM Bless, Roland (TM)
Hi Michael,
Am 29.11.18 um 13:12 schrieb Michael Welzl:
> I'm answering myself with an add-on thought:
>
>> On 29 Nov 2018, at 09:08, Michael Welzl wrote:
>>
>>
>>
>>> On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote:
>>>
>>> On Thu, 29 Nov 2018, Jonathan Morton wrote:
>>>
In my view,
Hi Jonathan,
Am 29.11.18 um 08:45 schrieb Jonathan Morton:
>> On 29 Nov, 2018, at 9:39 am, Dave Taht wrote:
>>
>> …when it is nearly certain that more than one flow exists, means aiming
>> for the BDP in a single flow is generally foolish.
>
> It might be more accurate to say that the BDP of
On Thu, 29 Nov 2018, Jonathan Morton wrote:
I have to ask, why would the network care? What optimisations can be
obtained by reordering packets *within* a flow, when it's usually just
as easy to deliver them in order?
Because most implementations aren't flow aware at all and might have 4
> On 29 Nov, 2018, at 2:12 pm, Michael Welzl wrote:
>
> But then, wouldn't it be good to have a way to tell the network "I don't care
> about ordering" ?
I have to ask, why would the network care? What optimisations can be obtained
by reordering packets *within* a flow, when it's usually
> On 29 Nov, 2018, at 2:06 pm, Michael Welzl wrote:
>
>> That's my proposal.
>
> - and it's an interesting one. Indeed, I wasn't aware that you're thinking of
> a DCTCP-style signal from a string of packets.
>
> Of course, this is hard to get right - there are many possible flavours to
>
I'm answering myself with an add-on thought:
> On 29 Nov 2018, at 09:08, Michael Welzl wrote:
>
>
>
>> On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote:
>>
>> On Thu, 29 Nov 2018, Jonathan Morton wrote:
>>
>>> In my view, that is the wrong approach. Better to improve Diffserv to the
> On 29 Nov 2018, at 11:30, Jonathan Morton wrote:
>
My alternative use of ECT(1) is more in keeping with the other codepoints
represented by those two bits, to allow ECN to provide more fine-grained
information about congestion than it presently does. The main challenge
On Thu, 29 Nov 2018, Sebastian Moeller wrote:
As far as I can tell intel is pushing atom/x86 cores into its
docsis SoCs (puma5/6/7) as well as into the high-end dsl SoCs (formerly
lantiq,
https://www.intel.com/content/www/us/en/smart-home/anywan-grx750-home-gateway-brief.html?wapkw=grx750),
>>> My alternative use of ECT(1) is more in keeping with the other codepoints
>>> represented by those two bits, to allow ECN to provide more fine-grained
>>> information about congestion than it presently does. The main challenge is
>>> communicating the relevant information back to the
Hi Mikael,
> On Nov 29, 2018, at 08:46, Mikael Abrahamsson wrote:
>
> On Thu, 29 Nov 2018, Jonathan Morton wrote:
>
>> You are essentially proposing using ECT(1) to take over an intended function
>> of Diffserv.
>
> Well, I am not proposing anything. I am giving people a heads-up that the
> On Nov 29, 2018, at 8:33 AM, Dave Taht wrote:
>
> This whole thread, although diversive... well, I'd really like everybody
> to get together and try to write a joint paper on the best stuff to do,
> worldwide, to make bufferbloat go away.
+1
I don’t think it’s an accident that a discussion
Hi Dave,
Am 29.11.18 um 08:39 schrieb Dave Taht:
> "Bless, Roland (TM)" writes:
>
>> Hi Luca,
>>
>> Am 27.11.18 um 11:40 schrieb Luca Muscariello:
>>> OK. We agree.
>>> That's correct, you need *at least* the BDP in flight so that the
>>> bottleneck queue never empties out.
>>
>> No, that's not
On Thu, 29 Nov 2018, Jonathan Morton wrote:
I'd say the important bits are only slightly harder than doing the same with
fq_codel.
Ok, FQ_CODEL is way off to get implemented in HW. I haven't heard anyone
even discussing it. Have you (or anyone else) heard differently?
I believe much of
Hi Dave,
Am 29.11.18 um 08:33 schrieb Dave Taht:
> "Bless, Roland (TM)" writes:
>
>> Hi Luca,
>>
>> Am 27.11.18 um 10:24 schrieb Luca Muscariello:
>>> A congestion controlled protocol such as TCP or others, including QUIC,
>>> LEDBAT and so on
>>> need at least the BDP in the transmission queue
> On 29 Nov, 2018, at 9:46 am, Mikael Abrahamsson wrote:
>
> I don't know if I've asked this but is CAKE easily implementable in hardware?
I'd say the important bits are only slightly harder than doing the same with
fq_codel. Some of the less important details might be significantly harder,
> On 29 Nov 2018, at 08:46, Mikael Abrahamsson wrote:
>
> On Thu, 29 Nov 2018, Jonathan Morton wrote:
>
>> You are essentially proposing using ECT(1) to take over an intended function
>> of Diffserv.
>
> Well, I am not proposing anything. I am giving people a heads-up that the L4S
>
27 matches
Mail list logo
