Subject: [manet] suggestions for further DLEP development

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 15 Oct 2012 17:22:28 -0700

Hi, I had a chance today to finally read the -03 dlep draft, and catch up on the list traffic since it was published.  I'd like to suggest a few things to try to make better progress.

First, it is very hard to review the list traffic to figure out what has reached either WG consensus or a decision point by the authors.  There are possibly hundreds of messages with the same subject line "Some comments on manet-dlep-03", containing many separate technical threads.  Could people please make an effort in the future to originate a new subject line when the topic forks, and to try to keep topics organized and separated by thread that is clear in the subject line?

It was previously suggested to use the tracker to document these issues and their wrapup/conclusion, an idea that I offer +1 to, but if the WG chooses to not use the tracker, perhaps some kind of informal convention could be adopted such as posting to the list with a clear subject such as "Decision on RFC 5444 issue for DLEP".  I'd also be in favor of recording this in a change log in the draft, for that matter, but I would be happy with just using an issue tracker or summary messages on the list if the authors do not want to use the draft this way.

Regarding the draft itself, it seems to me that there are still many fundamental disagreements or concerns about underspecification of the basic protocol for message exchanges and management of state between the entities.  I'd suggest first that the group try to document/decide basic aspects of the protocol without concern for the finer details of some of the radio-specific parameters.  Such as:

- is DLEP transport independent or not?   If so, what are the anticipated transports?
- is there a need for a stateful session?
- is there a need for a per-session identifier?  DLEP-layer node identifiers?  a message sequence number?
- what are the requirements for reliable message delivery, unreliable message delivery, etc.?
- how do acknowledgments work?  Are acknowledgments on a per-TLV or per-message basis?
- who can initiate or terminate a session?
- RFC 5444 or not?
- what is the version number; what is the distinction between major and minor numbers?
- can messages mix optional TLVs with mandatory, reliable TLVs?  Is TLV ordering to be enforced?
etc.

I'd suggest that the working group focus first on writing down and agreeing upon some requirements and detailed protocol just to cover the session state aspects, such that it would be really hard to come up with implementations that did not interoperate at that level.  Then move on to the radio-specific TLVs and issues there.

This kind of protocol has been done before and (I've suggested this in the past) it may be more efficient to try to reuse/adapt an existing protocol (LCP and X.25 come to mind).  This protocol may seem simple but when one starts to deal with issues such as race conditions, state misalignment (one side reboots and the other side doesn't detect it), notifications of errors to the peer, parameter negotiations, multiple devices on link, etc. one gets into issues that lead to interoperability and robustness problems.

- Tom

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 15 Oct 2012 18:06:49 -0700

Hello folks,

Just one comment...

> It was previously suggested to use the tracker to document these issues and their wrapup/conclusion, an idea that I offer +1 to, but if the WG chooses to not use the tracker, perhaps some kind of i…

For any draft with contentious issues, I think that the issue tracker 
ought to
be considered a "must", and the change log is even more of a "must".

It really helps to avoid going around in circles.

I also agree that it is very helpful to use more descriptive "Subject:" 
lines,
but it is not so easy to remember to do that.

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 16 Oct 2012 12:09:32 +0200

I agree totally that we need to make clear decisions with the
subjects/questions you mentioned. I already was trying many time to
remind the DLEP authors about this, and there was some comments not
responded when the new -03 version came out. Please note that I
already was doing that if you may refer to my history in the MANET WG,
and will recommend all to do the same.

IMHO, the problem is that the MANET WG mostly depends on making its
decisions in the Face-to-Face meeting, more than making them in the
Discussion list, which I disagree. Further more, in the last meeting
the WG did not give some reflection about the Discussion List which I
RECOMMEND that we do in the future, for the progress and reminder
purposes.

AB

On 10/16/12, Charles E. Perkins <[email-masked]> wrote:
>> It was previously suggested to use the tracker to document these issues
>> and their wrapup/conclusion, an idea that I offer +1 to, but if the WG
>> chooses to not use the tracker, perhaps some kind of informal convention
>> could be adopted such as posting to the list with a clear subject such as
>> "Decision on RFC 5444 issue for DLEP".  I'd also be in favor of recording
>> this in a change log in the draft, for that matter, but I would be happy
>> with just using an issue tracker or summary messages on the list if the
>> authors do not want to use the draft this way.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Oct 2012 13:53:15 +0200

On 10/16/2012 02:22 AM, Henderson, Thomas R wrote:
> Hi, I had a chance today to finally read the -03 dlep draft, and
> catch up on the list traffic since it was published.  I'd like to
> suggest a few things to try to make better progress.
>
> First, it is very hard to review the list traffic to figure out what
> has reached either WG consensus or a decision point by the authors.
> There are possibly hundreds of messages with the same subject line
> "Some comments on manet-dlep-03", containing many separate technical
> threads.  Could people please make an effort in the future to
> originate a new subject line when the topic forks, and to try to
> keep topics organized and separated by thread that is clear in the
> subject line?

Yes, we should keep attention to change the subject to a relevant topic.

> It was previously suggested to use the tracker to document these
> issues and their wrapup/conclusion, an idea that I offer +1 to,

I have no strong opinion on this.

 > but
> if the WG chooses to not use the tracker, perhaps some kind of
> informal convention could be adopted such as posting to the list
> with a clear subject such as "Decision on RFC 5444 issue for DLEP".

Yes, that is a good idea.

> I'd also be in favor of recording this in a change log in the draft,
> for that matter, but I would be happy with just using an issue
> tracker or summary messages on the list if the authors do not want to
> use the draft this way.

I am not sure a changelog is necessary. It might be a lot of additional 
work.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Oct 2012 14:08:43 +0200

Split off from the first mail...

On 10/16/2012 02:22 AM, Henderson, Thomas R wrote:
> Regarding the draft itself, it seems to me that there are still many
> fundamental disagreements or concerns about underspecification of the
> basic protocol for message exchanges and management of state between
> the entities.  I'd suggest first that the group try to
> document/decide basic aspects of the protocol without concern for the
> finer details of some of the radio-specific parameters.  Such as:
>

While the first drafts talked about "transport independence", the 
consensus has shifted to "UDP" as the standard transport protocol.

Teco has suggesting using TCP instead of DLEP-specific ACK mechanisms.

> - is there a need for a stateful session?

As far as I understand it, the session is needed for flow control, but 
would not be needed for pure 'metric delivery' from radio to router. The 
authors prefer to use a session for both.

> - is there a need for a per-session identifier? DLEP-layer node
> identifiers?

DLEP needs a radio identifier to allow multi-line radios talking over 
the same Ethernet interface to the router. IP address and port of the 
radio agent might be okay for this, if the radio agent can run without a 
well-known port of its own.

 > a message sequence number?

Currently DLEP-03 contains no sequence number, which only allows for a 
"stop and wait" delivery of messages (send one, wait for ACK, ...).

The exact mechanism how the ACK system will work is not specified, just 
the messages are in the draft.

The ACK messages are marked as "optional", which raises (in my opinion) 
the question how a sender which expects ACKs works together with a 
receiver which does not support ACKs.

Acknowledgements are message-specific.

> - who can initiate or terminate a session?

While DLEP-03 shifted from "Radio initiates discovery, router initiates 
session" to "both radio and router can support both... or not", the 
consensus seem to be that the DLEP-02 mechanism was sufficient for DLEP 
and is not as error prone.

I expect that in future revisions of DLEP the radio MUST send discovery 
messages via multicast and the router MUST react to them.

> - RFC 5444 or not?

My suggestion would be to postpone this question until the basic 
protocol mechanisms are well defined.

> - what is the version number; what is the distinction between major

At the moment I see no usage for the version number. I would suggest 
dropping it completely.

> - can messages mix optional TLVs with mandatory, reliable TLVs?  Is
> TLV ordering to be enforced? etc.

Yes, mandatory and optional TLVs can be mixed. The order of TLVs is not 
enforced (or at least its not specified).

> I'd suggest that the working group focus first on writing down and
> agreeing upon some requirements and detailed protocol just to cover
> the session state aspects, such that it would be really hard to come
> up with implementations that did not interoperate at that level.
> Then move on to the radio-specific TLVs and issues there.

I agree that making sure that DLEP-conform implementations are also 
interoperable with each other is maybe the most important work. At the 
moment the draft contains a lot of "optional" components and nearly no 
advise how the different possible implementations will interoperate.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 17 Oct 2012 17:16:37 +0000

On Oct 17, 2012, at 8:08 AM, Henning Rogge wrote:

> While the first drafts talked about "transport independence", the consensus has shifted to "UDP" as the standard transport protocol.

Correct. 

> Teco has suggesting using TCP instead of DLEP-specific ACK mechanisms.

I disagree with the approach of using TCP, and jettisoning DLEP-specific ACKs. A protocol with its own ACKS *could* be moved to other transports; otherwise, they (the ACKs) would have to be "reinvented" if/when someone decides to take DLEP from TCP to something else. 

> As far as I understand it, the session is needed for flow control, but would not be needed for pure 'metric delivery' from radio to router. The authors prefer to use a session for both.

The session exists between router and radio. That's the only one. 

> DLEP needs a radio identifier to allow multi-line radios talking over the same Ethernet interface to the router. IP address and port of the radio agent might be okay for this, if the radio agent can run without a well-known port of its own.

Actually, in the -04 draft I'm working on, I've removed the Identification TLV. It's not needed; an implementation can use the UDP 4-tuple (Source address, Source port, Destination address, destination port) to correlate the traffic.

> Currently DLEP-03 contains no sequence number, which only allows for a "stop and wait" delivery of messages (send one, wait for ACK, …).

That was an "Oopsie" on my part. Sequence numbers will re-appear in the -04 version. 

> 
> The exact mechanism how the ACK system will work is not specified, just the messages are in the draft.

I'll attempt to clarify. 

> 
> The ACK messages are marked as "optional", which raises (in my opinion) the question how a sender which expects ACKs works together with a receiver which does not support ACKs.

Another "Oopsie" (well, it's actually a longer story than that, but that story will suffice)… ;-) ACKs are becoming mandatory.
> While DLEP-03 shifted from "Radio initiates discovery, router initiates session" to "both radio and router can support both... or not", the consensus seem to be that the DLEP-02 mechanism was sufficient for DLEP and is not as error prone.

Correct. 

> 
> I expect that in future revisions of DLEP the radio MUST send discovery messages via multicast and the router MUST react to them.

The -04 specifies that the modem-initiated discovery can be sent to *either* the multicast address, or to a unicast address (if the radio already has some a-priori knowledge of the address of a router).

> 
>> - RFC 5444 or not?
> 
> My suggestion would be to postpone this question until the basic protocol mechanisms are well defined.

Hmmm… I consider the issue to be settled, and the answer is "not". At least for this draft. If someone would like to come along behind DLEP and create a "DLEP over 5444" draft...

> At the moment I see no usage for the version number. I would suggest dropping it completely.

Disagree. As we've put in the draft from the get-go, the major-minor versions *MAY* be used by an implementation to determine interoperability - e.g. I'm at version 4, rev 2, you're at version 1, rev 6. Helps to determine whether or net we can participate in useful communication. 

> Yes, mandatory and optional TLVs can be mixed. The order of TLVs is not enforced (or at least its not specified).
> 
> I agree that making sure that DLEP-conform implementations are also interoperable with each other is maybe the most important work. At the moment the draft contains a lot of "optional" components and nearly no advise how the different possible implementations will interoperate.

I would welcome suggested text…

Stan

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 17 Oct 2012 19:26:29 -0700

> radio agent might be okay for this, if the radio agent can run without
> a well-known port of its own.
> 
> Actually, in the -04 draft I'm working on, I've removed the
> Identification TLV. It's not needed; an implementation can use the UDP
> 4-tuple (Source address, Source port, Destination address, destination
> port) to correlate the traffic.

Is it possible to run DLEP over an unnumbered serial link?  What will be the tuple in that case?

Is it possible to run DLEP out-of-band (controlling a radio-router pair on another interface pair)?  If so, how are these interfaces referred to?  What if the data path link is unnumbered serial?

It seems that there is a need to uniquely identify control sessions for the purposes of managing the state pertaining to a data path between radio and router.  The data path may be in band or out of band of the DLEP session traffic.  I'm assuming that one DLEP session corresponds to exactly one data path relationship.  So, it seems like there would need to be two tuples (one for control path, one for data path), and the issue could be complicated by unnumbered links unless such links are out of scope.   

- Tom

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 18 Oct 2012 02:40:14 +0000

> Is it possible to run DLEP over an unnumbered serial link?  What will be the tuple in that case?

Good point. That makes the case for the Identification TLV. Should we keep it?

> Is it possible to run DLEP out-of-band (controlling a radio-router pair on another interface pair)?  If so, how are these interfaces referred to?  What if the data path link is unnumbered serial?

I have seen protocols run "out-of-band". I've even coded it. From a router perspective, it's ridiculously complex. For example, consider a series of VLANs. The DLEP session runs on one VLAN, the "data paths" are on the different VLANS. It required the radio to have knowledge about the VLAN configuration - e.g., metric packets had to basically identify "These metrics are for VLAN x". All in all, the authors made the decision before the initial (non-WG) draft was published to only consider "in-band" management via DLEP. In the long run, it's much simpler. 

> It seems that there is a need to uniquely identify control sessions for the purposes of managing the state pertaining to a data path between radio and router.  The data path may be in band or out o…

See the above response. I don't think "out-of-band" management is a good idea. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 18 Oct 2012 07:50:12 +0200

> Good point. That makes the case for the Identification TLV. Should we keep it?

Unnumbered router interfaces do have IP adresses. Would be "borrowed".
On serial link, there must be a L2 protocol, and a filter for the DLEP messages. The DLEP messages shall not be send over the wireless link.
Question is what L2 protocol is used, and how DLEP can be implemented on this L2 protocol.

As I mentioned earlier, there is a need for a L2 link local, or some smart (IP) filtering on the bridge.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 23 Oct 2012 09:42:02 +0000

(The last comment is Stan, I think before that it is Henning and Thomas Henderson.)

> Hmmm. I consider the issue to be settled, and the answer is "not". At least for this draft. If someone would like to come along behind DLEP and create a "DLEP over 5444" draft...

I'm currently maintaining a strictly neutral position on what should be the case here. But I'm afraid I've seen nothing on the list that looks like a consensus agreement that this is settled. The fact that someone not involved in the discussion then reviewed the discussion and listed this among other items as not settled would support that.

The idea of "DLEP over 5444" as an alternative draft seems poor to me. DLEP as you are specifying it includes message formats. In order for this idea to be meaningful, you'd have to specify DLEP messages in abstract terms, then have alternative formats one based on specialised formats. one based on 5444. And while sketching out two formats in discussion may be an approach, I'm not at all convinced by the idea of drafts defining both - especially in an asymmetric manner as you suggest.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Bo Berry <[email-masked]>
Date: Tue, 23 Oct 2012 07:11:30 -0400

> The idea of "DLEP over 5444" as an alternative draft seems poor to me. DLEP as you are specifying it includes message formats. In order for this idea to be meaningful, you'd have to specify DLEP me…

I agree that one DLEP is/should be adequate.   And I also agree with Stan not to use 5444.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 23 Oct 2012 11:21:51 +0000

Agreeing with Stan that you shouldn't use 5444 is fine. And not all voices are equal, document authors do, and I believe should, have more weight than others. Nevertheless I don't think you've established that there is a consensus against 5444. Tom Henderson's list would support that, and as far as I can see, Tom provided a not so involved up to that point viewpoint. I think at the moment opinions are split between "not 5444" and "let's get to that later", but I wouldn't like to say whether there's a consensus for the former.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Berry
Sent: 23 October 2012 12:12
To: Dearlove, Christopher (UK)
Cc: <[email-masked]>; <[email-masked]>; Stan Ratliff (sratliff)
Subject: Re: [manet] status of components DLEP and consensus on them

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 23 Oct 2012 16:43:43 -0700

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 4:22 AM
> To: Bo Berry
> Cc: <[email-masked]>; Henderson, Thomas R; Stan Ratliff (sratliff)
> Subject: RE: [manet] status of components DLEP and consensus on them
> 
> Agreeing with Stan that you shouldn't use 5444 is fine. And not all
> voices are equal, document authors do, and I believe should, have more
> weight than others. Nevertheless I don't think you've established that
> there is a consensus against 5444. Tom Henderson's list would support
> that, and as far as I can see, Tom provided a not so involved up to
> that point viewpoint. I think at the moment opinions are split between
> "not 5444" and "let's get to that later", but I wouldn't like to say
> whether there's a consensus for the former.
> 

My perception is that there was not WG consensus on this, but that the authors were not convinced to adopt 5444 or a revision of it.  However, the discussion/proposal of using 5444 seems to recur on the list since the question of whether or not it is still an open issue is unclear.  

What I had in mind, from a process standpoint for DLEP, is that a tracker issue would be created, filled in, and closed on this topic, with summary of what was discussed and decided.  If this issue is indeed still open, then it would be helpful to identify the currently available choices and how the issue is planned to be resolved.  

The primary discussion threads on this topic seem to have started at these points in the MANET list earlier this year, with several useful summaries along the way of the alternatives and tradeoffs:

1) http://www.ietf.org/mail-archive/web/manet/current/msg12436.html
2) http://www.ietf.org/mail-archive/web/manet/current/msg12620.html
3) http://www.ietf.org/mail-archive/web/manet/current/msg13104.html
4) http://www.ietf.org/mail-archive/web/manet/current/msg13445.html

I think that the next step would be for the authors and WG chairs to decide whether to start using the tracker (I believe Teco also suggested it earlier this month, and Charlie is using it on the reactive draft) and, if so, how to summarize this issue's status in the tracker.  Then we could try to identify and tackle some others.  I'd be willing to help but not if it will be pushing uphill.

- Tom

p.s.  (to the WG list participants) thank you for improving the DLEP subject lines/threads recently since I commented on it, it has been helpful

---

From: Joseph Macker <[email-masked]>
Date: Tue, 23 Oct 2012 21:20:25 -0400

On Tue, Oct 23, 2012 at 7:43 PM, Henderson, Thomas R <
[email-masked]> wrote:

> My perception is that there was not WG consensus on this, but that the
> authors were not convinced to adopt 5444 or a revision of it.  However, the
> discussion/proposal of using 5444 seems to recur on the list since the
> question of whether or not it is still an open issue is unclear.
>
> What I had in mind, from a process standpoint for DLEP, is that a tracker
> issue would be created, filled in, and closed on this topic, with summary
> of what was discussed and decided.  If this issue is indeed still open,
> then it would be helpful to identify the currently available choices and
> how the issue is planned to be resolved.
>
> The primary discussion threads on this topic seem to have started at these
> points in the MANET list earlier this year, with several useful summaries
> along the way of the alternatives and tradeoffs:
>
> I think that the next step would be for the authors and WG chairs to
> decide whether to start using the tracker (I believe Teco also suggested it
> earlier this month, and Charlie is using it on the reactive draft) and, if
> so, how to summarize this issue's status in the tracker.  Then we could try
> to identify and tackle some others.  I'd be willing to help but not if it
> will be pushing uphill.
>

I think it is important to track these issues better and present
resolutions/decisions if any. I believe using the tracker is a good idea.

>
> - Tom
>
> p.s.  (to the WG list participants) thank you for improving the DLEP
> subject lines/threads recently since I commented on it, it has been helpful