Subject: [manet] DLEP reviews - new info concerning Destination Up

From: Stan Ratliff <[email-masked]>
Date: Fri, 4 Dec 2015 10:46:44 -0500

Hello WG -

There has been some discussion amongst the authors about the current use of
Destination Up. Specifically, the is concern that allowing Destination Up
to originate from the router (Multicast group creation) towards the modem
is confusing, and is likely to be mis-handled by implementers.

One possible approach is to make the Destination Up message flow *only*
from modem to router, and to introduce a new message that the router would
employ to announce router-discovered (or router-created) destinations - a
"Destination Announce" message, if you will.

The modem action on receipt of this new Destination Announce message would
be to (1) perform any proprietary setup required to flow traffic to the
dest across the RF network, and then to periodically report metrics on the
Announced destination, via 'Destination Update' messages.

Thoughts? Flames? Concerns?

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 4 Dec 2015 16:54:43 +0100

On Fri, Dec 4, 2015 at 4:46 PM, Stan Ratliff <[email-masked]> wrote:
> Destination Up. Specifically, the is concern that allowing Destination Up to
> originate from the router (Multicast group creation) towards the modem is
> confusing, and is likely to be mis-handled by implementers.
>
> One possible approach is to make the Destination Up message flow *only* from
> modem to router, and to introduce a new message that the router would employ
> to announce router-discovered (or router-created) destinations - a
> be to (1) perform any proprietary setup required to flow traffic to the dest
> across the RF network, and then to periodically report metrics on the

So "Destination up" (router to radio) could be (as an example) used
for setting up a multicast address (mac to IP combination) ?

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 4 Dec 2015 10:58:43 -0500

On Fri, Dec 4, 2015 at 10:54 AM, Henning Rogge <[email-masked]> wrote:

> from
> dest

Yes. In fact, MCAST setup is the only known use case at this point, but I'm
uncomfortable with scoping it down to just MCAST in the document. There may
well be other use-cases.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 4 Dec 2015 17:14:04 +0100

> uncomfortable with scoping it down to just MCAST in the document. There may

That reminds me that I still need to check if my implementation
returns an "ack" when the radio receives a Destination Up/Down... it
ignores it of course, but I am not sure about the ack.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 4 Dec 2015 11:22:22 -0500

> ignores it of course, but I am not sure about the ack.

... Hence, the concern that implementations might mis-handle the
Destination Up coming from the router, I guess... ;-)

Any thoughts on a new, 'Destination Announce' message?

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 4 Dec 2015 17:31:06 +0100

On Fri, Dec 4, 2015 at 5:22 PM, Stan Ratliff <[email-masked]> wrote:
> ... Hence, the concern that implementations might mis-handle the Destination
> Up coming from the router, I guess... ;-)
>

I don't really see a reason to switch away from "Destination Up"...

Henning

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 4 Dec 2015 19:20:26 +0000

On 12/4/15, 11:31 AM, "manet on behalf of Henning Rogge"
<[email-masked] on behalf of [email-masked]> wrote:

>>Destination

Yeah, neither do I.  I admit to being initially puzzled about Destination
Up coming from the router, but now I think it's fine.  I like how almost
all of the messages can be sent by either side; that symmetry allows
almost complete code sharing between the modem and the router.  If there
are different messages depending on which side they're from, that sharing
is going to be reduced.

David

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 4 Dec 2015 14:54:17 -0500

David,

> are different messages depending on which side they're from, that sharing
Thanks for the input. I just want to play "Devil's Advocate" here for a
second -
If we stay with Destination Up, the rules *could* get convoluted - for
example, what do metrics mean on a Destination Up that flows from router to
modem? Should the spec attempt to define that a router-to-modem Destination
Up should not/must not contain metrics? Or, are these metrics some sort of
recommendation (in which case, they overlap with Link Characteristics
Request on the destination)?

To be honest, I'm of the same opinion as you and Henning - I think
Destination Up, flowing from either router or modem, is a good design. But
I can see the potential for some mis-interpretation here.

Your thoughts? Other opinions? Looking for consensus here, WG participants.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Sat, 5 Dec 2015 05:35:33 +0000

Sorry for the top post, but I will summarise my side of the discussion
Stan and I have been having for a week or two.

I have 2 issues with the status-quo of router originated Destination Ups.

1) They have been in the document for several years, but until the
authors pointed them out on the list, no-one had noticed.  This does not
point to good interoperability (or a good document ;) ).

2) More importantly, a router-originated Destination Up cannot have the
same data items that a modem originated D/Up, therefore there has to be
if/else text in the spec covering the two use-cases, and at the point
one may as well have two messages.

3) The flow of destination messages gets very knotty when some messages
are unidrectional (Dest_Update) and some are bi-directional (Dest_Up). 
Carefully peeling the two use-cases apart and making them explicitly
different is clearer.

I have already prototyped the text for a new Destination Interest
message for a draft-18, and in my opinion it has the following advantages:

A) It reads better and is much clearer, and it was not a lot of extra text.
B) It answers Lou's question about how does a router re-acquire a
destination that the router has previously replied with 'Not
Interested'.  This is an example of a unicast router-originated
destination btw.
C) It helps with Chris' comments about lots of use of the words 'peer'
and 'participant', the text ends up clearer once one sets the originator
for each message explicitly.

Hopefully that swings the argument in my favour!

As an exercise for the reader: How many of you have spotted that
Destination Down can flow in both directions?

Cheers,

Rick

P.S. I am still on vacation so my email latency is high.

On 04/12/15 19:54, Stan Ratliff wrote:
> David, 
>
> On Fri, Dec 4, 2015 at 2:20 PM, Wiggins, David - 0665 - MITLL
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]> on behalf
>     of [email-masked] <mailto:[email-masked]>> wrote:
>
>     >On Fri, Dec 4, 2015 at 5:22 PM, Stan Ratliff
>     <[email-masked] <mailto:[email-masked]>>
>     >wrote:
> Thanks for the input. I just want to play "Devil's Advocate" here for
> a second - 
> example, what do metrics mean on a Destination Up that flows from
> router to modem? Should the spec attempt to define that a
> router-to-modem Destination Up should not/must not contain metrics?
> Or, are these metrics some sort of recommendation (in which case, they
> overlap with Link Characteristics Request on the destination)?
>
> Destination Up, flowing from either router or modem, is a good design.
> But I can see the potential for some mis-interpretation here. 
>

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 5 Dec 2015 08:53:37 +0000

Can't say that I specifically spotted Destination Down, but I had spotted that some information flowed "backwards". One of my comments has been that this is not brought out in the introductory material. This rather supports that.

-- 
Christopher Dearlove

> On 5 Dec 2015, at 05:35, Rick Taylor <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 7 Dec 2015 18:26:47 +0000

Responses inline...

>point to good interoperability (or a good document ;) ).

I first noticed it a few months after I started with DLEP.

>one may as well have two messages.

Allowing different data items in different directions would wipe out most
of the symmetry benefits that I see.  It would also cause some heartburn
in our implementation.  (Normally I'd just deal with that quietly, but
there's been some encouragement to discuss implementation issues, so I'll
oblige.)  In our implementation, tables define which data items are
allowed on which signals, and the tables are loaded from configuration.
This makes it easy to adapt to changes in data item/signal mappings.
However, a fairly deep assumption is that the set of data items is not
direction-dependent, because so far that's been true (I think).  We could
change that, but it's not especially easy.  A new message is definitely
easier for us to integrate.  From a pure protocol design standpoint, it's
worth considering whether this new wrinkle, direction-dependent data items
for the same message, is a good idea.  The protocol would need to specify
the allowed direction(s) for each data item on each signal/message.

While we are on the topic of Dest Up from the router, and what data items
it allows... we have been considering having the router send Dest Up to
the modem with the IP addresses/subnets of other hosts and networks that
the router can provide access to.  The modem could then propagate this
over-the-air to remote modems, which could then pass it on (via a regular
Destination Up) to their routers.  This point is to let the routers
communicate what networks they have to each other.  It seemed like this
would be allowed, since there were no stated restrictions that would
prohibit it.  If we restrict Destination Up in a way that prevents this
usage, we'll need some other way of accomplishing the same thing.

>Carefully peeling the two use-cases apart and making them explicitly

Maybe I should just wait for the new text, but I didn't encounter any
special knotty-ness in this area.

>Destination Down can flow in both directions?

Saw that the same time I realized it for Destination Up.

Thanks,

David

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 7 Dec 2015 18:52:43 +0000

David, 

One item: 

[snip]
> Allowing different data items in different directions would wipe out most of
> the symmetry benefits that I see.  It would also cause some heartburn in our
> implementation.  (Normally I'd just deal with that quietly, but there's been
> some encouragement to discuss implementation issues, so I'll
> oblige.)  In our implementation, tables define which data items are allowed
> on which signals, and the tables are loaded from configuration.
> change that, but it's not especially easy.  A new message is definitely easier
> for us to integrate.  From a pure protocol design standpoint, it's worth
> considering whether this new wrinkle, direction-dependent data items for
> the same message, is a good idea.  The protocol would need to specify the
> allowed direction(s) for each data item on each signal/message.
> 

The main issue here (for me, at least) goes back to the last email I sent on this thread - Assume that a router originates a Destination Up for a multicast group to a modem. What do the metrics on that Destination Up (if they exist) mean? Just to flesh out the example, let's say the router issues Destination Up with CDRR/CDRT set to 100Mb. However, the RF link is somewhere in the neighborhood of 32Mbit. What do you envision happening then?

At a high level, I don't have an issue with the messages and the data items being capable of flowing in both directions. But I wonder how much we have to document for the sake of interoperability. 

Regards,
Stan
 
[snip]

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 7 Dec 2015 19:14:58 +0000

David, 

My apologies for the piece-meal response. But I just got to thinking about your other point: 

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: Monday, December 07, 2015 1:27 PM
> To: Rick Taylor <[email-masked]>; Stan Ratliff
> <[email-masked]>
> Cc: MANET IETF <[email-masked]>
> Subject: Re: [manet] DLEP reviews - new info concerning Destination Up
> 
> Responses inline...
> 
> >authors pointed them out on the list, no-one had noticed.  This does
> >not point to good interoperability (or a good document ;) ).
> 
> While we are on the topic of Dest Up from the router, and what data items it
> allows... we have been considering having the router send Dest Up to the
> modem with the IP addresses/subnets of other hosts and networks that the
> router can provide access to.  The modem could then propagate this over-
> the-air to remote modems, which could then pass it on (via a regular
> Destination Up) to their routers.  This point is to let the routers communicate
> what networks they have to each other.  It seemed like this would be
> allowed, since there were no stated restrictions that would prohibit it.  If we
> restrict Destination Up in a way that prevents this usage, we'll need some
> other way of accomplishing the same thing.

How do you see this working? Specifically, what MAC address to you announce with the connected subnets? The MAC of the router? Because that's the only way I see this working. 

Regards,
Stan

> Maybe I should just wait for the new text, but I didn't encounter any special
> knotty-ness in this area.
> 
> >
> >and 'participant', the text ends up clearer once one sets the
> >originator for each message explicitly.
> >

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 7 Dec 2015 19:25:51 +0000

Hi Stan,

On 12/7/15, 2:14 PM, "Ratliff, Stanley" <[email-masked]> wrote:

>>communicate
>How do you see this working? Specifically, what MAC address to you
>announce with the connected subnets? The MAC of the router? Because
>that's the only way I see this working.

Yes, the router's MAC address.

Thanks,

David

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 7 Dec 2015 19:40:41 +0000

Hi Stan,

On 12/7/15, 1:52 PM, "Ratliff, Stanley" <[email-masked]> wrote:

>>allowed
>>easier
>The main issue here (for me, at least) goes back to the last email I sent
>on this thread - Assume that a router originates a Destination Up for a
>multicast group to a modem. What do the metrics on that Destination Up
>(if they exist) mean? Just to flesh out the example, let's say the router
>issues Destination Up with CDRR/CDRT set to 100Mb. However, the RF link
>is somewhere in the neighborhood of 32Mbit. What do you envision
>happening then?

I'm not sure.  Probably ignore it.

>
>At a high level, I don't have an issue with the messages and the data
>items being capable of flowing in both directions. But I wonder how much
>we have to document for the sake of interoperability.

It does seem that the data items coming from the router need to be made
more explicit.

David