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

["Scheffenegger, Richard" <[e-mail]>]

While on the surface, the AQM marking strategy (abstract from what
actual signal is used to convey this) seems to be quite similar between
DCTCP (L4S) and SCE, what I am still missing would be a detailed
mathematical model of the SCE congestion control loop.

In the draft, the reaction is described as 1/sqrt(cwnd) - per mark,
compared to 1/cwnd (*alpha) for (fluid model) dctcp; at least the dctcp
implementation I work with, currently has not implemented the fluid
model reaction of dctcp though, but rather follows the original paper
and RFC.

I don't perceive the explicit ramp function in the marking probability
at the queue as fundamentally different between these two proposals.
Others have pointed out, that stability can be improved with dctcp, if
the aqm there is not using the step-function, but also a (steep) ramp.

The differnet CC reaction however will certainly result in a higher
marking level for SCE in the steady state. OTOH, SCE absolutely requires
a secondary signal (CE or drops), since the dynamic range of the control
is not sufficient to respond to large swings of the bottleneck state
over short (~RTT) time periods (dctcp has adjustable gain - G - to
address this.

Thus my ballpark estimate is, that SCE - on average - will operate at
higher Q utilization points compared to DCTCP/L4S, that is, with higher
queueing latency.

I would love to discuss the three pieces of SCE (AQM marking strategy,
Congestion Control loop, and signaling) separate from each other first,
before we wade into certain implementation details - like how to convey
the signal back and forth.

Best regards,
    Richard


Am 18.11.2019 um 01:27 schrieb Roni Even (A):
>>
>> tsvwg Chairs,
>>
>>
>> On 14/11/2019 21:50, Rodney W. Grimes wrote:
>>> The TSVWG chairs have provided the following guidelines for this adoption
>> request:
>> [snip]
>>> (2) Coexistence of the L4S and SCE experiments is a concern that will
>>> need to be addressed by the WG if the SCE draft is adopted, and hence is in
>> scope for discussion of this adoption request ..  In particular, absence of a
>> coexistence plan (e.g., to deal with the different uses of the ECT(1)
>> codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the
>> SCE draft.
>> Could the chairs give clarity on whether Rod's statement above came from
>> the them please? And if it did, what the chairs thinking was in saying that. It
>> seems rather an odd thing for chairs of an IETF WG to say about a codepoint
>> in the IP header, when the prime role of the IETF is interoperability and
>> coexistence.
> [Roni] My reading of the text was that while LS4 was adopted by the WG the usage of ECT(1) by LS4 should not be the reason for not adopting SCE. The decision should be on the merit of the SCE. The usage of ECT(1) is a separate issue
>
>>
>>
>>
>> Bob
>>
>>
>> --
>> __________________________________________________________
>> ______
>> Bob Briscoe                               http://bobbriscoe.net/
>