> >> 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 [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
