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

Mon Dec 2 02:54:30 EST 2019

Hi Dave,

On December 2, 2019 6:38:11 AM GMT+01:00, Dave Taht <dave at taht.net> wrote:
>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

Well, they have pretty graphs to wield around hitting their PR target of ~1ms queueing delay. I had a trawl through the bake-off data but all SCE results I found show noticeably larger delays (not bad by any standards, but a much harder sell than the simple <1ms story) I might not have looked to carefully though?

>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. 

         In the dual queue draft the reference latency sits at 15ms without a good rationale, I would love to see dual queue results at short RTT with a theoretically justified 5 Ms target, to see whether that counteracts the equitable sharing failure.

Neither achieve these,
>but both come close, but the second "classic" queue in dualq is 3x
>worse
>than any given queue in fq_codel.

         My take on that is: Bob must have realized early on that equal sharing very much is not optimal, if you know more about the relative importance of the flows you can do better. (He ignores that as the other side of the coin you can easily do worse, simply permute the latencies and bandwidth of the optimal asymmetric set, but I degrees) And now he struggles in getting this information in the first place and in distributing it to the hops that are in a position to act on this information. The informational ConEx RFC 6789 is a great example of that quixotic quest, where Bob proposes the punish flows based on their total experienced congestion on the full path. 
In short FQ is not perfect, but neither is anything goes, and FQ has fewer catastrophic failure modes, and the one it has, sensitivy to flow count can a) be remedied by an appropriate flow definition (maybe just a 2-tuple for backbone routers, or even by AS on peering routers, already recognised in rfc2914) and b) anything goes is equally sensitive to the same condition. I really hate the line of argument, since we can not come up with a perfect solution, let's do nothing: that is not how evolution operates.

>
>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.

       According to Koen, PIE is stricter than vodel in bringing down the hammer on flows not reacting fast enough though, so the level of ECN bloat might be a function of the employed AQM, no?

>
>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.

        But also one that can get you on the hot chair with the regulator quickly if the ISP charges extra... 

>
>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.

        This is why I hope for more push back from the IETF community....

>
>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 effortlessly seems to simply doba number of things pretty well and is conceptionally simple to understand and it's behavior is easily predictable, what is not to love about it, except the apparent lack of a fast in silicon implementation....

Best Regards
        Sebastian

>
>
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.