[sbm] Re: Draft-cheshire-sbm-02 submitted

[Sebastian Moeller <[e-mail]>]

> On 20. Mar 2025, at 13:26, Michael Welzl <[e-mail]> wrote:
> 
> Hi Stuart!
> 
> Thanks for referencing the Transport Services API (RFC 9622) now; however, I would say that the paragraph that you added in section 6 to refer to it mis-represents this mechanism. The quote about the “Sent events” is correct, but the consequences of this knowledge are much richer than the paragraph indicates: this does give applications complete control over the amount of buffering they create.
> 
> As written in Section 6, TCP_REPLENISH_TIME has the transport protocol “compute its best estimate of when the expected time-to-exhaustion falls below this threshold” (and the application would be notified when falling below the threshold).
> 
> Instead, the Sent events in a Transport Services System, as defined in RFC 9622, hand such decisions (estimation) entirely to the application. E.g., if an application wants to ensure that there will never be more than one message in the queue below, it can issue a send call and only issue the next such call when “Sent” has fired.  X messages? Just increase a counter up to X whenever sending, stopping to transmission when reaching X; decrease that counter when “Sent” has fired.  X bytes?  Same logic with bytes. Time? The application needs to compute an estimate. You get the idea.

Mmmh, TCP_REPLENISH_TIME would work better with variable rate link where the lower layers will be in a better position to estimate current buffer state in units of time required to service it, no? Put differently, an application easily can be in control of the amount of data it queues itself, it will be oblivious to data queued by other applications even on a fixed rate system (so little's law will only go so far to estimate queue servicing time, as the application does not know its share of the fixed capacity), let alone on a variable rate system.
Linux wireless ran into a similar issue (viewed from very high above), resulting in the airtime queuing limits approach to close this gap between the wireless fq_codel instance and the actual WiFi driver maintining its own queues and having information about air time access.


> This is slightly heavier for the application in that it processes more events than in the TCP_REPLENISH_TIME model, and if estimating time is the goal, it may also have the downside that less of the relevant data is available to the application.

Yes... that seems to be potentially a big difference...

> On the plus side, it's simpler for the system below. Anyway, both approaches give the application full control - they are just different ways of doing this.
> 
> Cheers,
> Michael
> 
> 
> 
>> On 16 Mar 2025, at 08:35, Stuart Cheshire <cheshire=[e-mail]> wrote:
>> 
>> Thanks all for the comments on draft-cheshire-sbm-01. I updated the draft and submitted draft-cheshire-sbm-02 today.
>> 
>> Stuart Cheshire
>> 
>> _______________________________________________
>> sbm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> sbm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]