Hi, Dave, strangely it looks like nobody has been copying TSVWG on this
thread, even though that is where the L4S work is happening in the IETF! :)
I just wanted to respond to one part of your message since I am
currently acting as document shepherd for the L4S drafts in TSVWG, and
it seems
Hi Dave,
> On Mar 15, 2019, at 15:06, Dave Taht wrote:
>
> I would really prefer to move this discussion to the ecn-sane mailing
> list, as IMHO, ecn is generally such a tiny thing needed for good
> congestion control compared to better transports like pacing + bbr,
> and things like bql, fq,
> On 15 Mar, 2019, at 4:44 pm, Sebastian Moeller wrote:
>
> In essence, they do not want to deal with the diffserv mess under the
> end-to-end perspective and making it reliable.
Yeah, that's pretty much what I thought. Diffserv really does need to be fixed
sometime.
>> But Codel-type AQMs
Hi Jonathan,
> On Mar 15, 2019, at 15:27, Jonathan Morton wrote:
>
>> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller wrote:
>>
>> That said, having read through the L4S architecture description and the
>> related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the
>> conclusion,
> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller wrote:
>
> That said, having read through the L4S architecture description and the
> related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the
> conclusion, that this is a mess.
>
> The L4S project proposes a really wide-ranging change
I would really prefer to move this discussion to the ecn-sane mailing
list, as IMHO, ecn is generally such a tiny thing needed for good
congestion control compared to better transports like pacing + bbr,
and things like bql, fq, and aqm using drop.
I'm going to keep cc-ing that list in the hope
Hi Dave,
I pruned the CC list as I am out of my league here and want to restrict the
radius of my embarrassment to those that already know my level of incompetence
before hand.
That said, having read through the L4S architecture description and the related
appendices of
Bufferbloat.net's ecn-sane working group members have a co-ordinated
response to your efforts brewing but it's not ready yet. We have a
worldwide team of linux and freebsd developers co-ordinating on landing
code for our competing proposal "Some Congestion Experienced", which we
submitted to tsvwg
