Re: [tsvwg] L4S vs SCE (Evolvability)

[Greg White <[e-mail]>]

David,
See [GW] below.
Greg

On 1/1/20, 4:33 PM, "tsvwg on behalf of Black, David" <[e-mail] on behalf of [e-mail]> wrote:

    Bob,
    (posting as an individual)
    
    The assertion that SCE traffic will "starve" is just plain wrong in the following ...
    
    > > The SCE markings can be used independently whether you have multiple
    > > queues or just a single queue.
    > [BB] This seems to be the opposite of reality. Perhaps you've used the
    > word 'can' because you think it might be possible. But there's good
    > reason to doubt that. As follows...
    > 
    > Packets from non-SCE and from SCE senders are indistinguishable by just
    > looking at them. So, if there's a single queue, they have to be mixed
    > together in it {Note 1}. But a single queue can only have one length.
    > Any transports that don't understand SCE drive the single queue to a
    > deeper operating point (defined by CE or drop).
    
    The reasoning appears to be sound up to this point, but the next sentence does not follow from the above:
    
    > This overruns the SCE
    > operating point, and causes SCE marking to approach 100% {Note 2}. Then
    > those transports that do understand SCE will starve.
    
    Actually, it causes both SCE and non-SCE senders to operate at that "deeper operating point (defined by CE or drop)" because SCE traffic has an RFC-3168-like response to CE marks, and the usual reaction to drops.  The result is a deeper queue than would have resulted in the absence of non-SCE traffic, but the result is definitely *not* starvation.

[GW] Is that true?  Setting aside Bob's "Note 2" implementation, it seems your statement would only be true if the SCE sender had /no/ cwnd response to SCE-marks (i.e. ECT(1)) at all (which I guess would make it a non-SCE sender). I know the SCE congestion controller is still under development, but I seem to remember Jonathan indicating that it would aim to reduce its congestion window until the SCE-mark rate was 50% (don't quote me on that being the precise behavior currently).   If the non-SCE senders continue to drive the SCE-mark rate to 100% in order to experience occasional CE-marks, then the SCE senders would continue to reduce their congestion window on every RTT.   I suppose one way to (somewhat) get the behavior you are describing would be for an SCE sender to, upon receiving a single CE-mark, revert to an RFC3168 compliant mode and stop responding to SCE-marks.  I don’t believe that is the behavior today.

    
    Thanks, --David