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

[Eric Kinzie <[e-mail]>]

I hope you don't mind me jumping into the middle of this.  Lou Berger
pointed out this draft to me.  I have one comment about this, below.

On Wed Feb 07 23:22:39 +0000 2024, Black, David wrote:
> > 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.

I think it should be possible to have a "graceful" reduction in the
Credit Window with somthing along the lines of:

"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, continue processing received packets
that match the indicated FIDs with an unmodified Credit Window Max Size
that arrive before the modem receives the corresponding Session Update
Response Message.  However, during this time no additional credits for
those FIDs are issued.  After the router's Session Update Response Message
is received, the modem waits for each affected window to drain until it
reaches the new Credit Window Max Size.  At this point the modem resumes
issuing credits for that FID, limited by the new Credit Window Max Size."

Misbehaving routers that send packets in the absence of credits will
still result in those packets being dropped.  But, otherwise, we avoid
dropping packets at the receiver simply as a side effect of the change.

Eric