[Ecn-sane] [Bloat] sce materials from ietf

[Dave Taht]

Jonathan Morton <chromatix99 at gmail.com> writes:

>> On 30 Nov, 2019, at 5:42 pm, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>>>> I fear that they will come up with something that in reality will
>>> a) by opt-out, that is they will assume L4S-style feedback until
>>> reluctantly convinced that the bottleneck marker is
>>> rfc3160-compliant and hence will b) trigger too late c) trigger to
>>> rarely to be actually helpful in reality, but might show a good
>>> enough effort to push L4S past issue #16.
>>> 
>>> I'm sure they will, and we will of course point out these shortcomings as they occur, so as to count them against issue #16.  
>> 
>> 	That might be bad position to be in though (if one party only
>> gives negative feed-back no matter how justified it will generate a
>> residual feeling of lack of good faith cooperation), I would have
>> preferred if the requirements would have bee discussed before.
>> 
>>> Conversely, if they do manage to make it fail-safe, it is highly
>>> likely that their scheme will give false positives on real Internet
>>> paths and fail to switch into L4S mode, impairing their performance
>>> in other ways.
>> 
>> 	Yes, so far they always err on the advantage of L4S, and
>> justify this with "but, latency" and if one buys the latency

I do hate watching y'all continually concede the "latency" point and
have to argue on the "chosen ground" of single or dualq about
long-running tcp flows. 

"fq" already achieves "ultra-low latency" for nearly all flows,
especially including flows in the presence of bursts, short flows that
never get out of slow start (e.g. most of them), simple malicious
traffic, and so on.

The need for any additional marking "stuff" is lessened, particularly as
fq enables RTT based tcps such as BBR to work better in the first place.

codel has a target of 5ms where pie is 16ms. Neither achieve these,
but both come close, but the second "classic" queue in dualq is 3x worse
than any given queue in fq_codel.

the gross unfairness of spitting l4s marked packets through a rfc3168
compliant link is made much worse when your flows are short.

both l4s and sce both seem to have an issue in aborting slow start
too early at this point.

lastly, overusage of ecn in either system can bloat up a link.

I'm happy to see the two primary approaches to making that less
disasterous by seeing some code arrive for shortening the MSS or "sub
packet windows", but i'd still like to see cwnd 1 and the other fallback
methods in rfc3168 implemented, and there are still adversaries to
deal with (see rfc3168 sec 7)

>> justification cautiously default to rfc3168 becomes obviously
>> sub-optimal, and so far none of the chairs put down the "first, do
>> no harm" hammer (and I doubt they will).

> I got the impression that failing to close most of L4S' open issues at
> Singapore is politically damaging to them.  This is a substantial list
> of problems opened at Montreal, as blockers for their WGLC on
> publishing L4S drafts as experimental RFCs.  They had all the time in

well, I'd like to file at least one more so we can get a real
rrul test comparison done.

> the world to talk about solutions to the major showstopper problems,
> but were only able to concede a point that maybe tying RACK to the
> ECT(1) codepoint is better written as a SHOULD instead of a MUST.
> That lack of progress was noticed at the WG Chair level; I think they
> may have been giving them the rope to hang themselves, so to speak.  I
> think they had a slide up at the side session, showing massive
> unfairness between L4S and "classic" flows, for a full half-hour - and
> they somehow thought that was *helpful* to their case!

I think there is at least a small segment of the audience that thinks
that prioritizing the internet for data coming from the ISP's or mobile
operator's DC is a very good thing.

It doesn't matter how (think vpn backhauls from cell towers as one
example, or coast to coast data transfers) long term disadvantagous
RTT-unfairness may be to that mindset.

Me, I love how FQ brings true RTT fairness to the internet, offering
a shot at equal bandwidth to sites near and far, bringing the world
closer together.


> I'm reasonably sure some industry attendees also noticed this - Stuart
> Cheshire (of Apple) in particular.  Apple have been on the front lines
> of enabling ECN deployment in practice in recent years.  He invited
> me, one of the ICCRG chairs, and Bob Briscoe - among others - to
> dinner, where we discussed some technical distinctions and Bob
> demonstrated a fundamental misunderstanding of control theory.

I am glad y'all got through dinner alive.

> And we will have more ammunition at Vancouver.  It remains to be seen how much progress they'll make…
>
>  - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat