Subject: [6lowpan] Proposal for ND option order

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Jun 2010 14:51:32 +0300

I have a proposal to make ND message processing simpler. RFC4861 and 6lowpan-nd-10 don't specify any specific order in which options are to be included, making parsing more complex. We could simplify things by specifying the order options in the NS, NA, RS, RA messages MUST be carried. 

Thoughts?

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 23 Jun 2010 13:58:56 -0400

> From: Zach Shelby <[email-masked]>
> Date: Tue, 22 Jun 2010 14:51:32 +0300
> 
> I have a proposal to make ND message processing simpler. RFC4861 and
> 6lowpan-nd-10 don't specify any specific order in which options are to
> be included, making parsing more complex. We could simplify things by
> specifying the order options in the NS, NA, RS, RA messages MUST be
> carried.

If nothing else, specifying the order is likely to
reduce interoperation problems.  Requiring that they
be in order of increasing Type would be simplest.
Seems like a good idea.
                              -Richard Kelsey

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jun 2010 14:00:23 -0400

How does ordering the options make parsing easier?

What does the receiver do if the options are out of order?  Discard  
the whole message?

- Ralph

On Jun 23, 2010, at 1:58 PM 6/23/10, Richard Kelsey wrote:

> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Ralph Droms <[email-masked]>
Date: Thu, 24 Jun 2010 15:52:07 -0400

How, exactly, would specifying the order make any difference to an  
implementation in terms of:

* code size and complexity
* processing time
* interoperability

Seems to me such a requirement would reduce interoperability with  
existing implementations.

- Ralph

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 24 Jun 2010 16:16:27 -0400

> From: Ralph Droms <[email-masked]>
> Date: Thu, 24 Jun 2010 15:52:07 -0400
> 

If two options interact in any way, the code to process them
is simpler if they appear in a fixed order.  The degree to
which a fixed order simplifies the code depends on the
degree of interaction between the various options.

> * processing time

No appreciable difference.

> * interoperability

Sending the options in the right order, and testing that
they are sent in the right order, is trivial.  Testing
that the order in which they appear in incoming messages
is irrelevant is much harder.

> existing implementations.

Absolutely.  This only makes sense if there are there 
no existing deployments.  Given the freshness of 6LoWPAN ND
I am not sure that this is an issue.

                                -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jun 2010 22:15:03 +0200

Aah, that would be my next assignment for Protocol Design 101, except that I'm publishing my own solution now :-)

> How does ordering the options make parsing easier?

In general, your code, when seeing a later-ordered option, knows whether an earlier-ordered option is in the packet or not -- it cannot occur later.  This can simplify code a lot.  Of course, that is only the case if the code that is processing one of the options influences the code processing one of the other options.  Haven't looked at ND much in this respect.

> What does the receiver do if the options are out of order?  Discard the whole message?

Yes, please.

> How, exactly, would specifying the order make any difference to an implementation in terms of:
> 

Hard to say without actually having written both versions, but I know that I've seen code getting quite a bit simpler that way.

> * processing time

Negligible, I'd say.

> * interoperability

Tends to get better, because there are fewer cases to test.

Random option ordering is a kind of variability that nobody really needs.
(As one historic example of how protocols can be improved by removing that variability, the "&" connector was thrown out of SGML when it became XML.)

> Seems to me such a requirement would reduce interoperability with existing implementations.

For protocol like ND, that might be a problem.
Whether we want to make this change for 6lowpan depends a lot on whether we think people will write new ND implementations for 6lowpan or reuse old ones.

For any new protocol, I would always consider requiring ordering the options.

Gruesse, Carsten

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 24 Jun 2010 13:15:39 -0700

> Seems to me such a requirement would reduce interoperability with existing
[SC>] 

Given that each ND option has unique type and the specified len field, I am
not sure how ordering would benefit the implementation as well. In most
implementations, a 'for loop' checking for the type in 'case statements'
work. I am also interested to find out if it does not work in some embedded
systems or what exactly is the issue.

Also, I do see the concern on interoperability - i,e I am not sure that the
extra effort of standardizing the order would bring any benefit considering
the interop issues with existing implementations of IPv6 ND (rfc 4861 and
other rfcs) options and more options added in the future.

Thanks,
-Samita

> >> 6lowpan-nd-10 don't specify any specific order in which options are
> >> to be included, making parsing more complex. We could simplify things
> >> by specifying the order options in the NS, NA, RS, RA messages MUST
> >> be carried.
> >
> > If nothing else, specifying the order is likely to reduce
> > interoperation problems.  Requiring that they be in order of
> > increasing Type would be simplest.
> > Seems like a good idea.
> >                              -Richard Kelsey

---

From: Daniel Gavelle <[email-masked]>
Date: Fri, 25 Jun 2010 13:50:44 +0100

If there were a fixed number of options with a fixed length and order, 
the packet would be very simple to parse as the data fields would be at 
the same offset in the buffer each time.

The receiver could check the option type, length and other unchanging 
bytes at their fixed offsets and if anything doesn't match the fixed 
values, reject the packet.

I think this would save several hundred bytes and make testing simpler.

There would need to be two types of e.g. NS, host to LR and LR to LBR 
but it would be easy to distinguish these.

Any future options could be added after the ones that are mandated in 
the current specification.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Robert Cragie <[email-masked]>
Date: Fri, 25 Jun 2010 14:19:40 +0100

As far as I can tell, the options are independent and the presence one 
after another doesn't particularly represent a concatenation. If that is 
the case, I don't really see how specifying the ordering would really 
make that much difference. It would reduce the number of test cases but, 
given that it has not been specified like this before, I don't see a 
precedent for introducing it now.

I can't see that it would save several hundreds bytes if the offsets are 
fixed. A packet is pretty much always parsed sequentially and adding a 
variable to a variable instead of a constant to a variable isn't going 
to make that much difference, surely?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 25/06/2010 1:50 PM, Daniel Gavelle wrote:
> the packet would be very simple to parse as the data fields would be 
> at the same offset in the buffer each time.
>
>
>> Absolutely.  This only makes sense if there are there no existing 
>> deployments.  Given the freshness of 6LoWPAN ND

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Jun 2010 06:19:46 -0700

> the same offset in the buffer each time.

That would not necessarily be the case, because in many cases the 
options are optional, and/or there can be zero or more of them included 
in a packet.

For example the PIO and 6CIO are of the latter form.
And ABRO is optional AFAIK.
There could be a MTU option in RAs.
Etc.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Jun 2010 17:46:33 +0300

Okay, since I started this thread, let me end it. Thanks for the comments everyone, I think Erik nailed it down here. The only way this could really reduce code size is if we would have a fixed set of singular MUST options for each message - but we don't. So let's just drop this idea.

Zach 

On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote:

> That would not necessarily be the case, because in many cases the options are optional, and/or there can be zero or more of them included in a packet.
>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 28 Jun 2010 16:34:54 +0100

+1

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 28/06/2010 3:46 PM, Zach Shelby wrote:
>>>>> From: Ralph Droms<[email-masked]>

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 28 Jun 2010 08:41:08 -0700

+1.  I don't see any benefit to fixed option encoding.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Zach Shelby
Sent: Monday, June 28, 2010 7:47 AM
To: Erik Nordmark
Cc: [email-masked]
Subject: Re: [6lowpan] Proposal for ND option order

Okay, since I started this thread, let me end it. Thanks for the comments
everyone, I think Erik nailed it down here. The only way this could really
reduce code size is if we would have a fixed set of singular MUST options
for each message - but we don't. So let's just drop this idea.

Zach 

On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote:

> That would not necessarily be the case, because in many cases the options
are optional, and/or there can be zero or more of them included in a packet.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 28 Jun 2010 11:55:51 -0400

+1

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Jun 2010 18:05:00 +0200

On Jun 28, 2010, at 16:46, Zach Shelby wrote:

> let's just drop this idea

+1
(as an individual member)

Gruesse, Carsten

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 28 Jun 2010 19:22:40 +0100

+1, as soon as there are options, the savings are pretty much gone.

Daniel

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 28 Jun 2010 11:42:23 -0700

> > let's just drop this idea
 +1  [ Fixed ordering for options in 6lowpan-nd and then mix/matching with
other existing optional IPv6 ND options do create interop issues and require
more processing time]

[SC>]