> 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 i
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 re
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 dragster
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 it
If you can think in terms of pipes, Go makes you /productive/. I
recognized that about 13 hours into learning Go about two years ago.
My advice as an aphorism: "redo something you've done at least once
before, in go, and see how different it it. Then decide if it's better"
--dave
On 2018-11-
as remarkable as our efforts have been to reduce network bloat, I have
to take my hat off to the
golang garbage collection folk, also.
Reductions in latencies from 300ms to 500us in 4 years. Good story
here about how latency is cumulative:
https://blog.golang.org/ismmkeynote
The very first thing
>> 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 qu
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 the
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 is
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 ba
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 unde
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)
w
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, th
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 the
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
qu
> 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 just
> 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
> idea
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 sender
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 L4
> 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 a
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 29 Nov, 2018, at 10:19 am, Mikael Abrahamsson 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 differentl
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 Cak
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
If you have multiple flows the BDP will change as measured at the end
points.
Also the queue occupancy has to accommodate the overshoot. If you have a
BDP in flight plus
epsilon you should not size based on the long term value but on the
overshoot.
If you don't have space for it, the long term valu
> 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,
a
> 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
> authors
31 matches
Mail list logo