Subject: [manet] DLEP-18 Destination Announce

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 8 Feb 2016 20:55:29 +0000

Here are some comments on the new Destination Announce/Response messages in DLEP-18.

1.  What are the IPv4/IPv6 data items for?  If the MAC address is a multicast address, are these supposed to be the IP multicast equivalents?

2.  Other than canceling a previous status of Not Interested  in a destination (from 3.1.  Router-requested Destinations), is there any other case where the router would use a unicast MAC address in a Destination Announce?

3.  How does the router cancel (undo) a Destination Announce?  Section 10.18 hints that it is Destination Down, but I still have some uncertainty because of the wording.

4.  In section C.2, the router is shown as using Destination Up with a multicast group.  I think this should now be using Destination Announce.

5.  I have been assuming that when the router announces interest in a multicast group, this effectively causes a multicast join and results in data plane traffic for that group to start flowing to the requesting router.  This is never stated, though, and it's an important side-effect that should be called out.

David

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Mon, 8 Feb 2016 21:20:40 +0000

David, 

Answers from the perspective of someone who does *not* like Destination Announce... ;-) 

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Wiggins, David -
> 0665 - MITLL
> Sent: Monday, February 08, 2016 3:55 PM
> To: [email-masked]; Stan Ratliff <[email-masked]>
> Subject: [manet] DLEP-18 Destination Announce
> 
> 1.  What are the IPv4/IPv6 data items for?  If the MAC address is a multicast
> address, are these supposed to be the IP multicast equivalents?

Yes. But while I don't have a specific use-case in mind, I believe the use of "router-discovered destinations" MAY well extend beyond MCAST.

> 
> 2.  Other than canceling a previous status of Not Interested  in a destination
> (from 3.1.  Router-requested Destinations), is there any other case where
> the router would use a unicast MAC address in a Destination Announce?

Not currently. But see above - I think a use case may develop. 

> 
> 3.  How does the router cancel (undo) a Destination Announce?  Section
> 10.18 hints that it is Destination Down, but I still have some uncertainty
> because of the wording.
>

Yes, a Destination Announce is just a router-initiated "Destination Up". After a destination is available (either via Announce or Up), it can be brought down by either partner. 

> 4.  In section C.2, the router is shown as using Destination Up with a multicast
> group.  I think this should now be using Destination Announce.
> 

Thanks! We'll put that on the list. 

> 5.  I have been assuming that when the router announces interest in a
> multicast group, this effectively causes a multicast join and results in data
> plane traffic for that group to start flowing to the requesting router.  This is
> never stated, though, and it's an important side-effect that should be called
> out.

The scheme so far with DLEP is to document (for interoperability) what crosses the wire, but *not* to document "what you'd do with this data". I'm not a multicast expert; I'd rather not get into trying to document what someone would do with this message (either on the modem or the router side). For example, I'd *assume* that a receiving modem would perform tasks (not necessarily in sequence) like: 
- Modify its MAC listening table to include the MAC address in Destination Announce (both on the RF and the LAN side)
- Do any other allocation (buffers, queues) needed to flow the traffic, 
- Determine a set of metrics for the Announced destination (in the MCAST case, does it flow at full data rate? A lesser rate, like 802.11 would? Are there different latencies for MCAST? stuff like that). 

But having said that, I'd *hate* to get into trying to list all of that - I think we'd be spinning on DLEP for an eternity (plus 2 weeks).

Regards,
Stan

_____________________________________________________
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: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 9 Feb 2016 18:11:49 +0000

> > 10.18 hints that it is Destination Down, but I still have some
> > uncertainty because of the wording.
> 
> Yes, a Destination Announce is just a router-initiated "Destination Up". After a
> destination is available (either via Announce or Up), it can be brought down by
> either partner.

I didn't realize that (either side can Down a destination) until it was noted in the latest draft.

I'm not sure how to handle the case where a modem declares a destination (let's say unicast) up and the router then says no, it's down.  In most of the implementations I can imagine, the modem is going to know which destinations are up and which are down.  So when the router says one of them is down, this may directly contradict the modem's reality.  What's the modem supposed to do?  Forcibly take the destination down (may not be possible)?  Remember that the router said it's down, and don't send that router any more information about that destination until the router later declares it up again, kind of like a "not interested" status?  Similar questions can be raised about a router declaring a multicast destination up, and the modem then declaring it down.  The router knows which multicast groups it's interested in; the modem shouldn't presume to know better.

I'd prefer it if the peer that declares a destination up is the only one that can declare it down.  It's a simpler mental model that avoids the questions above (and probably others).  We have the "not interested" status that lets a peer block information about a destination if so desired; is more than that really needed?

> > multicast group, this effectively causes a multicast join and results
> > in data plane traffic for that group to start flowing to the
> > requesting router.  This is never stated, though, and it's an
> > important side-effect that should be called out.
> 
> The scheme so far with DLEP is to document (for interoperability) what crosses
> the wire, but *not* to document "what you'd do with this data". I'm not a
> multicast expert; I'd rather not get into trying to document what someone
> would do with this message (either on the modem or the router side). For
> example, I'd *assume* that a receiving modem would perform tasks (not
> necessarily in sequence) like:
> - Modify its MAC listening table to include the MAC address in Destination
> Announce (both on the RF and the LAN side)
> - Determine a set of metrics for the Announced destination (in the MCAST case,
> does it flow at full data rate? A lesser rate, like 802.11 would? Are there
> different latencies for MCAST? stuff like that).
> 
> But having said that, I'd *hate* to get into trying to list all of that - I think we'd
> be spinning on DLEP for an eternity (plus 2 weeks).

Agreed; it shouldn't go into that level of detail.  Maybe just add one sentence like:
"When a router sends a Destination Announce with a multicast destination, the modem should interpret this as the  router's wish to receive traffic for that multicast group."  At least then the intent is clear, and an implementer will probably know what to do.

David

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 9 Feb 2016 13:30:33 -0500

On Tue, Feb 9, 2016 at 1:11 PM, Wiggins, David - 0665 - MITLL <
[email-masked]> wrote:

> I'm not sure how to handle the case where a modem declares a destination
> (let's say unicast) up and the router then says no, it's down.  In most of
> the implementations I can imagine, the modem is going to know which
> destinations are up and which are down.  So when the router says one of
> them is down, this may directly contradict the modem's reality.  What's the
> modem supposed to do?  Forcibly take the destination down (may not be
> possible)?  Remember that the router said it's down, and don't send that
> router any more information about that destination until the router later
> declares it up again, kind of like a "not interested" status?  Similar
> questions can be raised about a router declaring a multicast destination
> up, and the modem then declaring it down.  The router knows which multicast
> groups it's interested in; the modem shouldn't presume to know better.
>

It wasn't intended to contradict reality - just update the state of "DLEP
Reality". The Destination Down is more of a way to say "I don't want to
hear anymore DLEP info on this destination", or "I'm not going to send
anymore DLEP information on this destination". There's no reason that data
traffic can't continue to flow.

>
> I'd prefer it if the peer that declares a destination up is the only one
> that can declare it down.  It's a simpler mental model that avoids the
> questions above (and probably others).  We have the "not interested" status
> that lets a peer block information about a destination if so desired; is
> more than that really needed?
>

It's more state information that has to be carried; more of an opportunity
for things to go wrong. In the case where one of the session partners
(either router or modem) doesn't want DLEP info for a given destination,
sending "Destination Down" is as good a way as any other to say "Stop it".
The "Not Interested" status was a way to "NACK" a Dest Up - but when a
router initially *is* interested, and then ceases to be?

And on the modem side - as an example, I believe some satellites use
different transponders/beams for multicast vs. unicast. Therefore, it's
possible that multicast could stop, while unicast transmission is still
enabled (an operator shut the MCAST transponder down for maintenance, for
example). So, what's a poor modem to do, especially in the case where he's
already responded to "Destination Announce" for one or more MCAST groups?
The model you propose, by necessity, now requires one end to be able to
"ask" the other for a Destination Down...

> "When a router sends a Destination Announce with a multicast destination,
> the modem should interpret this as the  router's wish to receive traffic
> for that multicast group."  At least then the intent is clear, and an
> implementer will probably know what to do.
>

I'll see what I can work into the text.

Regards,
Stan

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 9 Feb 2016 22:30:21 +0000

(apologies for the funky attributions; outlook made a mess and I cleaned it up by hand)

Stan wrote:
It wasn't intended to contradict reality - just update the state of "DLEP Reality". The Destination Down is more of a way to say "I don't want to hear anymore DLEP info on this destination", or "I'm not going to send anymore DLEP information on this destination". There's no reason that data traffic can't continue to flow. 

David:
How about using Destination Update with status=Not Interested to say " I don't want to hear anymore DLEP info on this destination"?   Having just one way to express this seems better than having two (Not Interested and Destination Down).

For the  "I'm not going to send any more DLEP information on this destination" case, if a modem declares a destination up, then down, and data traffic continues to flow to the router for that destination for a significant amount of time afterward, that seems wrong to me.  I guess if you take the view that DLEP messages are only meaningful inside DLEP, and have no effect on the world outside of DLEP, then it works.  A DLEP island that doesn't affect anything outside itself, or affects the outside world in undefined ways, doesn't seem very useful, though.  I understand that we don't want to get into the business of specifying in great detail what the effects are, but staying silent on these interactions means different implementers are going to assume different things.  I hope there is a middle ground.

Stan wrote:
And on the modem side - as an example, I believe some satellites use different transponders/beams for multicast vs. unicast. Therefore, it's possible that multicast could stop, while unicast transmission is still enabled (an operator shut the MCAST transponder down for maintenance, for example). So, what's a poor modem to do, especially in the case where he's already responded to "Destination Announce" for one or more MCAST groups? The model you propose, by necessity, now requires one end to be able to "ask" the other for a Destination Down... 
 
David:
The modem would just continue to do its best to deliver the requested traffic to the router.  Sometimes it would not be able to.  I wouldn't have expected any DLEP messages would be needed in either direction for a traffic interruption.  If this is expected, it needs to be specified.

Thanks,

David

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 9 Feb 2016 18:34:20 -0500

David,

Sorry about that. I guess I need to stop using Outlook for IETF mails...

On Tue, Feb 9, 2016 at 5:30 PM, Wiggins, David - 0665 - MITLL <
[email-masked]> wrote:

> How about using Destination Update with status=Not Interested to say " I
> don't want to hear anymore DLEP info on this destination"?   Having just
> one way to express this seems better than having two (Not Interested and
> Destination Down).
>

We absolutely *could* do Destination Update, but I don't think we "should*.
In fact, we could've (and perhaps it would have been better) to just NACK
the Destination Up instead of providing the "Not Interested" status. To be
honest, I don't really look at this as having two ways to do something -
the Dest Up needs to be either ACKed or NACKed. Once a DLEP pair
understands that a destination is out there, and metrics are presented and
processed for it, there has to be a way, for *either* one of the pair, to
say "Stop" for some reason. At least for me, this discussion starts to be a
circular one, because when asked "What would I do with one of these 'Not
Interested' status code on a Destination Update?", my response would be
"process it just like you got a Destination Down"...

>
> For the  "I'm not going to send any more DLEP information on this
> destination" case, if a modem declares a destination up, then down, and
> data traffic continues to flow to the router for that destination for a
> significant amount of time afterward, that seems wrong to me.  I guess if
> you take the view that DLEP messages are only meaningful inside DLEP, and
> have no effect on the world outside of DLEP, then it works.  A DLEP island
> that doesn't affect anything outside itself, or affects the outside world
> in undefined ways, doesn't seem very useful, though.  I understand that we
> don't want to get into the business of specifying in great detail what the
> effects are, but staying silent on these interactions means different
> implementers are going to assume different things.  I hope there is a
> middle ground.
>

I have communicated poorly. Let me take another stab at it:   Presentation
of a Destination Down effective says that the sender is no longer capable
of understanding the state (whether the far end is a member of the RF
network or not) of the Destination, and/or is no longer capable of
producing or processing metrics for the destination. Does that have impact
on the data traffic? I sure hope so.

But as to "staying silent on these interactions" - I believe that
documenting said impact is well outside the scope of DLEP. I have no idea
how to wrap my head around how we'd even begin to do that, and I suspect it
would take, at a minimum, another 6 years. From my perspective, it
approaches a boiling of the ocean, which I didn't sign on to document, nor
do I think this WG should try to document; not to mention that (IMO still)
it stifles innovation with the protocol. We can document the protocol such
that the DLEP machinery is consistent & interoperable; but I think the
broader implications are beyond this one working group.

> The modem would just continue to do its best to deliver the requested
> traffic to the router.  Sometimes it would not be able to.  I wouldn't have
> expected any DLEP messages would be needed in either direction for a
> traffic interruption.  If this is expected, it needs to be specified.
>

But in the case I presented, MCAST traffic would *not* be deliverable for
an indeterminate amount of time (until the operations staff re-enables the
transponder). I don't see how leaving the Destination 'Up' in this case
helps anything.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Wed, 10 Feb 2016 15:46:15 +0000

Sorry to fork the thread, but here are some answers from someone who 
does like Destination Announce.

First, thank you David for picking up on Destination Announce, as I 
think it is an important change in this draft.

Some background:  I pushed for Destination Announce after I began to 
believe that many readers of earlier drafts of DLEP were unaware that 
Destination Up and Down messages could flow in *both* directions. That 
is from routers to modems as well as the more common modem to router. 
In an attempt to clarify, I put in the Destination Announce messages to 
replace router-initiated Destination Up messages.  Originally they were 
called Destination Interest messages, as they are supposed to indicate 
that a router is interested in a currently unavailable destination, and 
would like the modem to talk about it.

Comments inline...

> 1.  What are the IPv4/IPv6 data items for?  If the MAC address is a multicast address, are these supposed to be the IP multicast equivalents?

They are there because Destination Announce is inherited from 
Destination Up, and I see no reason to remove them.  As Stan said, there 
may be future use-cases where they are useful.

> 2.  Other than canceling a previous status of Not Interested  in a destination (from 3.1.  Router-requested Destinations), is there any other case where the router would use a unicast MAC address i…

As Stan said before: one day there might be, and I can see no reason to 
prevent unicast MAC addresses being used. One potential option for 
'on-demand' unicast destinations is perhaps triggering some proactive 
layer-2 routing protocol in the modem, to go find a viable path to the 
destination across some meshing radio net?

> 3.  How does the router cancel (undo) a Destination Announce?  Section 10.18 hints that it is Destination Down, but I still have some uncertainty because of the wording.

The wording may well need another pass.

What I was trying to say was that although Destination Up is no longer 
bidirectional, Destination Down may be sent by either peer at any time. 
  From a modem's perspective, when a Destination 'goes away' it MUST 
inform the router via Destination Down, whether the destination was 
Announced, or Upped.  From a router's perspective, if it no longer wants 
updates concerning a destination, it may send a Destination Down, as a 
kind of 'unsubscribe' message.

If the WG think it would be better to only allow Destination Downs to 
flow from modem to router, and to add a new 'Destination Unsubscribe' 
message to flow from router to modem instead, now is the time to say!

> 4.  In section C.2, the router is shown as using Destination Up with a multicast group.  I think this should now be using Destination Announce.

Yes, I missed that. (I hate editing the appendices).

> 5.  I have been assuming that when the router announces interest in a multicast group, this effectively causes a multicast join and results in data plane traffic for that group to start flowing to…

My use-case was that the router has detected that a local host has 
attempted to join a multicast group, through some out of scope method. 
It would then send a Destination Announce message to the modem, 
requesting information about the multicast destination.  If the modem 
can promptly report information about the multicast destination, then it 
response with a positive Destination Announce Response, and the router 
can do whatever it needs to do to with the multicast traffic. If the 
modem cannot deliver traffic to the multicast destination, then it must 
respond with a negative status code, and again, the router can react 
appropriately.

The critical point in my mind is that it is out of scope for DLEP to 
define what a Destination Announce message causes the modem to do, it 
just describes how a modem should respond, much like Link 
Characteristics Request.

Cheers,

Rick

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Wed, 10 Feb 2016 20:58:39 +0000

Hi Rick,

Comments below...

>is from routers to modems as well as the more common modem to router.

I think I was aware that these could go in both directions, but I had been
assuming that whichever side  does the Up for a particular destination is
the only side allowed to do the Down for that destination. I'm still not
clear on all of the ramifications of allowing either side to do the Down
for any destination.

>> 1.  What are the IPv4/IPv6 data items for?  If the MAC address is a
>>multicast address, are these supposed to be the IP multicast equivalents?
>

Do you agree with "If the MAC address is a multicast address, are these
supposed to be the IP multicast equivalents?"

If we leave in data items but don't define what they're to be used for,
what does that do to future interoperability?

>>2.  Other than canceling a previous status of Not Interested  in a
>>destination (from 3.1.  Router-requested Destinations), is there any
>>other case where the router would use a unicast MAC address in a
>>Destination Announce?
>

OK, I can see that.  So for now, when a modem receives a destination
announce with a unicast address, the modem should:
1. check to see if the destination is one that it has previously declared
Up.  If so, send a Destination Up for that destination to the router
(actually not sure about that) and resume sending future Destination
Updates for that destination to the router.
2. otherwise, ignore the Destination Announce.

However, a future enhancement may replace step 2:
2. Start actively probing the network for the given destination.

If a router wants this enhanced behavior, how does it know that the modem
supports it?  Is it going to be advertised by an extension?

>message to flow from router to modem instead, now is the time to say!

I could go either way, but if we call this Unsubscribe then I'd prefer to
rename Announce to Subscribe.

>just describes how a modem should respond, much like Link

If "how the modem should respond" includes the equivalent of "give the
router traffic for this multicast group" (for a multicast destination)
then I agree.

David

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 11 Feb 2016 14:25:37 -0500

David,

Some comments inline.

> supposed to be the IP multicast equivalents?"

Yes, I agree with this. However, I don't see a need to explicitly state it
in the draft. A developer of a DLEP implementation is free to check the
consistency of the received data. If the MAC address doesn't "match" the
supplied IP address (or addresses), then issue Announce Response with
non-zero Status.

> 2. otherwise, ignore the Destination Announce.

Why would you ignore the Destination Announce in this case? Why not send
Destination Announce Response with a non-zero status code, indicating that
the Announce failed?

> supports it?  Is it going to be advertised by an extension?

I don't see why this would necessarily be an extension. It's an
implementation "detail". What, specifically goes into a modem's support of
Destination Announce? Up to the modem developer.

Regards,
Stan

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Fri, 12 Feb 2016 19:50:30 +0000

Stan asked:

In general, if a data item is allowed on a message/signal, and is is
well-formed (length matches the expected length for this data item, any
restrictions on allowed values are met, etc.), and there isn't a
specifically called-out protocol reason to reject it, then our
implementation accepts it, even if it has no use for it.  ("Be liberal in
what you accept...")  If we definitely want every implementation to reject
a Destination Announce for a unicast address if it doesn't know what to do
with it, then I would expect that to be stated in the draft.  If we want
to leave this case up to implementations, then the draft doesn't have to
say anything about this, and some implementations will accept it and some
won't.

I didn't intend for this to get bogged down in minutiae; the bigger point
is that I'm not sure all of the protocol interactions between
Announce/Down from the router and Up/Down from the modem are sufficiently
spelled out, and I was just picking one example above of such an
interaction.

David

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 14 Feb 2016 17:42:01 -0500

David,

> spelled out, and I was just picking one example above of such an
I'm not sure where we go from here. If there are recommendations for
improving the draft, then please let me know. Otherwise, we'll press
forward with DLEP-18.

Regards,
Stan

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Wed, 17 Feb 2016 22:18:00 +0000

>clear on all of the ramifications of allowing either side to do the Down

The addition in the latest draft of the sentence "It should be noted that
both modem and router may send a Destination Down message to its peer" is
helpful.  I suggest further clarification, maybe adding ", regardless of
which peer initially announced or declared the destination to be up."

If the modem declares a destination to be up, and the router responds
Success, then later the router says destination down, I believe what is
intended is that the modem stop sending *any* messages regarding that
destination to the router.  It is as if the router had responded Not
Interested to the initial Up.  To the modem, though, that destination is
still up, and it will continue to tell other peers about it.  If that is
all correct, then I think the description of Destination Down should cover
this.  Currently it just says "A DLEP participant MUST send a Destination
Down message to report when a destination (a remote node or a multicast
group) is no longer reachable."  In this case, it's not that the
destination isn't reachable, it's that the router doesn't want to hear
about it any more.

One way to do this might be to split the description of Destination Down
in two, one part addressing what happens when the peer that initiated the
Up/Announce does the Down, and the other part addressing when the
non-initiating peer does the Down.  Having a new message to cancel an
Announce (instead of reusing Down), an idea that Rick floated, might also
help to clarify these cases.

David