Subject: [6lo] To ESC or not to ESC

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 10:06:05 +0200

(Resending, as a message without a subject is unlikely to reach everyone.)

Grüße, Carsten

On 21 Apr 2015 at 09:28:09, Robert Cragie ([email-masked]
<mailto:[email-masked]>) wrote:
> Hi Carsten, 
>
> ESC is still one way of doing it. 

ESC is defined as a way to get more dispatch code points once the first
192 are finished up.

We are not there yet, so ESC does not enter the picture.

> As Pascal points out, it is simply a 
> way of defining another 256 code points which can be used for dispatch 
> or header at the expense of having to include an extra byte 

Yes, we will have to allocate one or more dispatch code points, which
are then followed by additional header bits if we can’t get a large
enough space.  But that’s true for everything we do at the dispatch level.

> (I also 
> don't get the "127" text in RFC 4944; as James points out, that is 
> probably an error). ESC was probably defined as a simple "get out of 
> jail free" card to make sure there was always going to be a way of 
> expanding the dispatch codes. 

Yes, that is its point.

It’s not being used here.

> Sure it could have been done much more 
> efficiently but hindsight is a wonderful thing. So it isn't "reserved 
> for future use" as it is explicit (if not precise) about its meaning. 
>
> The proposal is to use ESC as a "switch" to mean "the subsequent codes 
> are not those in RFC4944 or RFC6282". What that means is that we 
> probably have to have a "through the looking glass" set of dispatch 
> codes which: 
>
> * Retain IPHC, FRAG1 and FRAGN as the most commonly used dispatch codes 

Why would I use an ESC-like mechanism for these?  They work without such
a mechanism.

> * Reserve the codes where NALP, IPv6, LOWPAN_HC1 and LOWPAN_BC0 as these 
> would no longer be used 

All codes from ESC-0 to ESC-255 are already waiting for allocation.  No
need to reserve anything.

> * Replace MESH with 6LoRH 

Why would I want to waste two more bits?

I understand the appeal to use something like an ESC-like mechanism for
this:  We could then simply say “ignore that you should be sending
ESC-like for this deployment”, doing the Mesh Header Renovation through
the back door.  But that is exactly the same as saying “reinterpret
11xxxxxx for this deployment”, except that it causes a giant confusion,
as if there were some mechanism there that isn’t.  And we would need to
allocate a new code for the purposes ESC is allocated for.  We might as
well allocate the new code for this new thing!

Actually, if we don’t do the Mesh Header renovation, then we should be
allocating an appropriate number of dispatch codes for the RH/New Mesh
Header/whatever we call it.

01 000100 through 01 001111reserved for future use

01 010001 through 01 011111reserved for future use

11 001000 through 11 011111reserved for future use

11 101000 through 11 111111reserved for future use

75 codes waiting to be allocated.

It should be easily justifiable to get three bits out of the dispatch
code by allocating eight of these (~ 10 %); four bits (~ 20 %) might be
stretching it (but might be appropriate if there is a good allocation
structure within the new structure).  In particular if we can hope to
get the unused part of the old MH space back.

Look, Ma, no ESC.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Apr 2015 08:47:02 +0000

Hello Carsten:

Apparently you have not yet looked at the draft in the bitbucket.

- Solution 1 is renovation of MH
- Solution 2 places one (only one) escape - I used ESC of 01000000 since at least that was a use for it - and after that, use the MH renovation as above. Confusion with original MH is eliminated. But that's ugly for a number of reasons, including as you point out, same codes as MH for different things, and the factorization we talked about before.
- Solution 3 is my attempt to answer you earlier mail, which you seem to be pushing again. In solution 3 I'm proposing to use 11 11xxxx for elective and 1101xxxx for critical.

This is all in the draft. 

The big trouble with the FRAG1 and FRAGN is that they end up fragmenting the dispatch space itself. Apart from being premature,  ESC was already making that mistake and good thing it was not used yet so we could move it. But Fragments... damn Grrrr.

Cheers,

Pascal

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: mardi 21 avril 2015 10:06
> To: James Woodyatt; [email-masked]; Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Subject: To ESC or not to ESC
> 
> Yes, we will have to allocate one or more dispatch code points, which are then
> followed by additional header bits if we can’t get a large enough space.  But
> that’s true for everything we do at the dispatch level.
> 
> > (I also
> > Sure it could have been done much more efficiently but hindsight is a
> > wonderful thing. So it isn't "reserved for future use" as it is
> > explicit (if not precise) about its meaning.
> >
> Why would I use an ESC-like mechanism for these?  They work without such a
> mechanism.
> 
> > * Reserve the codes where NALP, IPv6, LOWPAN_HC1 and LOWPAN_BC0 as
> > these would no longer be used
> 
> All codes from ESC-0 to ESC-255 are already waiting for allocation.  No need to
> reserve anything.
> 
> this:  We could then simply say “ignore that you should be sending ESC-like for
> this deployment”, doing the Mesh Header Renovation through the back door.
> But that is exactly the same as saying “reinterpret 11xxxxxx for this
> deployment”, except that it causes a giant confusion, as if there were some
> mechanism there that isn’t.  And we would need to allocate a new code for the
> purposes ESC is allocated for.  We might as well allocate the new code for this
> new thing!
> 
> It should be easily justifiable to get three bits out of the dispatch code by
> allocating eight of these (~ 10 %); four bits (~ 20 %) might be stretching it (but
> might be appropriate if there is a good allocation structure within the new
> structure).  In particular if we can hope to get the unused part of the old MH
> space back.
> 
> Look, Ma, no ESC.
> 
> Grüße, Carsten
>

---

From: James Woodyatt <[email-masked]>
Date: Tue, 21 Apr 2015 11:40:04 -0700

On Tue, Apr 21, 2015 at 1:47 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>
> - Solution [1] is renovation of MH
>

A problem with this solution is that it will entail the SDO liaison
statements and the careful and critical review of the IESG before the
chairs will approve it.

> - Solution [3] is my attempt to answer you earlier mail, which you seem to
> be pushing again. In solution [3] I'm proposing to use 11 11xxxx for
> elective and 1101xxxx for critical.

I agree with your comment below about the problems with this solution.

> [...] The big trouble with the FRAG1 and FRAGN is that they end up
> fragmenting the dispatch space itself. Apart from being premature,  ESC was
> already making that mistake and good thing it was not used yet so we could
> move it. But Fragments... damn Grrrr.
>

The remaining solution [2] is the only one under serious discussion I
think. Am I wrong?

- Solution 2 places one (only one) escape - I used ESC of 01000000 since at
> least that was a use for it - and after that, use the MH renovation as
> above. Confusion with original MH is eliminated. But that's ugly for a
> number of reasons, including as you point out, same codes as MH for
> different things, and the factorization we talked about before.
>

Using the ESC Dispatch Header to renovate the Mesh Header using new type
selector codes from the extended code space is an option that A) avoids the
need to send the SDO liaison statements as in [1], and B) keeps the type
selector code space from being unduly fragmented as in [3].  However, as
Robert Cragie and I have pointed out, it does entail defining a final
mechanism for using the reserved 01111111 type selector code currently
reserved for the dispatch escape mechanism.

There are lots of ways to expand the type selector code space, and I
suspect that a separate draft for that limited purpose may be in order.
However, if the mechanism involves changing the ESC code into a SWITCH code
that controls which page of the type selector code definitions is used in
the current context, then speaking as an individual participant, I'll be
vigorously arguing that a more parsimonious solution would be the NHC++
approach.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Apr 2015 19:56:47 +0000

Hi James:

Please see below:

Le 21 avr. 2015 à 20:40, James Woodyatt <[email-masked]<mailto:[email-masked]>> a écrit :

On Tue, Apr 21, 2015 at 1:47 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

A problem with this solution is that it will entail the SDO liaison statements and the careful and critical review of the IESG before the chairs will approve it.

- Solution [3] is my attempt to answer you earlier mail, which you seem to be pushing again. In solution [3] I'm proposing to use 11 11xxxx for elective and 1101xxxx for critical.

[...] The big trouble with the FRAG1 and FRAGN is that they end up fragmenting the dispatch space itself. Apart from being premature,  ESC was already making that mistake and good thing it was not used yet so we could move it. But Fragments... damn Grrrr.

The remaining solution [2] is the only one under serious discussion I think. Am I wrong?

I think so... I just meant that Fragments headers fragments the dispatch space but still the proposed solution works, doesn't it?

The only trouble is that we lose one bit but if you go through the draft you'll find that I worked it out...

I'd like to hear Carsten's perspective on that third option since he is the one who suggested to explore that path...

Carsten, what do you think?

Pascal