Subject: [manet] DLEP-09 Last Call issue

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 21 Apr 2015 14:14:21 +0000

Working Group Participants,

It was noted during a private discussion that there could be an issue with DLEP and Heartbeats. Specifically, the scenario mentioned was:

1.       Peer Discovery/Peer Offer processing takes place with no errors or issues.

2.       Router uses information received from Peer Offer, and connects a socket to the modem. Router sends Peer Initialization, with a Heartbeat TLV.

3.       Modem, for whatever reason, *fails* to respond to Peer Initialization.

The question/issue is that Heartbeats (if used at all) aren't fully established at that point, since they require the Peer Initialization/Peer Initialization ACK sequence. So what to do?

Here is the proposed fix - the following text will be inserted into the Peer Initialization section:

"It should be noted that Heartbeats (if used) are not fully established until both the Peer Initialization and Peer Initialization ACK messages have been sent and successfully processed by the appropriate recipient. This leaves the possibility for timing issues to occur (e.g. a Peer Initialization message is sent from router to modem, but no Peer Initialization ACK is received). Prior to the establishment of the Heartbeat interval, heuristics for determining the amount of time to wait for a specific message, or to declare the session inoperative, are left to implementers. However, it is recommended that an implementation select some reasonable multiple of its own proposed Heartbeat interval in these cases, in order to minimize the number of inputs to the implementation."

Other opinions are welcome.

Regards,
Stan
________________________________
Stan Ratliff  |  Architect, Applied Research
VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA
T: +1 703 544-8520  |  F: +1 222 123-4567
[email-masked]<mailto:[email-masked]>  |  www.idirect.net<http://www.idirect.net>
Connect with iDirect: Twitter.com/iDirect<https://twitter.com/idirect>  |  Facebook.com/iDirect<https://www.facebook.com/idirect>

Advancing a Connected World

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Tue, 21 Apr 2015 16:45:20 +0000

Several other signals that expect ACKs have words like: "The sender of the Destination Up signal is free to define its retry heuristics in event of a timeout."  I see that Peer Initialization does not say this, but perhaps it should.  Wouldn't that fix the problem, and be more in line with the rest of the draft?

David

From: manet [mailto:[email-masked]] On Behalf Of Ratliff, Stanley
Sent: Tuesday, April 21, 2015 10:14 AM
To: [email-masked]
Subject: [manet] DLEP-09 Last Call issue

Regards,
Stan

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 21 Apr 2015 16:51:54 +0000

David,

I'm OK with doing it that way as well.

Are there other opinions out there? Send 'em if you got 'em - I'd like to close on this.

Regards,
Stan

From: Wiggins, David - 0665 - MITLL [mailto:[email-masked]]
Sent: Tuesday, April 21, 2015 12:45 PM
To: Ratliff, Stanley; [email-masked]
Subject: RE: DLEP-09 Last Call issue

David

From: manet [mailto:[email-masked]] On Behalf Of Ratliff, Stanley
Sent: Tuesday, April 21, 2015 10:14 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] DLEP-09 Last Call issue

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 21 Apr 2015 19:45:21 +0200

On Tue, Apr 21, 2015 at 6:45 PM, Wiggins, David - 0665 - MITLL
<[email-masked]> wrote:
>
> Several other signals that expect ACKs have words like: “The sender of the Destination Up signal is free to define its retry heuristics in event of a timeout.”  I see that Peer Initialization does not say this, but perhaps it should.  Wouldn’t that fix the problem, and be more in line with the rest of the draft?

I think the Peer Discovery/Peer Offer case is even more important
because they are not protected by the Heartbeat. For every other
signal if the implementation misses to send the ACK (or the ACK is
lost) the protocol will still work somehow or it will be resetted by a
missing Heartbeat.

If the TCP session is activated but one of the Peer Signals get lost
or is not handled correctly, DLEP will just do nothing until the TCP
timeout will save you... which might take a couple of minutes. If your
DLEP radio or router does only allow a single connection at the same
time, all you could do is to reset both devices.

So I think the longer text Stan suggested is better for this case.

Henning Rogge

---

From: Victoria Mercieca <[email-masked]>
Date: Wed, 22 Apr 2015 11:15:33 +0100

Hi Stan, hi all,

>From Section 4.3 and 4.5, it's pretty clear that heartbeats begin to flow
_after_ a Peer Initialization ACK is received with a success status code,
so no heartbeat-related timers would be started on the router until the
Peer Initialization ACK is received. However, the modem receiving the Peer
Initialization would start up the heartbeat timer when it sends the Peer
Initialization ACK.

In case the ACK was lost, the router should have some timeout behaviour on
the Peer Initialization, like David Wiggins says. I think your suggested
text effectively says this but in a much more complicated way?

Also, if the router is not "in-session", because no Peer Initialization ACK
was received, would the router respond to any other signals from the modem
(including Heartbeat) with a Peer Termination anyway? You mention earlier
in section 4.4 that any other signals received when expecting the Peer
Offer would be silently dropped, but you dont have a similar comment for
the Initialization signals. Sending a Peer Termination would fit with the
other comments in the document that any unexpected/invalid signal should
cause a termination, and you have a status code for this too. So the
problem would be resolved by Peer Termination when any other signal is
received from the modem. Alternatively, but I suppose the delay is
undesirable, the modem will terminate the session after 2 of its own
heartbeat intervals anyway, since the router will not send any DLEP signals
while waiting for the Peer Initialization ACK.

Kind regards,
Victoria.

On Tue, Apr 21, 2015 at 5:51 PM, Ratliff, Stanley <[email-masked]>
wrote:

>  David,
>
>
>
> I’m OK with doing it that way as well.
>
>
>
> Are there other opinions out there? Send ‘em if you got ‘em – I’d like to
> close on this.
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
> *From:* Wiggins, David - 0665 - MITLL [mailto:[email-masked]]
> *Sent:* Tuesday, April 21, 2015 12:45 PM
> *To:* Ratliff, Stanley; [email-masked]
> *Subject:* RE: DLEP-09 Last Call issue
>
>
>
> *From:* manet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ratliff, Stanley
> *Sent:* Tuesday, April 21, 2015 10:14 AM
> *To:* [email-masked]
> *Subject:* [manet] DLEP-09 Last Call issue
>
>
>
> It was noted during a private discussion that there could be an issue with
> DLEP and Heartbeats. Specifically, the scenario mentioned was:
>
>
>
> 2.       Router uses information received from Peer Offer, and connects a
> socket to the modem. Router sends Peer Initialization, with a Heartbeat TLV.
>
> 3.       Modem, for whatever reason, **fails** to respond to Peer
> Initialization.
>
>
>
> The question/issue is that Heartbeats (if used at all) aren’t fully
> established at that point, since they require the Peer Initialization/Peer
> Initialization ACK sequence. So what to do?
>
>
>
> Here is the proposed fix – the following text will be inserted into the
> Peer Initialization section:
>
>
>
> "It should be noted that Heartbeats (if used) are not fully established
> until both the Peer Initialization and Peer Initialization ACK messages
> have been sent and successfully processed by the appropriate recipient.
> This leaves the possibility for timing issues to occur (e.g. a Peer
> Initialization message is sent from router to modem, but no Peer
> Initialization ACK is received). Prior to the establishment of the
> Heartbeat interval, heuristics for determining the amount of time to wait
> for a specific message, or to declare the session inoperative, are left to
> implementers. However, it is recommended that an implementation select some
> reasonable multiple of its own proposed Heartbeat interval in these cases,
> in order to minimize the number of inputs to the implementation."
>
>
>
>
>
>  ------------------------------
>
> *Stan Ratliff  *|  Architect, Applied Research
>
> *VT iDirect  *|  13861 Sunrise Valley Drive, Suite 300, Herndon, VA
> 20171, USA
>
> [email-masked]  |  www.idirect.net
>
> *Connect with iDirect: *Twitter.com/iDirect <https://twitter.com/idirect>
> |  Facebook.com/iDirect <https://www.facebook.com/idirect>
>
>
>
>  *Advancing a Connected World*
>
>
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>