Subject: [manet] draft-sratliff-dlep-00

From: Stan Ratliff <[email-masked]>
Date: Wed, 4 Aug 2010 13:28:00 -0400

Was submitted on Aug 2 and is on the ietf site at
https://datatracker.ietf.org/doc/draft-sratliff-dlep/

One difference from what was presented in Maastricht:  Authentication  
has been removed from the draft. There was an off-list discussion  
about handling authentication within the context of the packetbb-sec  
draft; that seems like a better approach than handling it inside of  
DLEP.

Regards,
Stan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Aug 2010 13:30:43 -0700

Hello Stan,

I've read the draft.  I have some minor editorial
nits I'll send separately.  Some comments/questions:

- My reading is that a "session" is between
   a router and a modem, and that a "neighbor" is
   some node reachable on the "other side" of the
   modem.   I reckon that "neighbors" do not have
   sessions with the router.  Is this correct?

- Presumably it's better for DLEP to enable bridging
   to neighbors, but it would be almost the same if
   DLEP established modems as next hops towards the
   neighbors.  Then, would DLEP count as a
   "mini routing protocol"?  Could you explain
   why that would be a bad idea?

- I reckon the Bandwidth Request Message field
   descriptions are wrong.  What is "Request DR"?

- Does the distinction between a client and a client
   proxy have any effect on the protocol?  Is it the
   case that _all_ "remote clients" are associated
   with a client proxy?

- Is N*2 really long enough in noisy environments
   for the heartbeat timeout?

- It's not clear why the session model is important
   for the operation of the protocol.  What state is
   established for the maintenance of the session?
   Does it just mean that a heartbeat should be
   expected?

- In the introduction:

>             Fluctuations in speed and quality of these links can
>    occur    ...    on a
>    moment-to-moment basis, due to physical phenomena like multipath
>    interference, obstructions, rain fade, etc.

    Is it intended that DLEP should deal with such
    fluctuations?  I guess it's "best effort", but in
    some cases I could imagine bursts of control traffic
    when data is struggling to be transmitted correctly.

Regards,
Charlie P.

On 8/4/2010 10:28 AM, Stan Ratliff wrote:
> One difference from what was presented in Maastricht: Authentication has
> been removed from the draft. There was an off-list discussion about
> handling authentication within the context of the packetbb-sec draft;
> that seems like a better approach than handling it inside of DLEP.
>
> Regards,
> Stan
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 5 Aug 2010 17:16:44 -0400

Charlie,

>  sessions with the router.  Is this correct?
Correct.

>  why that would be a bad idea?
Well, if DLEP were going to be a "mini routing protocol",
it would seem easier just to put this kind of functionality
(e.g. better sensitivity to like metrics and link-level
awareness to neighbor comings & goings) directly into
a protocol like OLSR, no? And then put it into DYMO,
and etc, etc etc.

We've been of the notion to "let routers be routers and
radios be radios". Our thinking is that enabling an event-
based paradigm for presence and absence of neighbors,
as well as for link fluctuations, is more scalable, while
allowing the functional separation between routers &
radios to let each evolve at its own pace.

>  descriptions are wrong.  What is "Request DR"?

Sorry about that. In that context, DR = DataRate.

>  case that _all_ "remote clients" are associated
No, there's really no effect on the protocol. The distinction
was introduced to cover the case where one end of a link
has a DLEP-enabled modem, but the other does not. Since
UDP is a viable transport for RFC 5444, we envisioned a
case where the DLEP-enabled modem might want to act
as a remote for non-DLEP side, using the radio link to
communicate the necessary information. However, carrying
that forward to a case where both sides of the link are DLEP-
enabled, a router may want to prefer the local modem over
the remote one, hence the distinction.

>  for the heartbeat timeout?
Our initial thought was that it was, but if a longer window
would be better, then we can certainly change that.

>  Does it just mean that a heartbeat should be

Our implementation drives a finite state machine off of
the router-to-radio session establishment. We expect
heartbeat messages, as well as the "Neighbor" messages.
Any neighbor message received prior to the session
establishment (e.g. Neighbor up) is something we flush.

>   when data is struggling to be transmitted correctly.
Yes, you'll still encounter situations where the traffic is either  
sufficiently
bursty, or the link is fluctuating so fast (or both) that stations will
struggle to transmit correctly. But in a lot of cases (to be honest,  
most
of the cases we've seen), the link metrics can be sent quickly enough to
help the router adjust to the change.

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 10 Aug 2010 12:21:18 -0700

Substantive comments:
- I would like to see this draft advance in the WG.

- My perception is that this is less a protocol and more a series of packet formats, except for a fairly loose description of behavior in Section 3. Do you envision any required behaviors associated with receipt of these packets/messages, e.g. Peer Discovery MUST be answered with Peer Offer, retransmission standards for unacknowledged bandwidth requests, etc?

- The "bandwidth request" message is a huge step forward, but there are many more policy knobs that we should build into this. For example:
	o latency requests, which can be honored in a TDMA system or when 
	  radios are reporting metrics about a MANET where they can change hop
	  counts
	o priority scores associated with requests, that would allow radios to
	  deconflict mutually unsupportable requests
	o This would be much harder to design, but if routers could request
	  that clients acquire particular nodes as neighbors, that would be a
	  boon to directional systems that have limited numbers of links but
        many potential neighbors.

My nits on this draft:

- Section 1, bottom of page 2: "In the case of Ethernet or 
   serial attachment, with existing protocols and techniques, routing
   software cannot be aware of convergence events occurring on the
   radio link..." 

Is this true, given the existence of PPPoE (RFC 5578)?

- Section 7.1: I think it's unclear what the client and router roles are for the "dead interval". Is the sequence that the client proposes a dead interval in the Peer Discovery message and then it is acknowledged by the router in the Peer Offer? Or can the Peer Offer propose a different one, and if so how is this adjudicated?

- Section 7.8: I think we'd better off reprinting the norms from RFC 5578 rather than simply referring to it, e.g. "the latency may be a running average calculated from the internal queueing."

- Section 7.8-7.10: Data rate is limited to 4.2 Gbps, which is a lot, but we're not that far away from systems that can deliver that order of throughput.  5578 had a "credit scaling" TLV and perhaps this draft could do with one.

Martin

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 10 Aug 2010 19:26:02 -0400

Martin,
On Aug 10, 2010, at 3:21 PM, Duke, Martin wrote:

> - My perception is that this is less a protocol and more a series of  
> packet formats, except for a fairly loose description of behavior in  
> Section 3. Do you envision any required behaviors associated with  
> receipt of these packets/messages, e.g. Peer Discovery MUST be  
> answered with Peer Offer, retransmission standards for  
> unacknowledged bandwidth requests, etc?
>
Yes, what we're thinking is that the Peer Offer is an explicit  
response to the Peer Discovery. In terms of the Bandwidth request, we  
envisioned that the response would be a link metric packet. Having  
said that, if the consensus opinion is that there needs to be a  
specific response to a Bandwidth request, we're amenable to that.

> - The "bandwidth request" message is a huge step forward, but there  
> are many more policy knobs that we should build into this. For  
> example:
We can most definitely look at making additions to the Bandwidth  
Request packet. Can you point me at some description of a TDMA system  
that can honor a latency request? To be honest, I haven't dealt with  
one. As for the priority scoring and the specific neighbor request,  
that sounds interesting as well. Can you give the list some additional  
detail of how that would work?

> Is this true, given the existence of PPPoE (RFC 5578)?

... you are correct. If someone is implementing RFC 5578, then you can  
get the feedback. What I should have said is something along the lines  
of "unless an implementation is using RFC 5578, routing software  
cannot be aware...". I'll make a change to the next revision of the  
draft.

> - Section 7.1: I think it's unclear what the client and router roles  
> are for the "dead interval". Is the sequence that the client  
> proposes a dead interval in the Peer Discovery message and then it  
> is acknowledged by the router in the Peer Offer? Or can the Peer  
> Offer propose a different one, and if so how is this adjudicated?
>
The intent was that the client would propose a Dead Interval, and the  
router would either accept it (mirroring it in the Peer Offer), or  
fail to establish session. I'll clarify in the next version.

> - Section 7.8: I think we'd better off reprinting the norms from RFC  
> 5578 rather than simply referring to it, e.g. "the latency may be a  
> running average calculated from the internal queueing."
>
OK, I'll put some more of the RFC 5578 text into the next version.

> - Section 7.8-7.10: Data rate is limited to 4.2 Gbps, which is a  
> lot, but we're not that far away from systems that can deliver that  
> order of throughput.  5578 had a "credit scaling" TLV and perhaps  
> this draft could do with one.
>
I'm OK with re-introducing the scaling factor into the metrics and  
Bandwidth request packets. Are there other opinions on the list?

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Tue, 10 Aug 2010 17:06:21 -0700

Stan,

Responses inline: 

>	Yes, what we're thinking is that the Peer Offer is an explicit response > to the Peer Discovery. In terms of the Bandwidth request, we envisioned 
> that the response would be a link metric packet. Having said that, if the 
> consensus opinion is that there needs to be a specific response to a 
> Bandwidth request, we're amenable to that. 

Well now I'm confused, since the draft has a "Bandwidth Request ACK" message type and TLV. But the broader point is that I think there are some implied behaviors here that should at least be explicit SHOULDs, if not MUSTs.

> We can most definitely look at making additions to the Bandwidth Request   > packet. Can you point me at some description of a TDMA system that can 
> honor a latency request? To be honest, I haven't dealt with one. As for the > priority scoring and the specific neighbor request, that sounds interesting 
> as well. Can you give the list some additional detail of how that would 
> work? 

I'm skirting around some IP issues here, but there's a certain defense contractor (not Boeing) that is shortening per-hop latency by allocating more than one slot per TDMA link, spread out uniformly over the frame. And of course, in the queueing domain you can improve latency by increasing throughput.

For priority scoring, a router could attach to each request a 4-bit priority value, which ultimately would be driven by some network manager somewhere. If the radio has two mutually unsupportable requirements, it would choose to honor the one with the higher priority value.

For specific neighbor requests, as I said it's much harder to design, but routers could request links to specific neighbors, and the radio could report back if they're reachable, or go out and form the link. For example, a free-space-optic system could be targeted at any one of a number of targets, but only one. There might have to be radio-specific fields providing things like location. There's a lot to this and it may be a bridge too far for this spec, but if others out there are interested in this capability we could figure something out.

That brings up a more philosophical issue, which is whether you envision networks of radios running their own MANETs and then reporting to the router connectivity to all the nodes in the MANET, even some that are several physical hops away. In my experience this is something of a religious issue, but if you do allow this paradigm then there are things you can do to modify the topology to reduce hop count.

Martin

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 10 Aug 2010 20:37:35 -0400

Martin,
On Aug 10, 2010, at 8:06 PM, Duke, Martin wrote:

>> response > to the Peer Discovery. In terms of the Bandwidth  
>> request, we envisioned
> Well now I'm confused, since the draft has a "Bandwidth Request ACK"  
> message type and TLV. But the broader point is that I think there  
> are some implied behaviors here that should at least be explicit  
> SHOULDs, if not MUSTs.
>

My apologies for the confusion. Pressed the enter key before proof- 
reading.... (blush). You're correct, the Bandwidth Request ACK is the  
response to the Bandwidth Request. And your broader point is taken. We  
will attempt to firm-up the implied behavior in the draft.

>> Request   > packet. Can you point me at some description of a TDMA  
>> system that can
>> honor a latency request? To be honest, I haven't dealt with one. As  
>> for the > priority scoring and the specific neighbor request, that  
>> sounds interesting
> I'm skirting around some IP issues here, but there's a certain  
> defense contractor (not Boeing) that is shortening per-hop latency  
> by allocating more than one slot per TDMA link, spread out uniformly  
> over the frame. And of course, in the queueing domain you can  
> improve latency by increasing throughput.
>
In that case, wouldn't the bandwidth request as it currently stands  
cause the allocation of the additional time-slots? Don't get me wrong  
- I'm not opposed to adding a latency request mechanism into the  
draft. What I'm grappling with is how modem devices would use it.

> For priority scoring, a router could attach to each request a 4-bit  
> priority value, which ultimately would be driven by some network  
> manager somewhere. If the radio has two mutually unsupportable  
> requirements, it would choose to honor the one with the higher  
> priority value.
>
> For specific neighbor requests, as I said it's much harder to  
> design, but routers could request links to specific neighbors, and  
> the radio could report back if they're reachable, or go out and form  
> the link. For example, a free-space-optic system could be targeted  
> at any one of a number of targets, but only one. There might have to  
> be radio-specific fields providing things like location. There's a  
> lot to this and it may be a bridge too far for this spec, but if  
> others out there are interested in this capability we could figure  
> something out.
>
> That brings up a more philosophical issue, which is whether you  
> envision networks of radios running their own MANETs and then  
> reporting to the router connectivity to all the nodes in the MANET,  
> even some that are several physical hops away. In my experience this  
> is something of a religious issue, but if you do allow this paradigm  
> then there are things you can do to modify the topology to reduce  
> hop count.
>

I can see the DLEP protocol being used in a Layer 2 multi-hop  
deployment, as well as a single-hop. As it stands, it would depend on  
what the modem device reports to the router.

Regards,
Stan

---

From: "Duke, Martin" <[email-masked]>
Date: Wed, 11 Aug 2010 11:34:04 -0700

Stan, 

> >
> In that case, wouldn't the bandwidth request as it currently 
> stands cause the allocation of the additional time-slots? 
> Don't get me wrong
> - I'm not opposed to adding a latency request mechanism into 
> the draft. What I'm grappling with is how modem devices would use it.
> 

Not really. The router may not need the bandwidth, just latency, so it'd be difficult for the router to compute what bandwidth request would be needed to generate any particular latency. Also, a bandwidth request for 2 slots worth of data with no latency requirement may very well be satisfied with 2 adjacent slots rather than two spread over the frame.

Furthermore, if you allow for multihop MANETs to be abstracted using DLEP, as you suggested is the case, that opens up several more degrees of freedom for how the radio can attempt to tackle a latency requirement.

This discussion brings up another point, do we want to communicate radio ability through a means other than the string exchange? It would be nice to on session initiation indicate what TLVs/messages the radio can support.

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 11 Aug 2010 14:58:03 -0400

On Aug 11, 2010, at 2:34 PM, Duke, Martin wrote:

> Not really. The router may not need the bandwidth, just latency, so  
> it'd be difficult for the router to compute what bandwidth request  
> would be needed to generate any particular latency. Also, a  
> bandwidth request for 2 slots worth of data with no latency  
> requirement may very well be satisfied with 2 adjacent slots rather  
> than two spread over the frame.
>
OK. So, is the proposal to add a Latency Request packet? Or to modify  
the Bandwidth request to (for lack of a better term) a Link  
Characteristics request and add a request for latency?

> Furthermore, if you allow for multihop MANETs to be abstracted using  
> DLEP, as you suggested is the case, that opens up several more  
> degrees of freedom for how the radio can attempt to tackle a latency  
> requirement.
>
> This discussion brings up another point, do we want to communicate  
> radio ability through a means other than the string exchange? It  
> would be nice to on session initiation indicate what TLVs/messages  
> the radio can support.
>

We were trying to handle TLV support via the "Version Level" TLV  
(implicitly tying what TLV's were or weren't supported to a version of  
the protocol). We can investigate another mechanism, but a version  
exchange seems pretty straightforward.

Regards,
Stan

---

From: Bo Berry <[email-masked]>
Date: Thu, 12 Aug 2010 08:17:31 -0400

in-line comments
-Bo

On Aug 11, 2010, at 2:58 PM, Stan Ratliff wrote:

> OK. So, is the proposal to add a Latency Request packet? Or to modify the Bandwidth request to (for lack of a better term) a Link Characteristics request and add a request for latency?
> 

Would it be useful to separate the metric values into individual TLVs to allow reuse in multiple messages?

An additional benefit is the radio could send only the metrics that changed from the previous report. This  does imply that the radio sends all metrics in the initial report and the router keeps and updates the cache with individual metric reports that follow.

This brings up another thought for the community, allowing basic TLV formats?  RFC5444 defines all TLVs with the <flags> field. In some cases the <flags> field can be eliminated by using the basic TLV format. In the context of separating the metrics, using basic TLV formats would save 5-bytes of overhead from the TLV block for each message bundled w/in a packet.  

T-F-L-<RLQ> 
T-F-L-<Resources> 
T-F-L-<Latency> 
T-F-L-<CDR> 
T-F-L-<MDR> 

T-L-<RLQ> 
T-L-<Resources> 
T-L-<Latency> 
T-L-<CDR> 
T-L-<MDR> 

Thoughts from the community

> We were trying to handle TLV support via the "Version Level" TLV (implicitly tying what TLV's were or weren't supported to a version of the protocol). We can investigate another mechanism, but a version exchange seems pretty straightforward. 
> 
> Regards,
> Stan
> 
> 

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: "Duke, Martin" <[email-masked]>
Date: Thu, 12 Aug 2010 11:22:01 -0700

Stan,

I'm pretty flexible as to how it's accomplished as long as the capability is there, but in my view the easiest way to structure things is to change the "Bandwidth request message" and "bandwidth request ack message" become "metric request" and "metric request ack" messages, and then have different TLV pairs for each metric. At this point, we've come up with bandwidth and latency, but perhaps more will emerge.

Martin

________________________________
From: Stan Ratliff [mailto:[email-masked]]
Sent: Wednesday, August 11, 2010 11:58 AM
To: Duke, Martin
Cc: MANET IETF
Subject: Re: [manet] draft-sratliff-dlep-00

Stan,

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 12 Aug 2010 14:35:16 -0400

Martin,

OK, will do.

Regards,
Stan

On Aug 12, 2010, at 2:22 PM, Duke, Martin wrote:

> Stan,
>
> I'm pretty flexible as to how it's accomplished as long as the  
> capability is there, but in my view the easiest way to structure  
> things is to change the "Bandwidth request message" and "bandwidth  
> request ack message" become "metric request" and "metric request  
> ack" messages, and then have different TLV pairs for each metric. At  
> this point, we've come up with bandwidth and latency, but perhaps  
> more will emerge.
>
> Martin
>
> OK. So, is the proposal to add a Latency Request packet? Or to  
> modify the Bandwidth request to (for lack of a better term) a Link