Subject: [manet] DLEP-17: error handling during "In-Session" state

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 10:54:29 -0500

Section 5.3 seems to talk about all of the expected behaviors,
which is great.

But what is the intended response behavior if one side of the 
active DLEP session receives a (presumably unexpected) TCP Reset ?

It seems to me that Section 5.3 ought to say something about:

(a) whether a DLEP peer is allowed to just reset the DLEP TCP session.
    (Maybe it isn’t allowed to, from a DLEP perspective, which
    might be important to note so implementers know this.)

(b) how the other DLEP peer, the one receiving the TCP RST,
    should respond to receiving that TCP RST 
    (e.g. does it try to restart the DLEP session, does it wait 
    for the other side to restart the DLEP session, or is some 
    other behavior appropriate)

Thanks,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 16:10:03 +0000

Thanks Ran,

My current thoughts are to add a blanket statement to Section 5, saying 
something along the lines of "A TCP reset in any state causes an 
immediate transition to the relevant initial state, clearing any session 
information bases."

I don't see the need for special handling for particular states, or any 
kind of 'gentle' restarting.

Cheers,

Rick

On 24/11/15 15:54, RJ Atkinson wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 17:27:48 +0100

> kind of 'gentle' restarting.

As far as I read the draft the "reset" is a termination both of the
TCP session and the protocol data associated with the session.

You tear everything down and start a completely new connection.

Henning Rogge

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:03:30 -0500

> On 24  Nov 2015, at 11:10 , Rick Taylor <[email-masked]> wrote:
> 
> Thanks Ran,
> 
> information bases.”

I am unclear what “relevant initial state” above means.  Perhaps
say that when one receives a TCP Reset that (a) the current DLEP
session terminates and (b) the receiver should do X 

[alternately: "(b) the receiver should listen on the DLEP port 
as it would if the previous abruptly terminated DLEP session 
had never existed”]

I’m not sure what you mean “X" to be.  It could be do X or 
to do nothing.  Please edit to make it clear somehow.

> kind of 'gentle' restarting.

I’m flexible about how to resolve this.

The key thing for me is to document the intended reaction,
so that a naive implementer has a good probability of
coding correctly.

Thanks,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:09:35 -0500

> On 24  Nov 2015, at 11:27 , Henning Rogge <[email-masked]> wrote:
> 

If that’s the answer, please say so explicitly.  Right now the
I-D is not so crystal clear.

Thanks,

Ran

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 Nov 2015 13:25:05 +0000

> session terminates and (b) the receiver should do X

The 'relevant initial state' text is used in the Session Flows section 
to mean "discovery state or session initialization state if you are a 
router and not doing discovery".  Out of context I can see it being unclear.

> so that a naive implementer has a good probability of

Completely agree.

Rick