Subject: [manet] DLEP

From: Stan Ratliff <[email-masked]>
Date: Fri, 3 Jun 2011 12:24:58 -0400

Hello everyone.

The latest version of the DLEP draft -
http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
was posted on May 2. As of this writing, there has been no discussion  
on the mailing list about the 01 version of the draft. Taking the  
optimistic viewpoint that there are no objections, I'll ask the group  
- Can we proceed to WGLC on this document?

Regards,
Stan

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 4 Jun 2011 09:09:50 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stan Ratliff
> Sent: Friday, June 03, 2011 9:25 AM
> To: MANET IETF
> Subject: [manet] DLEP
> 
> Hello everyone.
> 

Stan and all,
Sorry for the delay in reviewing the draft.  I don't think it is ready for WGLC because it doesn't seem complete enough to build interoperable implementations, and at least for the use cases that I'm thinking of applying it to (existing users of RFC 4938, and multi-channel DAMA-based systems), the features don't seem complete enough.

I've previously raised a few initial questions that I think would be worthwhile to try to discuss and come to consensus on.  First, what would be the overall document set necessary for vendors to build interoperable implementations?  Since this document considers transport out of scope, it seems at a minimum that this document plus some kind of transport profile (e.g. "DLEP over UDP") would be the minimum.  I also think that it will be the case that future radio systems will need to extend DLEP; I would like to see the document describe how DLEP is expected to be extended, and explicitly consider extensibility. 

Second, besides TLV specifications, the document defines a basic point-to-point session protocol, but it presently is not specified fully (e.g. no state machine, not much detail in how exceptions are handled).  This sort of protocol must have been done many times before in the IETF (e.g. service discovery, neighbor discovery, DHCP, key management protocols) so I wonder whether the working group should try to define a new one from scratch, or try to find one that is close in functionality and well specified, and either run over that protocol or copy that protocol over as much as possible.

It is not clear to me how it relates to RFC 4938/5578.  I had thought that DLEP was supposed to be a standards-track protocol to replace the (informational) PPPoE-based protocol, but credit-based flow control is left out of this specification.  

The draft is missing a terminology session.  The terms "first-speaker" and "passive-listener" could probably be replaced by "initiator" and "responder" for consistency with other IETF terminology.

The assumptions section should try to clarify some more details about scope of applicability, such as any restrictions on how routers and radios are interconnected that might require loop detection mechanisms, whether DLEP requires both sides (local and remote) to have active sessions (or can be applied only on one side of the link), whether DLEP requires that no reordering occur between router and radio, and whether multicast is handled.

It wasn't clear to me why sequence number 0 needs to be invalid.  It wasn't clear whether the protocol requires (enforces) that sequence numbers be monotonically increasing.

The alignment of the TLVs seems to be on byte boundaries, leading to some odd-length TLVs.  Many recent protocols have tried to align on larger boundaries for implementation convenience, and was wondering what drove you away from the use of any padding (perhaps it was the concept of detached sessions that you introduced later, where over-the-air bandwidth needs to be conserved).

The Router Id and Client Id seem to be used instead as session ids; should they be renamed?  If the intent is really to be router Ids, 4 bytes is not large enough for all routing protocols, so I might suggest 6 bytes, which would allow for use of mac addresses.

It wasn't clear why there is a requirement for major and minor version numbers; I would suggest to remove this unless requirements are clear.  Also, it seems like Version Sub-TLV ought to be mandatory in session initiation messages.

It wasn't clear why the detached peer discovery use case needed to be supported, and if so, whether it places additional requirements on the protocol since the link between router and radio is no longer guaranteed to be highly available.  Suggest to delete this option unless it has clear requirements.

Is specific ordering of TLVs enforced or not?  Also, it is probably sufficient to list the sub-TLVs when messages are specified (e.g. section 9.1) rather than enumerate all of their fields.  

Should the sequence number in Peer Offer message echo the Discovery sequence number, so that the Offer is associated with the right Discovery?

It wasn't clear how the Peer Update procedure would work if the clients ignored the message because they didn't care about the layer 3 addresses.  The router may conclude that the session has failed if it kept retrying the Update that was being ignored at the modem.

There seems to be normative elements of procedure (message sequences) in an Appendix A; suggest to move these to the main body of the specification.  In general, other protocol specifications tend to define message formats and elements of procedure separately, but this draft seems to spread the elements of procedure between the message formats and Appendix A sections.

- Tom

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Jun 2011 10:03:27 +0100

Thomas Henderson wrote:
> The alignment of the TLVs seems to be on byte boundaries,
> leading to some odd-length TLVs.

That is due to using RFC 5444, rather than being introduced by DLEP.
Even if TLV value fields are multiples of 2, 4 or whatever bytes,
the actual start of the value field won't be so constrained.

> Many recent protocols have tried to align on larger boundaries
> for implementation convenience, and was wondering what drove you
> away from the use of any padding (perhaps it was the concept of
> detached sessions that you introduced later, where over-the-air
> bandwidth needs to be conserved).

5444 was created for MANETs, which are most commonly wireless
networks where bandwidth matters. There was creative tension, let's
say, between people who regarded (and may still regard) it as being
able to be made even more efficient, and people who were prepared
to nake things simpler (for more than one definition of simpler)
at the cost of some bytes. (There was also a third axis of
flexibility.) The final result is a compromise in all these regards.

********************************************************************
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: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 6 Jun 2011 21:54:51 -0700

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: Monday, June 06, 2011 2:03 AM
> To: Henderson, Thomas R; Stan Ratliff; MANET IETF
> Subject: RE: [manet] DLEP
> 
> Thomas Henderson wrote:

Thanks for the explanation; I didn't participate in developing 5444 and wasn't aware of that history (and didn't intend to open up any old debates with my question).

- Tom

---

From: "A. Riley Eller" <[email-masked]>
Date: Tue, 28 Jun 2011 11:01:44 -0700

Hello,

I've been on the list for a while and mostly tried to learn from what is being said but, based on increasing experience with military radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? This question has been bouncing around MIT/LL and associated technology development labs. I apologize in advance if my query is in poor form.

My reasoning:
1. DLEP aims to make standard radio to router interfaces (R2RI), a primary value proposition for multi-radio platforms. Even in single-radio platforms, it is the interface standard that would permit component and vendor replacement or upgrade.
2. 7.11 Relative Link Quality value is under-specified and cannot be tested except for nonzero value.
3. 7.9 Latency Sub-TLV is too short to bear deep queuing times.
4. 7.9 does not mandate the latency computation.
5. The EFT method is effective at answering all of these problems, and has been tested by members of this list.

Thank you for your consideration,

A Riley Eller
CoCo Communications 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: Friday, June 03, 2011 9:25 AM
To: MANET IETF
Subject: [manet] DLEP

Hello everyone.

Regards,
Stan
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 28 Jun 2011 22:21:55 -0400

Is there time? Yes, of course. I'm going to show my ignorance here; I  
haven't heard about the EFT method. Can you please give me some  
explanation/background?

Regards,
Stan

On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote:

> Hello,
>
> I've been on the list for a while and mostly tried to learn from  
> what is being said but, based on increasing experience with military  
> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP?  
> This question has been bouncing around MIT/LL and associated  
> technology development labs. I apologize in advance if my query is  
> in poor form.
>
> My reasoning:
> 1. DLEP aims to make standard radio to router interfaces (R2RI), a  
> primary value proposition for multi-radio platforms. Even in single- 
> radio platforms, it is the interface standard that would permit  
> component and vendor replacement or upgrade.
> 5. The EFT method is effective at answering all of these problems,  
> and has been tested by members of this list.
>
>

---

From: "A. Riley Eller" <[email-masked]>
Date: Wed, 29 Jun 2011 10:52:24 -0700

Thank you for the consideration.

Expected Forwarding Time (EFT)[1] represents what I believe to be the state of the art in generating a meaningful cost function for links. The value represents "typical latency between the arrival of a given packet at the transmitting device and that packet's reception at the other end of the link" and so it combines transmission time, idle time, waiting time, freezing time, and queuing time to the degree that those values are meaningful for a given medium. By encompassing the entire packet lifetime, it describes the interaction of transmission rate, packet delivery ratio (in acknowledged, retransmitting links), contention in the local area, router load, and potentially traffic priority. The last of those depends upon whether the metric is computed distinctly for different traffic classes, of course.

It is not panacea, but it is a discrete unit of measure that aggregates well across multiple media. This strength is in opposition to the inutility to software developers of dimensionless RLQ. I have been using a scheme of my own design (which amounts to nothing more than an integer approximation of air time) to good effect for six years, but EFT is better. EFT represents a milestone in both its efficacy and its comprehensibility.

Regards,

Riley

[1] EFT: a high throughput routing metric for IEEE 802.11s wireless mesh networks, Islam et al., 13 March 2009,
 Institut TELECOM and Springer-Verlag 2009

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: Tuesday, June 28, 2011 7:22 PM
To: A. Riley Eller
Cc: MANET IETF
Subject: Re: [manet] DLEP

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 30 Jun 2011 12:40:56 -0400

Riley,

Thank you for the explanation. Just playing devil's advocate here -  
couldn't EFT be expressed as a better, more accurate definition of  
latency?

Regards,
Stan

On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote:

> Expected Forwarding Time (EFT)[1] represents what I believe to be  
> the state of the art in generating a meaningful cost function for  
> links. The value represents "typical latency between the arrival of  
> a given packet at the transmitting device and that packet's  
> reception at the other end of the link" and so it combines  
> transmission time, idle time, waiting time, freezing time, and  
> queuing time to the degree that those values are meaningful for a  
> given medium. By encompassing the entire packet lifetime, it  
> describes the interaction of transmission rate, packet delivery  
> ratio (in acknowledged, retransmitting links), contention in the  
> local area, router load, and potentially traffic priority. The last  
> of those depends upon whether the metric is computed distinctly for  
> different traffic classes, of course.
>
> It is not panacea, but it is a discrete unit of measure that  
> aggregates well across multiple media. This strength is in  
> opposition to the inutility to software developers of dimensionless  
> RLQ. I have been using a scheme of my own design (which amounts to  
> nothing more than an integer approximation of air time) to good  
> effect for six years, but EFT is better. EFT represents a milestone  
> in both its efficacy and its comprehensibility.
>
> Regards,
>
> Riley
>
>
> [1] EFT: a high throughput routing metric for IEEE 802.11s wireless  
> mesh networks, Islam et al., 13 March 2009,

---

From: "A. Riley Eller" <[email-masked]>
Date: Thu, 30 Jun 2011 10:14:25 -0700

Stan,

"You can call me anything, just don't call me late for dinner." -- my pops

I'm not much of a semanticist, so I'll defer to the group's ideas about naming, but in the spirit of advocacy: "Latency" is easy to understand and has a lot of background context that EFT does not share. The latter is, at best, comprehensible only if you sound it out. That suggests to me that a reader would pay better attention to the more specific term and not be tempted to "plug in" an existing one- or two-way link latency metric. So by virtue of being precise, my hunch is that EFT is a better name.

I must admit that my scientific training is weak in temporal matters, so I cannot be an arbiter of whether a "queuing delay" and "transmission delay" should be expressed in the same terms as a "congestion back-off timer". It seems to me, though, that latency should be used in tightly-coupled processes (like phase-lock loops latent by the distance over the speed of light) and duration should be used in loosely-coupled processes like timer events. So in some senses, I might say, forwarding time is latencies plus durations.

In the pursuit of standardization, also, EFT is a formulation that might be better specified rather than left to implementers. In the exchange of messages across a component architecture, I believe that Latency might lose sufficient context to be mistaken for one- or two-way link latency or any similar term.

My preference sort would be:
1) Specify EFT instead of Latency in 7.9
2) Specify EFT as 7.x in addition to 7.9
3) Specify EFT as the MUST for 7.9
4) Suggest EFT as a MAY for 7.9

Do those ideas make sense?

Again thank you for the consideration,

Riley

-----Original Message-----
From: Stan Ratliff [mailto:[email-masked]] 
Sent: Thursday, June 30, 2011 9:41 AM
To: A. Riley Eller
Cc: MANET IETF
Subject: Re: [manet] DLEP

Riley,

Regards,
Stan

---

From: Joe Macker <[email-masked]>
Date: Thu, 30 Jun 2011 13:53:46 -0400

At first glance its seems like some sort of stochastic measure of expected latency. 
Is that essential what it is?
Can you sketch out the TLV content desires and post it?

On Jun 30, 2011, at 12:40 PM, Stan Ratliff wrote:

> Riley,
> 
> Thank you for the explanation. Just playing devil's advocate here - couldn't EFT be expressed as a better, more accurate definition of latency?
> 
> Regards,
> Stan
> 
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 30 Jun 2011 15:08:57 -0400

Riley,

:-) Your father & mine share the same sayings...

Your point makes sense. I'll try to lift the ETF description from the  
reference and include it in the next rev of the DLEP document. If you  
have some suggested text to describe EFT, that would be great.

Regards,
Stan

On Jun 30, 2011, at 1:14 PM, A. Riley Eller wrote:

> I'm not much of a semanticist, so I'll defer to the group's ideas  
> about naming, but in the spirit of advocacy: "Latency" is easy to  
> understand and has a lot of background context that EFT does not  
> share. The latter is, at best, comprehensible only if you sound it  
> out. That suggests to me that a reader would pay better attention to  
> the more specific term and not be tempted to "plug in" an existing  
> one- or two-way link latency metric. So by virtue of being precise,  
> my hunch is that EFT is a better name.
>
> I must admit that my scientific training is weak in temporal  
> matters, so I cannot be an arbiter of whether a "queuing delay" and  
> "transmission delay" should be expressed in the same terms as a  
> "congestion back-off timer". It seems to me, though, that latency  
> should be used in tightly-coupled processes (like phase-lock loops  
> latent by the distance over the speed of light) and duration should  
> be used in loosely-coupled processes like timer events. So in some  
> senses, I might say, forwarding time is latencies plus durations.
>
> In the pursuit of standardization, also, EFT is a formulation that  
> might be better specified rather than left to implementers. In the  
> exchange of messages across a component architecture, I believe that  
> Latency might lose sufficient context to be mistaken for one- or two- 
> way link latency or any similar term.
>

---

From: "A. Riley Eller" <[email-masked]>
Date: Thu, 30 Jun 2011 13:17:22 -0700

Dennis Edwards, the co-author of the Air Time metric I mentioned, reminds me that all we're talking about is using the best available mechanism to measure latency. So with his admonishment in mind, here's my attempt at a draft text. Stan will surely note that it resembles the Latency Sub-TLV, although I took the liberty of pushing toward a microsecond based representation. Millisecond accuracy is technically sufficient, but I believe that the additional bits can be used to improve mobility in CSMA-style media. Please feel free to replace (us) with (ms) if the group prefers, and in that case shrink the encoding to 2 octets.

7.X  Expected Forwarding Time (EFT) Sub-TLV

   The EFT Sub-TLV is used in Neighbor Up, Neighbor Update, Link 
   Characteristics Request, and Link Characteristics ACK messages to 
   indicate the expected forwarding time on the link, or in the case 
   of the Link Characteristics Request, to indicate the maximum 
   packet holding time (e.g. a should-not-exeed value) on the link. 

   The EFT Sub-TLV contains the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length = 4     |EFT     (us)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Expected Forwarding Time (us)                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type              -  TBD

   TLV Flags             -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not used and MUST be set to '0'.

   Length                -  2

   Expected Forwarding   -  the transmission delay that a packet
   Time                     encounters as it is transmitted over the
                            link. In Neighbor Up, Neighbor Update, 
                            and Link Characteristics ACK, this value
                            is reported in expected delay, in 
                            microseconds. The calculation of 
                            forwarding time is modem-device dependent, 
                            but SHOULD represent the sum of all 
                            latencies due to queuing, transmission,
                            retransmission, idle, and freezing times.
                            For example, the queuing time may be a 
                            running average calculated from the 
                            internal queuing and the freezing time may
                            be a running average of media acquisition
                            time. If the modem device cannot calculate 
                            expected forwarding time it MUST be 
                            reported as 0. In the Link Characteristics 
                            Request Message, this value represents the 
                            maximum acceptance holding time, in 
                            microseconds, expected on the link.