Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

[Robert Cragie <[e-mail]>]

Hi Jonathan,

Comments inline.

Robert

On 28 July 2015 at 18:08, Jonathan Hui <[e-mail]> wrote:

> Having the "page switch" markers effectively increases the Dispatch space
> to 2 octets or more, with a compression mechanism that allows consecutive
> headers from the same page to elide the the first octet.  In the limit, if
> I wanted to keep switching between the two spaces, then I incur one byte
> overhead for each header.  Though, I agree that is a fairly contrived case.
>

<RCC>There is also the uncompressed/stateless case where you have to
qualify every dispatch code with an associated page code, which becomes
more like an escape code (ESC). The idea of a switch and subsequently
remembering the page code is perfectly logical from a parsing perspective
as state is implied in parsing anyway, so the stateless case (whereby you
lose state at the end of processing every dispatch code) seems somewhat
wasteful.</RCC>

>
> Currently, we are going down a path where every 6LoWPAN network in
> existence needs to respect the same header identifiers (i.e. Dispatch
> values) at all times.  It's not obvious to me that this is a good idea.
>
> For example, two devices in the field could easily determine what headers
> are actually in use and the corresponding header identifiers.  In one view,
> this is not much different than establishing 6LoWPAN contexts.  A 6LoWPAN
> network already determines what prefixes are in use and binds short forms
> (4-bit Context IDs) to those.  If there is ever any confusion on how those
> 4-bit Context IDs are assigned, then things will fail.  Typically, we
> expect to use IEEE 802.15.4 security mechanisms to isolate networks.  After
> devices establish a secure link, there is no need to worry about processing
> packets that not a part of that secure link.  We could apply the same logic
> to Dispatch values and forgo the overhead of "page switch" markers.
>

<RCC>That is true, but we already discussed this and tried this to some
extent with the repurposing of the mesh header. That isn't defining a whole
new set of codes for a new technology but is tantamount to it. It didn't
seem to go down well, hence the idea of page codes/markers.</RCC>

>
> As a side note, strictly speaking, RFC 4944 was defined for IEEE
> 802.15.4-2003 and RFC 6282 defined for IEEE 802.15.4-2006.  In theory, we
> could easily define a new Dispatch mechanism for TSCH (IEEE
> 802.15.4e-2012).  The frames are distinguishable using the IEEE 802.15.4
> Frame Version field.
>

<RCC>Indeed we could. Perhaps a wholesale change might actually be more
palatable than just repurposing some of the dispatch code space?</RCC>