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

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

Hi Eric,

Thanks for jumping in ...

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

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

If that's the desired effect, then "MAY, at its discretion" is entirely too weak. The new text needs to begin with
"The modem SHOULD ..." and would benefit from a little rearrangement, e.g.:

   After sending the Session Update Message with one or more Credit Window Initialization Data Items that decrease
   the Credit Window Max Size, the modem SHOULD continue processing received packets that match the indicated FIDs,
   fit within the window for the unmodified Credit Window Max Size and arrive before the modem receives the corresponding
   Session Update Response Message. 

The rest of the text assumes that the window size won't decrease to or below the new max size before the response
message arrives.  While that's certainly the likely behavior, it won't always be the case.  So instead of:

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

I'd suggest:

   The modem SHOULD NOT issue additional credits for each affected FID until the associated affected
   Window has drained to be less than the new Credit Window Max Size, regardless of whether sufficient
   draining occurs before or after the modem receives that corresponding Session Update Response Message.

I think that one sentence covers both cases and using "SHOULD NOT" makes the point clearer.


Thanks, --David

-----Original Message-----
From: Eric Kinzie <[e-mail]> 
Sent: Friday, February 23, 2024 4:06 PM
To: Black, David <[e-mail]>
Cc: Henning Rogge <[e-mail]>; Black, David <David.Black=[e-mail]>; Don Fedyk <[e-mail]>; Velt, R. (Ronald) in 't <Ronald.intVelt=[e-mail]>; Lou Berger <[e-mail]>; [e-mail]; MANET IETF <[e-mail]>
Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09


[EXTERNAL EMAIL] 

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