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

[Michael Welzl <[e-mail]>]

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.

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