Re: [6lowpan] How to find the mailbox? (related to "Advertizeon Behalf")

["Pascal Thubert (pthubert)" <[e-mail]>]

> >> As mentioned yesterday, there is a distinction between Frequently
> >> Listening (a.k.a duty cycled nodes) and what I call call-back
nodes,
> >> i.e. nodes that depend on a router holding a mailbox for that node.
> >> Whether that mailbox feature is provided by any router, a few
> >> specialiezed routers or the border router is a network
implementation
> >> decision.
> >
> > As you point out, there are lots of ways to do this.  No one
solution
> > is going to work for everyone.  At one extreme this can all be
handled
> > by the link layer.  It shouldn't matter to the higher layers if a
> > message is polled for, transmitted according to some known schedule,
> > or unicast immediately.
> >
> > At the other end of the spectrum, it can all be handled at the
> > application layer, with the application polling to some centralized
> > mailbox which may be anywhere.
> >
> > The middle ground, where ND and/or routing get involved, seems
> > dangerous to me, exactly because so many different approaches are
> > possible.
> 
> +1
> 
> Both extremes were represented at the mic yesterday and there were
> certainly concerns with the middle ground approach.  In some cases, I
think it
> will be a combination of both extremes.  The link layer knows best how
to
> contact a duty-cycled node, while the application layer specifies the
policy of
> what to do with packets that experience long communication latencies.
> Having another mechanism in the middle would only add complexity in
> having to combine the particular link layer properties and application
layer
> policies.
> 
+1

Considering only the one-hop problem of sleeping nodes seems to be the
recipe for uncontrolled congestion at - or close to - the sink. What we
really need is a congestion control operation that protects the network,
and that cannot be a one-hop operation.
Sleeping hops introduce latencies that need to be absorbed in outgoing
queues; something constrained devices do not exactly have aplenty.
Selective drops might help by intermediate nodes lack information for
doing that intelligently; in particular, dropping fragments actually
augments the load of the network.

ISA100.11a acknowledges that sleeping periods introduce latencies that
may be unusual in the classical internet, and mandates RFC 2988 for
calculating the retry timer-out interval (RTO). 
ISA100.11a supports ECN, and refers to RFC3168. ECN is always enabled:
it CANNOT be turned off. ECN is set by L2 over the LoWPAN and stamped
into the IPv6 header when HC is uncompressed.
ISA100.11a also tags the packets with a Discard Eligible indication -
mostly for buffered unidirectional publication. This indication is set
by the application for use of the L2 as part of congestion control.
For queued bidirectional communication (R/W, RMI) ISA100.11a is
consistent with the behavior described at the mic above (and Core). Acks
are app layer Acks over UDP, they may carry data, and they are sensitive
to ECN.

What this boils down to is:
- ISA100 has identified a need for congestion control in the LLN. The
congestion control has to be an interaction between the LLN and the
transport/app level. It is unclear how ECN can work with 6LoWPAN
fragments.
- Classical ECN that is designed in conjunction with TCP does not
address properly congestions due to sensor data publication over UDP.
There is a need for an additional mechanism that is not described in
6LoWPAN.

I hope that this can all be addressed in core, though I'm not fully sure
the charter allows that. 
 
Cheers,

Pascal