Re: [manet] Last call ending

["Wiggins, David - 0665 - MITLL" <[e-mail]>]

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

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

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

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

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

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

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.

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

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.

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.

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

Thanks,
David