[6lo] 6lo packet expiration time draft discussion; request for WG adoption

[Charlie Perkins <[e-mail]>]

Hello folks,

I would like to discuss the points raised during the recent IETF 99 
meeting in Prague.  It seems to me that the draft is ready now for 
adoption by the working group.

Below, I have extracted the relevant part of the minutes for easier 
follow-up:

 > Packet Expiration Time in 6lo Routing Header Charlie Perkins 10 min
 > https://www.ietf.org/id/draft-lijo-6lo-expiration-time-03
 > * This is about communicating delivery deadline time in 6LoWPAN 
networks. Allows dropping
 > packet if too late, and measuring transit time in network.
 > * Since last revision, added ASN as possible time unit.
 > * Name of draft says "expiration", should become "deadline"


We would do this if the document is adopted as a WG document.


 > * Charlie shows format
 > * Pascal: supportive of this. You should drop as soon as you know the 
packet won't make it.
 > Requires to know transit time of remaining part of the rest of the 
path. With source routing, Root could
 > compute intermediate deadlines at each hop.
 > * Charlie: would love to have this fine-grained level of planning, 
not sure real networks can do this.
 > Is it worth the added complexity?
 > * OpenWSN implemented an EDF (Earliest Deadline First) policy based 
on this.
 > * Kerry Lynn: back to Pascal's question. Not all hops have same 
"cost" (transit time). Where is time
 > spent? propagation, queuing, ...?


At an intermediate node, it will be hard to predict/compute the 
remaining time for each hop because of wireless conditions, queuing 
delays, etc.  Simply computing the remaining time divided by number of 
hops seems unlikely to provide a useful solution. The actual numbers for 
the per-hop delay are time-varying on a timescale that can be short 
compared to the lifetime of the flow. So I would definitely not want to 
tackle that question as part of this draft.  Conditions that matter for 
the purpose of longer timescales could be handled by purpose-built 
objective functions. That's definitely out of scope for our draft.


 > * Charlie: just want have a deadline so know it's too late.
 > * Thomas: to Kerry's question: depends on technology. In 6TiSCH, 
transit time is mostly queing,
 > waiting for the next slot
 > * Kerry: ?
 > * Charlie: ?
 > * Samita: About time synch mechanism/protocol, any recommendation?

In a wireless network based on IEEE802.15.4-2015, TSCH provides time 
synchronization; RFC 7554 provides some useful information about this 
mode of synchronization.  In scenarios where a packet is routed over an 
IPv6 external network, a synchronization mechanism has been recommended 
by IEEE802.1 AS.  This solution has also been cited in the Detnet 
problem-statement <draft-ietf-detnet-problem-statement>.   I think it 
will be sufficient for us to mention these two documents in the next 
revision.


 > * Charlie: will post on the mailing list, and add text in the draft
 > * Thomas: time synch, can answer on our implementation. 100us. In 
commercial implemenation,
 > 10-15us. But not related to this draft.
 > * Charlie: could insert words of caution in the draft that operating 
on timestamps may provide
 > misleading results
 > * Gabriel: if D bit set, text says SHOULD drop. Anything bad can 
happen if implementation does not
 > obey SHOULD? Then maybe turn it into MUST
 > * Thomas: Recommend to put MUST.

I am semi-O.K. with MUST, but I still think that SHOULD is better.

 > * Pascal: This header is optional to process.
 > * Suresh: can say MUST, but sender cannot expect it to be observed if 
intermediate router does not
 > implement this.
 > * Pascal: application cannot rely that packet will *not* be delivered 
after deadline. On;y use it as
 > "discard preferably to other packets" after deadline.

This seems to go against a previous discussion in favor of using MUST.

 > * Peter VDS: if network and application is actually real time, will 
make sure this draft is
 > implemented in all routers and make this a MUST.

The packet would typically be dropped in such networks even if SHOULD, 
and SHOULD does not necessarily detract from enabling real time.

 > * Gabriel: will continue this discussion on mailing list and call for 
adoption after that.

Yes, I would like to request WG adoption of this draft.

Regards,
Charlie P.