Subject: [manet] Review of draft-ietf-manet-credit-window-00

From: John Dowdell <[email-masked]>
Date: Sat, 7 Nov 2015 10:58:12 +0000

Stan

Thanks for splitting this out as a separate draft. I believe this will set the template for other extension drafts to follow.

On the whole, it’s a good read, however I have some observations that could help an implementor, especially one that may be new to DLEP.

1. Clarification

I would like to see a little more expansion of the exchanges during the Session Initialisation exchanges for a new destination. Presumably if the modem (say) supports Credit Windowing but the router does not, the modem would issue the code for ‘Credit Windowing supported’ in the Extensions Supported data item, and the router would then respond with its Session Initialisation Response but minus that code in its Extensions Supported data item. Is it fair to say that if either end supported no extensions, then the Extensions Supported data item would not even be sent?

2. Worked example

Just to help things along, I’d like to see a worked example. If the Credit Grant is for 1000 octets, then is the value of the Credit Increment in the Credit Grant and Credit Window Status data items 1000?

3. Feature Architecture

Is it the case that Credit Windowing (I’ll call this Feature X as it’s a generic discussion) would have to be supported end-to-end, i.e. if one modem-router pair both supported Feature X then for the feature to work properly, the destination modem-router pair would also have to support Feature X? It might be worth a few words (in a section that can be populated by future extension draft authors too) to say how the feature is envisaged to work architecturally; is it a purely local modem-router feature, or should (must?) all modem-router pairs in a network implement the feature?

So what then if two modem-router pairs happily support Feature X, but a newcomer modem-router pair does not? We already know that how the modems negotiate with each other is not part of the DLEP specification, so if Feature X is required to be implemented end-to-end then the modems would have to signal to each other by ‘radio magic’ that this feature is not to be used in this session. The modem ‘radio magic’ negotiation would have to take place before the Session Initialisation/Response exchanges. This then places a mandatory dependency on the modems to negotiate for DLEP Supported Extensions before talking to their respective routers. Should that be something that is added to core DLEP?

Best regards
John

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 8 Nov 2015 20:22:34 -0500

John,

Thanks for the review! Responses inline.

On Sat, Nov 7, 2015 at 5:58 AM, John Dowdell <[email-masked]>
wrote:

> Stan
>
> Thanks for splitting this out as a separate draft. I believe this will set
> the template for other extension drafts to follow.
>
> On the whole, it’s a good read, however I have some observations that
> could help an implementor, especially one that may be new to DLEP.
>
> 1. Clarification
>
> I would like to see a little more expansion of the exchanges during the
> Session Initialisation exchanges for a new destination. Presumably if the
> modem (say) supports Credit Windowing but the router does not, the modem
> would issue the code for ‘Credit Windowing supported’ in the Extensions
> Supported data item, and the router would then respond with its Session
> Initialisation Response but minus that code in its Extensions Supported
> data item. Is it fair to say that if either end supported no extensions,
> then the Extensions Supported data item would not even be sent?
>

Going on your example where the modem supports the extension, but the
router does not - The Peer Init from the router would *not* contain an
entry for it in the "Extensions Supported" data item (Section 10.6 of the
base DLEP draft). Therefore, it would be an error for the mode to use *any*
of the credit windowing extension data items.

>
> 2. Worked example
>
> Just to help things along, I’d like to see a worked example. If the Credit
> Grant is for 1000 octets, then is the value of the Credit Increment in the
> Credit Grant and Credit Window Status data items 1000?
>

I'll try. In your example, the value of the Credit Grant would be 1000, the
value of the Credit Window Status would be the absolute value of the window
(e.g. whatever the 'old' credit count was, plus the new grant of 1000).

>
> 3. Feature Architecture
>
> Is it the case that Credit Windowing (I’ll call this Feature X as it’s a
> generic discussion) would have to be supported end-to-end, i.e. if one
> modem-router pair both supported Feature X then for the feature to work
> properly, the destination modem-router pair would also have to support
> Feature X? It might be worth a few words (in a section that can be
> populated by future extension draft authors too) to say how the feature is
> envisaged to work architecturally; is it a purely local modem-router
> feature, or should (must?) all modem-router pairs in a network implement
> the feature?
>
> So what then if two modem-router pairs happily support Feature X, but a
> newcomer modem-router pair does not? We already know that how the modems
> negotiate with each other is not part of the DLEP specification, so if
> Feature X is required to be implemented end-to-end then the modems would
> have to signal to each other by ‘radio magic’ that this feature is not to
> be used in this session. The modem ‘radio magic’ negotiation would have to
> take place before the Session Initialisation/Response exchanges. This then
> places a mandatory dependency on the modems to negotiate for DLEP Supported
> Extensions before talking to their respective routers. Should that be
> something that is added to core DLEP?
>

Actually, there's nothing about credit-windowing that forces it to be used
by all router-modem pairs as you've outlined - theoretically, I could
deploy one router/modem pair that uses the extension, and another that
doesn't. The windowing isn't 'end-to-end'. Rather, it's just 'local
router-to-local modem' and 'local modem-to-local router'.

Regards,
Stan

>
> Best regards
> John
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>