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