Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

[Greg White <[e-mail]>]

Hi Jake,

A couple of comments.

Please don't confuse L4S with TCP Prague.  TCP Prague is just one congestion controller that is L4S compatible.  There are others, and there will likely be more in the future.  The bug you are referring to was not with L4S congestion signaling, it was with the TCP Prague implementation, and a part of that implementation (exit from slow start) where there is active research (paced chirping, etc.) and opportunity for continued evolution even after L4S gets deployed.   

The second issue you are referring to is not similar to the first.  It does not affect any flows other than the TCP Prague flow itself, and it seems to be restricted to these existing IQRouter/CAKE implementations. If we can consider improvements in the IQRouter/CAKE implementations (a not unreasonable fix for this sort of issue) a fairly minor change to fq_codel (low CE threshold marking for ECT(1) packets) would fix it.  Also (and this is speculation) a more responsive AQM such as PIE instead of CoDel probably would as well.

Greg

On 11/18/19, 8:45 AM, "tsvwg on behalf of Holland, Jake" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Ingemar,
    
    If fragmenting the space will prevent other SDOs from prematurely
    adopting the unproven L4S technology, that seems like exactly the
    right thing to do at this stage.
    
    I think we've seen strong evidence that L4S may still contain
    show-stopping problems.  Also that we have not yet seen strong
    evidence that the problems stemming from the ambiguity in the
    L4S signaling design can be fixed.
    
    This carries a demonstrated potential for breaking existing
    ECN deployments by under-responding to the already widely-deployed
    congestion feedback systems.
    
    Certainly L4S's implementation was demonstrated to contain an
    issue that would have wrecked the latency of existing ECN
    deployments, and it had not previously been detected, despite the
    years of lab evaluation and repeated requests from reviewers to
    test such scenarios earlier.

    Although a fix was found for the specific initially-demonstrated
    case, no fix has yet been demonstrated for what looks to be a very
    similar issue occurring with staggered flow startup, which can't
    be attributed to a wrong alpha starting value:
    https://trac.ietf.org/trac/tsvwg/ticket/17#comment:8
    
    The proposed pseudocode fix (with up to 5 tuning parameters, IIRC)
    may or may not be able to address this for specific cases, and it
    may or may not be possible to discover a set of tuning values that
    can address a wide range of conditions, but it seems appropriate
    to have some skepticism, at least until demonstration of successful
    operation under a wide range of conditions, given the history of
    such proposals.  This suggests that we do the opposite of
    encouraging other SDOs to move broadly forward with L4S at this time.
    
    I share your concern that we might lose the codepoint (and the low
    latency functionality), and I acknowledge that a persistently
    fragmented space introduces a risk that it never happens, or takes
    an extra decade.
    
    But the risk that concerns me even more is if L4S gets rolled out
    and then these kinds of issues are discovered in production, after
    other SDOs have prematurely standardized on this experiment, and it
    therefore gets shut off with prejudice against future solutions.
    That outcome also would lose the use of the codepoint, probably
    even more permanently.
    
    (Or even worse: if it does not get shut off in spite of the problems
    it causes, which loses even the low-ish latency solutions we already
    have, and adds to the congestion control aggression arms race.)
    
    IMO, those would be even worse outcomes than a somewhat delayed
    adoption of a fully vetted system (or at least one that can't break
    existing deployed networks).
    
    Best regards,
    Jake
    
    PS: I still don't understand why the gains available through the
    use of regular AQM (especially with ECN) have not been more widely
    adopted by the other SDOs that would want to make use of L4S.
    
    It seems possible already to reduce the application-visible delay
    spikes from ~200ms to ~20ms (provided that no overly aggressive
    competing traffic improperly ignores the feedback, or that
    flow-queuing or other queue protection mechanisms are more widely
    deployed to prevent excessive damage from aggressive flows to less
    aggressive competing flows).
    
    I wonder if whatever would drive SDOs to start using L4S maybe
    could instead be leveraged to drive adoption of the much more well-
    proven existing ECN solutions, which at least already have a lot
    of endpoint support deployed.
    
    The endpoint support is a critical component to making this useful,
    and I see no reason to believe it'll be any quicker than the existing
    regular ECN was.  I'd even expect less so, since the behavior is much
    more complicated and hard to test.
    
    PPS: I agree it would be interesting to see paced chirping solutions
    to help do better than slow start, and to quickly grow when new
    capacity opens on-path.  But I'll point out that's not specific to L4S,
    but rather should have application for any CC that can avoid pushing
    the network until queue overflow, which to me likely includes regular
    ECN-enabled Reno or Cubic, as well as BBR.
    
    However, as yet another unproven TBD, I'll suggest it's not very
    useful as a strong influence on this debate, in spite of the early
    demos using L4S.  Regardless of the ultimate low latency solution,
    that part will need further development and might not work.