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

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

Lou,

I think we're close to done.  There are a few more things that need attention:

i) The security considerations text was only updated in the flow-control draft.  The other 3 drafts need corresponding security considerations text updates.

ii) A diff of da-credit-extension-15 against -12 reveals a couple of updates at the end of section 3 (Management Considerations) that need to be applied to ether-credit-extension-03 .

iii) New text in section 2.3.2 of the flow control draft: "TIDs in different Credit windows must not overlap."
That text solves the problem that it was intended to address, but raises a couple of secondary concerns:
	- Which entity checks for overlaps?  I think it’s the modem.
	- What happens if overlaps are found?  I think it a suitable "you got it wrong" DLEP error goes back to the router and either the overlapping TIDs or all TIDs in the message (which one?) are not used.
   A sentence or two should be added to explain.

Finally, in looking back on all the emails, I want to record here that item [H] on amount of imprecision (e.g., what does "significantly different" mean?) was not pursued in revising the drafts as your email characterized that as implementation dependent.  That seems ok to me, as this is a modem implementation decision on how aggressive the modem chooses to be in protecting its resources.

Thanks, --David

-----Original Message-----
From: Lou Berger <[e-mail]> 
Sent: Friday, March 8, 2024 9:01 AM
To: Black, David <[e-mail]>
Cc: MANET IETF <[e-mail]>; [e-mail]; Velt, R. (Ronald) in 't <Ronald.intVelt=[e-mail]>; Eric Kinzie <[e-mail]>
Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09


[EXTERNAL EMAIL] 

David,

Can you take a look at the latest update and let us know if there remains any open issues?

Thank you!

Lou

On 3/3/2024 11:53 PM, Lou Berger wrote:
> Thank you all for the discussion and changes.  I'll be refreshing the 
> drafts, including with related changes.
>
> Lou
>
> On 2/28/2024 6:00 AM, Eric Kinzie wrote:
>> On Tue Feb 27 22:07:00 +0000 2024, Black, David wrote:
>>> Great, in addition to the two sentences below, the following change in section 2.3.1 is also desired to close out this topic:
>>>
>>>> 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.
>>> "to be applied to" -> "to be added to"
>>>
>>> Thanks, --David
>> I agree; this change makes sense.
>>
>> Eric
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Eric Kinzie <[e-mail]>
>>> Sent: Tuesday, February 27, 2024 1:11 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]
>>>
>>> On Tue Feb 27 00:30:28 +0000 2024, Black, David wrote:
>>>> 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.
>>> Yes, the stronger wording seems appropriate here.
>>>
>>>> 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.
>>> I agree with your wording here, also.
>>>
>>> Thanks,
>>>
>>> Eric
> _______________________________________________
> manet mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mane
> t__;!!LpKI!ndvpYtyjsOdQCv-3vIWkyCNPKBEuU10XKuoiYq-k6f7rZPSqwbCQRneZgcc
> SnDqXSBc3IhgxRwVMm_7Q$ [ietf[.]org]