Re: [manet] Last call ending

[Lou Berger <[e-mail]>]

On January 26, 2018 3:41:30 PM "Wiggins, David - 0665 - MITLL" 
<[e-mail]> wrote:

> Comments inline… sorry if outlook mangles stuff
>
> On 1/25/18, 7:33 PM, "Lou Berger" <[e-mail]> wrote:
> On 1/25/2018 10:07 AM, Wiggins, David - 0665 - MITLL wrote:
>     >
>     > I think the latency extension is in reasonable shape.  I agree with
>     > all of Vicky’s recent comments.
>     >
>     > Here are some comments on the Multi-Hop extension.
>     >
>     > Section 3.1
>     >
>     > “…each hop represents a transmission and the number of hops is
>     > equal to the number of transmissions required to go from a router
>     > connected modem to the destination's connected modem.”
>     > So hops are counted starting at the modem that is the DLEP peer of the
>     > router.
>     >
>     yes, that's the intent.
>
>     > But then:
>     >
>     > “The minimum number of hops is 1, which represents the router's
>     > locally connected modem.”
>     >
>     how about "which represents the *transmission* by the router's locally
>     connected modem."?
>
> I like this better: “which represents transmission to destinations that are 
> directly reachable from the router’s locally connected modem.”
>

How about s/from/via ?

>     > If counting starts at that modem, wouldn’t hop count be 0 for the modem?
>     >
>     I don't understand this.  Perhaps you mean for the hop between the
>     router and the modem?  This extensions isn't intended to count router to
>     modem hops.
>
> No, I mean the modem.  If the hop count from the modem to one of its 
> directly reachable destinations is 1, and assuming each hop increments the 
> count by 1, then the modem’s hop count has to be zero for that math to work 
> (  Now, we may expect a hop count of zero to never be reported, but that is 
> a separate issue; more below.
>

Right- I think we agree that this is a non issue/case.

>     >   If it’s 1, this seems to mean that the (typically) wired link
>     > between the router and the modem is being counted.
>     >
>     How so?  1 means a single transmission over the modem attached media
>     (RF) channel .
>
> It doesn’t matter now… I was just trying to reason through what it would 
> mean if the modem’s hop count was 1, because it was ambiguous before.  Now 
> it’s not.
>

Okay.

>     > I think the two quotes above are inconsistent about whether this first
>     > link counts as a hop. If the hop count was meant to convey
>     > over-the-air hops, then the router’s locally connected modem should
>     > have a hop count of 0.
>     >
>     There is no destination for the locally connected modem, so zero would
>     never be reported.  In what case do you see zero being reported?
>
> I’ve been assuming that the locally connected modem could indeed announce a 
> destination for itself, though admittedly this seems unusual.  However, I’m 
> probably wrong; in 8175 section 2.1:
>
> “Destinations can be identified by either the router or the modem and 
> represent a specific, addressable location that can be reached via the 
> link(s) managed by the modem.”
>
> Unless we imagine an implied link from the modem to itself, which seems 
> like a stretch, this means that the destinations are on the other end of a 
> link from the modem.  So I accept that the modem itself won’t be a 
> destination, and thus there won’t ever be a zero hop count.
>

Great.

>     > “A value of zero (0) is used to indicated that processing of a Hop
>     > Control action, see Section 3.2, has resulted in a destination no
>     > longer being reachable.”
>     >
>     > I would rather not have this special case. Just leave it to
>     > Destination Down to convey loss of reachability.  I’ve worked on
>     > systems that had multiple different ways of indicating a node was
>     > down, and it leads to bugs, especially when the down indications are
>     > not closely synchronized.  Part of the system thinks a node is up,
>     > part thinks it’s down, and chaos ensues.
>     >
>     I'd actually expect both a Destination Down, per normal processing which
>     is not modified by this document, and a  Link Characteristics Request
>     Message.  This is so there is consistent processing of  the Hop Control
>     Data Item on both router and modem.  Otherwise there how will a router
>     know that a particular Hop Control request has completed.  Having just a
>     Destination Down would mean that the router would have to infer that
>     this was due to the hop control when in fact it may be due to just some
>     transitory affect.  In my experience leaving things to inference is a
>     bad transaction model and leads to race condition bugs. So I'd prefer to
>     leave as is. I've added a note to make it clear that the Destination
>     Down is still sent. specifically:
>        Note that
>        normal DLEP processing is not otherwise modified by this document, this
>        includes the generation of Destination Down messages.
>
> The router would know that the Hop Control request has completed when it 
> receives a Link Characteristics Response.  The status code would be used to 
> indicate whether it succeeded or not.  If it did succeed, a Destination 
> Down would come along soon after (if the action was Terminate).  This is 
> almost what you have now, except I’m suggesting to use the status code data 
> item rather than the hop count data item to indicate success.
>

Hmm. A successful transaction does not necessarily Translate to a loss of 
connection, so I think being explicit here makes the most sense. We should 
certainly ensure that the text is clear either way.

>     > Section 3.2 paragraph 5
>     >
>     > I think a Session Update message should be replied to with a Session
>     > Update Response, and a Link Characteristics Request message with a
>     > Link Characteristics Response.  The text has both of these being
>     > replied to with a Link Characteristics Request message.
>     >
>     What information would you like carried in the Session Update Response
>     message?  Note that a reset may result in a destination specific change.
>
> A Hop Control Reset sent in a Session Update would be answered with a 
> Session Update Response with an appropriate status code, followed by 
> Destination Updates with appropriate Hop Count data items for any that changed.
>
This works for me and seems sensible. I thought you were suggesting 
something different. I'll propose some text to this effect.

> Please, please don’t make a Session Update message be replied to with a 
> Link Characteristics Request message.  That contorts my implementation in 
> unnatural ways.
>

Understood.

>     > Sections 3.2.2 Terminate and 3.2.3 Direct Connection
>     >
>     > These seem to be a way for the router to tell the modem how important
>     > it is to be able to communicate with specific destinations.
>     >
>     I see this as the way to reverse/undo a 'Direct Connection'.
>
> I’m talking about both Terminate and Direct Connection.
>
>     >
>     > If that was the motivation, perhaps a more direct expression of that
>     > information would be better.  For example, the router could provide a
>     > list of destinations, ordered by importance.  I worry that the router
>     > giving low-level directions to the modem about which links to maintain
>     > might be difficult or suboptimal for some radios.
>     >
>     How about:
>     OLD
>         It indicates
>          that the modem SHOULD attempt to terminate communication
>          with the destination identified in the message.
>     NEW
>         It indicates that a direct connection is no longer needed with the
>         the destination identified in the message.
>
> My concern is deeper than this.  The modem may be running a sophisticated 
> topology control algorithm to decide which neighbors to maintain links to.  
> It may be juggling multiple beams, multiple frequencies, considering the 
> local network density and traffic load, factoring in connectivity goals 
> (e.g., biconnectedness), etc.  Having an external party (router) insert its 
> own wishes for links into the mix could be untenable.  The probability is 
> good that the router’s wishes will contradict the modem’s topology choices.
>
Well certainly this extension is about a router in forming a modem about 
its wishes/preferenes.


> Also, there seems to be an unstated assumption that a direct connection (1 
> hop) to a destination is better in some sense that a non-direct connection. 
>  Why else would the router ask for a direct connection?  Two short hops are 
> often more reliable than one long hop, though.  Forcing a single hop could 
> make communication worse.  Giving the router this control is too low-level; 
> it doesn’t have enough information to do it right.
>

I think the router has access to sufficient information through other 
metrics. Certainly A system that doesn't care to provide this capability to 
a router doesn't have to implement it.

> That’s why I was suggesting a radically different mechanism for the router 
> to express its wishes, e.g., by ordering the destinations in terms of 
> importance, and letting the modem work that information into its topology 
> control scheme however it can.  The router’s most important destination may 
> be best reached over a 3-hop link.
>

To me this is a different extension with different objectives. I certainly 
would be interested in reading that extension.

>     >
>     > Section 3.2.4 Suppress Forwarding
>     >
>     > What exactly is meant by suppressing multi-hop forwarding here?  Is it:
>
> Borrowing text from a different message in this thread, Lou said:
>
>     The basic use case is to have all forwarding done by the routers. This
>     would only be useful in networks where routers are attached to all
>     radios.  So this is a user deployment choice...
>
> Ah, I see.  This clarifies the intent significantly.  This motivation 
> should be stated in the draft.  I’ve definitely heard the desire to turn 
> off all of the radio’s routing and use it as a single-hop device.
>

I'll look at providing some text on this in the intro.

Thanks,

Lou

> Thanks,
> David
>