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

[Stan Ratliff <[e-mail]>]

Charlie,

On Aug 5, 2010, at 4:30 PM, Charles E. Perkins wrote:

> 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?
>
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?
>
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.

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

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

> - 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?
>
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.

> - Is N*2 really long enough in noisy environments
>  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.

> - 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?

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.

>
> - 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.
>
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



> Regards,
> Charlie P.
>
>
>
> On 8/4/2010 10:28 AM, Stan Ratliff wrote:
>> 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
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>