I have to admit after reviewing the tattered mess of the l4s stuff,
and the ongoing work in the tsvwg like the 40+ pager for dual queue
https://datatracker.ietf.org/wg/tsvwg/documents/
the non-proposals here:
https://datatracker.ietf.org/wg/l4s/documents/
that I'm finally inclined to make a go
> 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 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
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,
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 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
> 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
>
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 are proposing this.
But yes, you're right. Diffserv has shown itself
> 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 compared to "let's put it in a separate queue and CE-mark it
>
On Wed, 28 Nov 2018, Dave Taht wrote:
see ecn-sane. Please try to write a position paper as to where and why
ecn is good and bad.
if one day we could merely establish a talmud of commentary
around this religion it would help.
From my viewpoint it seems to be all about incremental deployment.
20 matches
Mail list logo
