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

[Jonathan Morton]

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

We do have a political ally in the form of David Black.  As one of the authors of RFC-3168, he has a natural desire to defend his work.  At Singapore I believe he mostly spoke from the floor, but he is also advocating for SCE behind the scenes.  He's actually quite encouraged by the situation at present, in which L4S were seen to bluster for 2+ hours without actually moving very much forward, while we were able to present some new work in a very limited time.

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

And we will have more ammunition at Vancouver.  It remains to be seen how much progress they'll make…

 - Jonathan Morton