Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09

["Black, David" <[e-mail]>]

> The feature here is that the radio can be "sure" that the router has
> done something stupid so it's easy to decide "just drop it and maybe
> log a local error".

I'm not thrilled about taking a bad situation and making it worse -  this is not quite attempting to make a "right" out of "two wrongs" but it is still not good.

In looking back on this, I may not have correctly understood how Credit Window Initialize works.   Going back to the problem scenario described in my review:

>> E.g., suppose we
>>  have a very slow modem with a 1kbyte queue and there could be 512 bytes in flight
>>  between router and modem.  If the Credit Window Status arrives with 512 bytes in
>>  flight behind it, and the modem immediately does a Credit Window Initialization to 1k,
>>  the router can then send another 1k for a total of 1.5k which overruns the 1k modem
>>  queue by 50% (oops).

This example assumes that Credit Window Initialization sets the Credit Window Max Size to 1k and applies 1k in credits.  That's not a good assumption - those are separate values in Credit Window Initialize that don't have to be the same - if only 512 bytes of credits are applied because the Max Window Size is only increasing by 512 bytes, then the 1k modem queue is not overrun.  That would be much better - it does require that "applied" mean "added" in the following text in section 2.3.1:

Credit Value:
    A 64-bit unsigned integer representing the credits, in octets, to be applied to the Credit Window. This value includes MAC headers as seen on the link between the modem and router. 

Is that change (applied -> added) reasonable?

In the reverse direction, there's "no free lunch" - if the Window size has to be dramatically decreased (e.g., radio conditions suddenly went seriously downhill), the number of outstanding credits has to be decreased, and scenarios are possible in which there's no choice but to drop traffic that was sent using credits that (in effect) no longer exist.  The suggestion for section 2.3.4 is a starting point to address this:

> I would suggest adding a sentence to the last paragraph of section 2.3.4., Credit Window Status, to clarify this re-synchronization process,
> e.g., "The modem MAY, at its discretion, after sending the Session Update Message with one or more Credit Window Initialization Data Items,
> discard any further packets matching the indicated FIDs until it receives a Session Update Response Message from the router." Thoughts?

Perhaps: "The modem MAY, at its discretion, after sending the Session Update Message with one or more Credit Window Initialization Data Items that decrease the Credit Window Max Size, discard packets that
- match the indicated FIDs, cause outstanding traffic for that FID at the modem to exceed the corresponding new Credit Window Max Size, and arrive before the modem receives a corresponding Session Update Response Message from the router.

In the last bullet, the change from "until" to "arrive before" is subtle - once that message arrives, the router will be operating with the correct credit window parameters, so it's better to drop traffic that arrived earlier (when the router may not have been operating with the correct window parameters) even if that traffic is queued in the modem and is not dropped until after that message arrives.

Thanks, --David

-----Original Message-----
From: Henning Rogge <[e-mail]> 
Sent: Wednesday, February 7, 2024 3:00 AM
To: Black, David
Cc: Don Fedyk; Velt, R. (Ronald) in 't; Lou Berger; [e-mail]; MANET IETF; Black, David
Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09


[EXTERNAL EMAIL] 

On Wed, Feb 7, 2024 at 2:45 AM Black, David
<David.Black=[e-mail]> wrote:
>
> > Hi  I did not see a reply on this thread.
> > David are you satisfied with the response?
>
> Hi Don,
>
> Sorry for the delay - I was on vacation for most of January, and am still digging out from the backlog ...
>
> David> Comments inline.
>
> In summary:
> - item [1] has been resolved via the shepherd writeup.
> - item [C] has an agreed resolution below.
> - item [2] discussion appears to have reached agreement in principle on what to do.
> - item [3] needs more thought, but appears to be headed towards resolution.
> - item [5] looks like an actual problem, as I am very surprised to see dropped traffic due to buffer overrun characterized as a "feature" of credit-based flow control - that definitely looks like a "bug" to me.

The feature here is that the radio can be "sure" that the router has
done something stupid so it's easy to decide "just drop it and maybe
log a local error".

Henning Rogge