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

["Noriyuki SATO" <[e-mail]>]

+1 
A mailbox mechanism for the sleeping node described in this thread should be
treated in the link layer as Jonathan indicated. The IEEE802.15.4e treats
what low energy mode is enabled, how long duty cycle is etc. and also
current IEEE802.15.4 has mode of operation direct transmission and indirect
transmission. If another L2 protocol addresses sleeping nodes, it should
also address such kind of mechanism in the L2 layer.
But a buffer (aka queue) as implemented in a normal router may be
implemented also in 6LR or 6LBR. Pascal indicated about ECN but we can
implement RED and it can work also for UDP for an easy solution.
I'm not sure the CORE WG is appropriate place to discuss a congestion
control mechanism to solve the issue in LLN since I'm afraid that it should
be discussed some place in transport area.

---
OKI Electric Industry Co., Ltd.
Noriyuki Sato ([e-mail])
Tel [phone]
Fax [phone]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Pascal Thubert (pthubert)
> Sent: Thursday, March 31, 2011 5:29 PM
> To: Jonathan Hui; Richard Kelsey
> Cc: [e-mail]; [e-mail]
> Subject: Re: [6lowpan] How to find the mailbox? (related to"Advertizeon
> Behalf")
> 
> > >> 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
> 
> 
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan