Subject: [manet] DLEP Draft 8 Comments

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 23 Mar 2015 18:05:57 +0000

Hi all,

Sorry for the late response. We've been updating our implementation to
support Draft 08 and have found a few things that may require some
updates/modifications. If it¹s relevant/acceptable to the group, we¹d be
happy to make the changes and provide a diff. Most of them are consistency
issues. David W. has been doing the implementation and I¹ve CC-ed him
incase there needs any clarification.

Minor Typos:
=============

1.      p. 9, second paragraph, "manipulation or or substitution" (two
or's)

2.      section 7.1, p. 17, "Peer Discovery signal SHOULD be sent by a
router to discover DLEP routers" should be "to discover DLEP modems²

Clarification needed:
=====================

1.       There is still inconsistency in the direction of the Peer
Initialization and Peer Initialization Ack signals.

- section 4, p. 12, "DLEP modem implementations MUST announce all
supported metric items, and provide default values for those metrics, in
the Peer Initialization signal", thus indicating that the modem sends this
signal.

- Then in section 5.2, p.13, "the modem implementation MUST issue a Peer
Initialization signal... to the DLEP router... the modem implementation
MUST wait for receipt of a Peer Initialization ACK signal from the
router." So this agrees with section 4.

- section 5.3, p. 14, "the DLEP modem... MUST send a Peer Initialization
signal" Everything agrees so far...

- section 7.3, p. 19, "A Peer Initialization signal MUST be sent by a
router as the first signal of the DLEP TCP session." So this contradicts
the above three.

- section A.4, p. 56, the diagram shows the modem sending Peer
Initialization.

- So 4 out of 5 places say that the modem sends Peer Initialization, with
only section 7.3 saying that the router sends it. Nevertheless, we believe
that the router is supposed to send this signal.

2.      The draft is inconsistent about whether metrics are to be included
in the Peer Initialization vs. Peer Initialization Ack signals.
The following places say that metrics should be included in Peer
Initialization:

- section 4, p. 12; section 5.2, p. 13; section 5.3, p. 14

- However, section 7.3, p. 19, describes the Peer Initialization signal in
detail and says nothing of metrics.

- section 7.4, p. 20, says that metrics should be included in the Peer
Initialization ACK Signal. Also, the descriptions of the individual metric
data items, like 8.13. Maximum Data Rate (Receive), say that they MUST be
in Peer Initialization ACK but do not mention Peer Initialization, even as
MAY appear.

- This is probably more fallout from switching the direction of the Peer
Init / Peer Init ACK signals. I think that the sections cited above that
come before 7.3 are wrong, and the rest are correct.

3.      The draft never clearly states when Heartbeats commence.

- There are a couple of hints that it starts after Peer Initialization is
sent. In section 8.5, "The receiver (of Peer Initialization) MUST either
accept the (heartbeat) timeout interval supplied by the sender, or reject
the Peer Initialization, and close the socket." So one might surmise that
before the heartbeat interval is accepted, there can be no heartbeating.
(As an aside, it is not clear what it means to "accept" the interval.)
Later, in section A.4, heartbeats are shown flowing immediately after Peer
Initialization, and the Peer Initialization Ack is not shown at all.

- I am uncomfortable with the above interpretation. The session isn't
fully established until the modem sends an affirmative Peer Initialization
Ack. The modem can decide to reject the session, in which case it will
never send heartbeats, and any heartbeats sent by the router will have
been for naught. It seems better to wait for the affirmative Peer
Initialization Ack to be sent by the modem / received by the router to
start heartbeats. The draft describes this as the "in session" state. I
will assume that heartbeats commence once the "in session" state is
entered.

4.      The draft is unclear about which side of the session the heartbeat
interval applies to.

Let's look at the router sending a Peer Initialization signal containing
heartbeat interval H to the modem. Which of the following does this mean:
- The router is going to send heartbeats every H seconds, and the modem is
responsible for ending the session if there is no activity in the last 2H
seconds.
- The router expects the modem to send heartbeats every H seconds, and the
router is responsible for ending the session if there is no activity in
the last 2H seconds.
- Both of the above. The router and modem are expected to agree on the
heartbeat interval.

Restating more generally, when a session participant specifies a heartbeat
interval, is it saying that it is going to send heartbeats at that
interval, or is it saying that it is expecting its peer to send heartbeats
at that interval? Or both?
Section 8.5 says "The receiver MUST either accept the timeout interval
supplied by the sender" which could be interpreted as meaning both sides
must use the same interval. That is reading a whole lot into the one word
"accept," though, and this interpretation isn't supported anywhere else in
the document. I'm going to assume for now that the intervals used by each
side are independent and can be different.

5.      The draft states in several places that the Peer Discovery message
is sent by the router. However, the diagrams in sections A.3 and A.4 show
the modem sending this message.

6.      General comment on the whole protocol: I couldn't tell what
possible interleavings of signals are allowed. For example, can a
heartbeat appear between a signal and the ack of that signal? (By default,
our implementation will sometimes do this because heartbeats are sent by a
different thread that has no idea what else is going on in the protocol.)
Can the modem send several Destination Ups in a row and then wait for all
of the acks to come back? Or is this strictly a stop-and-wait protocol?

Minor design suggestions:
=========================
 
1.      section 8.2 Status: in the case of an Invalid Signal status, it
would be convenient to include the offending ("invalid, unexpected, or
duplicated") data items to assist in troubleshooting why the signal failed.

2.      Small potential simplification of the protocol: have a single Ack
signal type instead of per-signal Ack types. One of the data items in this
generic Ack could represent the signal type that is being Ack'ed.

On 2/27/15, 11:47 AM, "[email-masked]"
<[email-masked]> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group of
>the IETF.
>
>        Title           : Dynamic Link Exchange Protocol (DLEP)
>        Authors         : Stan Ratliff
>                          Bo Berry
>                          Darryl Satterwhite
>                          Rick Taylor
>	Filename        : draft-ietf-manet-dlep-08.txt
>	Pages           : 63
>	Date            : 2015-02-27
>
>Abstract:
>   When routing devices rely on modems to effect communications over
>   wireless links, they need timely and accurate knowledge of the
>   characteristics of the link (speed, state, etc.) in order to make
>   forwarding decisions.  In mobile or other environments where these
>   characteristics change frequently, manual configurations or the
>   inference of state through routing or transport protocols does not
>   allow the router to make the best decisions.  A bidirectional, event-
>   driven communication channel between the router and the modem is
>   necessary.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-manet-dlep-08
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-08
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/manet

---

From: Rick Taylor <[email-masked]>
Date: Mon, 23 Mar 2015 18:57:03 +0000

Bow-Nan,

Thanks you so much for your review, you've raised some very good points
that should be addressed.

The confusion about the Initialization and Initialization Ack signals I
believe comes from the repeated rewriting of those sections and some
consistency has been lost in the cut'n'paste.  These sections will
definitely need to be proof-read again.

I agree with your assessment on Heartbeats.  There does need to be some
more explicit text covering their use.  Your assumptions match our
intention for heartbeats, but I agree with you that it needs to be
written better in the draft.

Your suggestion for a general purpose ACK signal is good, but we are
under a lot of pressure to get DLEP 'done' so it might not happen.

For the Status data item, I agree, some context would be useful, but I
am not keen on trying to encode 'pointers to faulty items' data into the
TLV.  Would an additional free text field suitable for logging be more
useful than nothing? 

If anyone else has any comments, however minor, please raise them,

Thanks,

Rick Taylor

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 23 Mar 2015 19:27:18 +0000

Hi Rick,

I have been working with Bow-Nan to bring our DLEP implementation up to the current draft, so I'll take the response to this.

Regarding the Invalid Signal status, I'm fine with leaving it the way it is.  A free text field might be somewhat helpful, but the modem/router will probably log something locally that we can use to figure out the details of what happened, so we'd probably be fine even without that.

There was one other thing I meant to mention.  The Destination Update signal is the only one that doesn't have an associated ACK signal.  Is that intentional, or an oversight?  Apologies if the answer to that or any of the others are in the archives; I haven't gone through them in detail.

David Wiggins

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
Sent: Monday, March 23, 2015 2:57 PM
To: Cheng, Bow-Nan - 0665 - MITLL; [email-masked]; Stan Ratliff
Subject: Re: [manet] DLEP Draft 8 Comments

Bow-Nan,

Thanks you so much for your review, you've raised some very good points that should be addressed.

The confusion about the Initialization and Initialization Ack signals I believe comes from the repeated rewriting of those sections and some consistency has been lost in the cut'n'paste.  These sections will definitely need to be proof-read again.

I agree with your assessment on Heartbeats.  There does need to be some more explicit text covering their use.  Your assumptions match our intention for heartbeats, but I agree with you that it needs to be written better in the draft.

Your suggestion for a general purpose ACK signal is good, but we are under a lot of pressure to get DLEP 'done' so it might not happen.

For the Status data item, I agree, some context would be useful, but I am not keen on trying to encode 'pointers to faulty items' data into the TLV.  Would an additional free text field suitable for logging be more useful than nothing? 

Thanks,

Rick Taylor

On 23/03/15 18:06, Cheng, Bow-Nan - 0665 - MITLL wrote:
> updates/modifications. If it¹s relevant/acceptable to the group, we¹d 
> be happy to make the changes and provide a diff. Most of them are 
> consistency issues. David W. has been doing the implementation and 
> I¹ve CC-ed him incase there needs any clarification.
>
>
> Minor Typos:
> =============
>
>  
> supported metric items, and provide default values for those metrics, 
> in the Peer Initialization signal", thus indicating that the modem 
> sends this signal.
>
> - Then in section 5.2, p.13, "the modem implementation MUST issue a 
> Peer Initialization signal... to the DLEP router... the modem 
> implementation MUST wait for receipt of a Peer Initialization ACK 
> signal from the router." So this agrees with section 4.
>
> - section 5.3, p. 14, "the DLEP modem... MUST send a Peer 
> Initialization signal" Everything agrees so far...
>
> router as the first signal of the DLEP TCP session." So this 
> contradicts the above three.
>
> - So 4 out of 5 places say that the modem sends Peer Initialization, 
> with only section 7.3 saying that the router sends it. Nevertheless, 
> we believe that the router is supposed to send this signal.
>
> - However, section 7.3, p. 19, describes the Peer Initialization 
> signal in detail and says nothing of metrics.
>
> Initialization ACK Signal. Also, the descriptions of the individual 
> metric data items, like 8.13. Maximum Data Rate (Receive), say that 
> they MUST be in Peer Initialization ACK but do not mention Peer 
> Initialization, even as MAY appear.
>
> - This is probably more fallout from switching the direction of the 
> Peer Init / Peer Init ACK signals. I think that the sections cited 
> above that come before 7.3 are wrong, and the rest are correct.
>
> - There are a couple of hints that it starts after Peer Initialization 
> is sent. In section 8.5, "The receiver (of Peer Initialization) MUST 
> either accept the (heartbeat) timeout interval supplied by the sender, 
> or reject the Peer Initialization, and close the socket." So one might 
> surmise that before the heartbeat interval is accepted, there can be no heartbeating.
> Later, in section A.4, heartbeats are shown flowing immediately after 
> Peer Initialization, and the Peer Initialization Ack is not shown at all.
>
> fully established until the modem sends an affirmative Peer 
> Initialization Ack. The modem can decide to reject the session, in 
> which case it will never send heartbeats, and any heartbeats sent by 
> the router will have been for naught. It seems better to wait for the 
> affirmative Peer Initialization Ack to be sent by the modem / received 
> by the router to start heartbeats. The draft describes this as the "in 
> session" state. I will assume that heartbeats commence once the "in 
> session" state is entered.
>
> Let's look at the router sending a Peer Initialization signal 
> containing heartbeat interval H to the modem. Which of the following does this mean:
> - The router is going to send heartbeats every H seconds, and the 
> modem is responsible for ending the session if there is no activity in 
> the last 2H seconds.
> - The router expects the modem to send heartbeats every H seconds, and 
> the router is responsible for ending the session if there is no 
> activity in the last 2H seconds.
> Restating more generally, when a session participant specifies a 
> heartbeat interval, is it saying that it is going to send heartbeats 
> at that interval, or is it saying that it is expecting its peer to 
> send heartbeats at that interval? Or both?
> supplied by the sender" which could be interpreted as meaning both 
> sides must use the same interval. That is reading a whole lot into the 
> one word "accept," though, and this interpretation isn't supported 
> anywhere else in the document. I'm going to assume for now that the 
> intervals used by each side are independent and can be different.
>
> is sent by the router. However, the diagrams in sections A.3 and A.4 
> show the modem sending this message.
>  
>
> heartbeat appear between a signal and the ack of that signal? (By 
> default, our implementation will sometimes do this because heartbeats 
> are sent by a different thread that has no idea what else is going on 
> in the protocol.) Can the modem send several Destination Ups in a row 
> and then wait for all of the acks to come back? Or is this strictly a stop-and-wait protocol?
>  
>
> signal type instead of per-signal Ack types. One of the data items in 
> this generic Ack could represent the signal type that is being Ack'ed.
>
>
>
>
>
>> This draft is a work item of the Mobile Ad-hoc Networks Working Group 
>> of the IETF.
>>
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Mar 2015 14:16:02 +0000

Hi David,

I've been chatting to Stan about your and Bow-Nan's comments, and I
think we are in some rough agreement that a free text field on the
Status data item is a simple change with some benefit, so if there are
no strong objections from the list, it might make it in. (I'm not
committing to anything until after the WG meeting!)

The Destination Update signal intentionally has no ACK as it is a 'pure'
notification signal, I can't think of anything the receiver can reply
about, and we assume the vast amount of signals generated during a DLEP
session being Updates, hence removing the processing/bandwidth
requirements of ACKing each one.  Do you have a specific use-case where
you need to ACK an update, when a Link Characteristics Request or other
Dest* signal won't do?

To answer Bow-Nan's earlier comment about a generic ACK signal, Stan and
I agree that a specific ACK per signal keeps the message flow more
'functional programming' in style, and that has a slight advantage in
clarity over reducing the number of signal items.  Fundamentally one's
code still has to do a big switch statement, whether one does it on
signal receive or after 'generic ACK' signal receive makes little real
difference. (And I'm sure the Lisp community has some clever Lambda
technique they will want to brag about ;-) )

No problem with repeating possibly answered questions!  I would rather
DLEP was discussed and reviewed thoroughly than silence.

Cheers,

Rick Taylor

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 24 Mar 2015 14:31:14 +0000

Hi Rick,

I didn't identify a specific need for an ACK to Destination Update.  It just stuck out as being practically the only ACK-less signal, so it made me wonder if something was amiss.  Your rationale makes perfect sense.  Thanks!
 
David

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Tuesday, March 24, 2015 10:16 AM
To: Wiggins, David - 0665 - MITLL; Cheng, Bow-Nan - 0665 - MITLL; [email-masked]; Stan Ratliff
Subject: Re: [manet] DLEP Draft 8 Comments

Hi David,

I've been chatting to Stan about your and Bow-Nan's comments, and I think we are in some rough agreement that a free text field on the Status data item is a simple change with some benefit, so if there are no strong objections from the list, it might make it in. (I'm not committing to anything until after the WG meeting!)

The Destination Update signal intentionally has no ACK as it is a 'pure'
notification signal, I can't think of anything the receiver can reply about, and we assume the vast amount of signals generated during a DLEP session being Updates, hence removing the processing/bandwidth requirements of ACKing each one.  Do you have a specific use-case where you need to ACK an update, when a Link Characteristics Request or other
Dest* signal won't do?

To answer Bow-Nan's earlier comment about a generic ACK signal, Stan and I agree that a specific ACK per signal keeps the message flow more 'functional programming' in style, and that has a slight advantage in clarity over reducing the number of signal items.  Fundamentally one's code still has to do a big switch statement, whether one does it on signal receive or after 'generic ACK' signal receive makes little real difference. (And I'm sure the Lisp community has some clever Lambda technique they will want to brag about ;-) )

No problem with repeating possibly answered questions!  I would rather DLEP was discussed and reviewed thoroughly than silence.

Cheers,

Rick Taylor

On 23/03/15 19:27, Wiggins, David - 0665 - MITLL wrote:
>> Sorry for the late response. We've been updating our implementation 
>> to support Draft 08 and have found a few things that may require some 
>> - section 7.4, p. 20, says that metrics should be included in the 
>> Peer Initialization ACK Signal. Also, the descriptions of the 
>> individual metric data items, like 8.13. Maximum Data Rate (Receive), 
>> say that they MUST be in Peer Initialization ACK but do not mention 
>> Peer Initialization, even as MAY appear.
>>
>> - There are a couple of hints that it starts after Peer 
>> Initialization is sent. In section 8.5, "The receiver (of Peer 
>> Initialization) MUST either accept the (heartbeat) timeout interval 
>> supplied by the sender, or reject the Peer Initialization, and close 
>> the socket." So one might surmise that before the heartbeat interval is accepted, there can be no heartbeating.
>> (As an aside, it is not clear what it means to "accept" the 
>> interval.) Later, in section A.4, heartbeats are shown flowing 
>> immediately after Peer Initialization, and the Peer Initialization Ack is not shown at all.
>>
>> affirmative Peer Initialization Ack to be sent by the modem / 
>> received by the router to start heartbeats. The draft describes this 
>> as the "in session" state. I will assume that heartbeats commence 
>> once the "in session" state is entered.
>>
>> modem is responsible for ending the session if there is no activity 
>> in the last 2H seconds.
>> - The router expects the modem to send heartbeats every H seconds, 
>> and the router is responsible for ending the session if there is no 
>> - Both of the above. The router and modem are expected to agree on 
>> the heartbeat interval.
>>
>> Section 8.5 says "The receiver MUST either accept the timeout 
>> interval supplied by the sender" which could be interpreted as 
>> meaning both sides must use the same interval. That is reading a 
>> whole lot into the one word "accept," though, and this interpretation 
>> isn't supported anywhere else in the document. I'm going to assume 
>> for now that the intervals used by each side are independent and can be different.
>>
>>> This draft is a work item of the Mobile Ad-hoc Networks Working 
>>> Group of the IETF.
>>>

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 29 Mar 2015 16:13:40 -0400

Bow-Nan,

Thanks for the review. We're working to incorporate your changes into a
DLEP-09, which will be submitted for WGLC.

One comment on this item:

> of the acks to come back? Or is this strictly a stop-and-wait protocol?
I think that depends on the implementation. The protocol doesn't attempt to
constrain one way or another - we say on several occasions that the sender
of a signal is "...free to define its retry heuristics in the event of a
timeout". So, in this case, the sender of Destination Up decides how long
to wait before considering the signal lost, and whether or not to send
additional Destination Up signals up the same pipe.

Regards,
Stan

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 30 Mar 2015 22:03:29 +0000

Thanks Stan and Rick!

We’ll take a look when the new draft comes out, but I don’t foresee any issues. Thanks for all your hard work!!

-Bow-Nan

From: Stan Ratliff <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 29, 2015 at 4:13 PM
To: Bow-Nan Cheng <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Wiggins, David - 0665 - MITLL" <[email-masked]<mailto:[email-masked]>>
Subject: Re: DLEP Draft 8 Comments

Bow-Nan,

Thanks for the review. We're working to incorporate your changes into a DLEP-09, which will be submitted for WGLC.

On Mon, Mar 23, 2015 at 2:05 PM, Cheng, Bow-Nan - 0665 - MITLL <[email-masked]<mailto:[email-masked]>> wrote:

I think that depends on the implementation. The protocol doesn't attempt to constrain one way or another - we say on several occasions that the sender of a signal is "...free to define its retry heuristics in the event of a timeout". So, in this case, the sender of Destination Up decides how long to wait before considering the signal lost, and whether or not to send additional Destination Up signals up the same pipe.

Regards,
Stan