Subject: [pcp] Option ordering, ticket #41

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Feb 2011 10:35:54 -0800

During today's PCP call, it was proposed to add suggested ordering for PCP
options, which is new ticket #41,
http://trac.tools.ietf.org/wg/pcp/trac/ticket/41

I propose the following:

1.  Currently, the optional-to-process options are 0-127, and
mandatory-to-process options are 128-255.  I propose swapping
this, so the mandatory-to-process options are numbered lowest.

2. new text for the General PCP Client processing section:

  If more than one Option is included in a PCP request, the
  Options MUST be ordered from the lowest numbered option to
  the highest numbered option.

3. new text for the General PCP Server processing section:

  If more than one Option is present in the PCP request,
  and they are not ordered from lowest numbered Option
  to highest numbered Option, the PCP server MUST generate 
  a MISORDERED_OPTIONS error response.

Comments or feedback?

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Feb 2011 13:42:01 -0500

On 2011-02-22 13:35, Dan Wing wrote:
> options

Can you please summarize why this is a good idea? Specifically, what
optimizations would this allow the server to perform?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dave Thaler <[email-masked]>
Date: Tue, 22 Feb 2011 20:37:48 +0000

I like this in general.
It makes me wonder though whether we should leave a gap between existing options, to allow for future insertion requirements?   Or maybe we just reserve the lowest numbered value in case we ever need to add an "option ordering option" at some point in the future.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Tuesday, February 22, 2011 10:36 AM
> To: [email-masked]
> Subject: [pcp] Option ordering, ticket #41
> 
> 1.  Currently, the optional-to-process options are 0-127, and mandatory-to-
> process options are 128-255.  I propose swapping this, so the mandatory-to-
> process options are numbered lowest.
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Feb 2011 12:43:23 -0800

The issue with options in IPv6 is that, if you do not care about them, you still have to process them one by one before finding the transport header...
This is something that middle-boxes using hardware acceleration do not like.
In PCP, options are at the end of the packet, so this should be much less of an issue.

  - Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Feb 2011 13:10:52 -0800

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Tuesday, February 22, 2011 12:38 PM
> To: Dan Wing; [email-masked]
> Subject: RE: [pcp] Option ordering, ticket #41
> 
> I like this in general.
> It makes me wonder though whether we should leave a gap between
> existing options, to allow for future insertion requirements?  

Like line numbering in BASIC?

Do you expect we would "prioritize" the options somehow, in 
importance or something??  

> Or
> maybe we just reserve the lowest numbered value in case we ever need to
> add an "option ordering option" at some point in the future.

-d

> mandatory-to-

---

From: Simon Perreault <[email-masked]>
Date: Wed, 23 Feb 2011 10:50:51 -0500

> In PCP, options are at the end of the packet, so this should be much less of an issue.

So it looks like there is no reason why we would be doing this. I don't
see how it could make the server's life any easier. If nobody can come
up with a justification, we're just imposing an arbitrary constraint on
the protocol.

I can certainly live with that constraint. It's just that usually I
prefer those of the justified kind.... ;)

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Feb 2011 16:32:14 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Wednesday, February 23, 2011 7:51 AM
> To: [email-masked]
> Subject: Re: [pcp] Option ordering, ticket #41
> 
> > The issue with options in IPv6 is that, if you do not care about
> them, you still have to process them one by one before finding the
> transport header...

I believe it was Xiaohong Deng, in the interim, that supported the
idea of ordering the options, to help hardware implementations.  I
know we are not doing a hardware implementation of PCP, but other
vendors might be.

It could help, though, to require the mandatory-to-process
options be listed first, so that a PCP server can parse through
the packet until it (a) hits the first non-mandatory-to-process
option or (b) hits a mandatory-to-process option that it cannot
process.  But this is a pretty minor optimization in the scheme
of things.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 23 Feb 2011 19:38:23 -0500

I also support Ordering + mandatory-to-process first for the same reasons.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Feb 2011 09:30:00 -0500

> know we are not doing a hardware implementation of PCP, but other

Would it be impolite to expect a technical justification from the person
asking for the constraint?

I mean, I see people agreeing with the demand, but I still have not seen
any justification.

> process.  But this is a pretty minor optimization in the scheme

Agreed.

Simon

---

From: Alain Durand <[email-masked]>
Date: Thu, 24 Feb 2011 06:35:28 -0800

The best justification I've heard so far is that HW may or may not want to support 'optional' options.
By ordering them and putting the mandatory one first, as soon as a non-nandatory option is seen, the server can stop
processing the packet. It will not have to go through the list trying to find a subsequent mandatory option.

That seems to me a reasonable request attached to a small price tag.

   - Alain.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Feb 2011 09:54:59 -0500

> processing the packet. It will not have to go through the list trying to find a subsequent mandatory option.

Thanks, got it.

> That seems to me a reasonable request attached to a small price tag.

I have a different opinion, but as I said earlier, I can live with that.

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 24 Feb 2011 11:26:57 -0500

So,

If there are mandatory options 1, 4 and optional 6, 8 the packet would have

1, 4, 6, 8

Correct?

On 2/24/11 6:35 AM, "Alain Durand" <[email-masked]> wrote:

> By ordering them and putting the mandatory one first, as soon as a
> non-nandatory option is seen, the server can stop

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Feb 2011 08:44:50 -0800

While editing the text, I ran into a sticky problem.  The text will say the
request needs to use a specific order for the options.  That's fine.
However, a client might have a bug (yes, bugs happen), causing the client to
send options in a different order.  Let's imagine the client sends the
options in the order:

  mandatory-to-process
  optional-to-process
  mandatory-to-process

When the server receives this message, and it is expecting the options in a
certain order, the server might stop processing at that first
optional-to-process option.  This seems to be a problem.  The only way the
server can realize the options were sent out of order is to look at all the
options.  While editing, the best text I can come up with:

  If the server receives Options that are not in the required order, its
  behavior for processing all of the Options is unspecified and is
  implementation-dependent.  

This feels somewhat dirty.  I don't like it, because it creates
inconsistency in the protocol.  A PCP server that is liberal in what it
accepts could accept out-of-order Options and process them properly.  But a
PCP server that is following the specification would return an error, choke,
or have broken operation (from the perspective of the PCP client).

-d

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, February 24, 2011 6:55 AM
> To: Alain Durand
> Cc: Dan Wing; [email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 24 Feb 2011 11:56:43 -0500

why not the ietf moto: should send in order, be prepared to receive in 
any order.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Alain Durand <[email-masked]>
Date: Thu, 24 Feb 2011 08:55:22 -0800

This is what MUST are for.
The client MUST order option. The server MAY discard out of order options.

  - Alain.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 24 Feb 2011 12:05:18 -0500

As long as prepared to receive only means receiving and nothing else.
Something like IPv6. If headers are out of order, no guarantees

"  IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation."

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Feb 2011 18:50:27 +0100

In your previous mail you wrote:

   But this is a pretty minor optimization in the scheme of things.
   
=> and not for all operations, in particular it makes insert clearly
more complex...

Regards

[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Thu, 24 Feb 2011 18:13:31 +0000

You could say that 
> If the server receives Options that are not in the required order, it
> MUST fail the request.

Then there's no inconsistency, and clients with bugs fail fast.

-Dave

> Sent: Thursday, February 24, 2011 8:45 AM
> To: 'Simon Perreault'; 'Alain Durand'
> Cc: [email-masked]
> send options in a different order.  Let's imagine the client sends the options
> in the order:
> 
>   mandatory-to-process
>   optional-to-process
>   mandatory-to-process
> 
> certain order, the server might stop processing at that first optional-to-
> process option.  This seems to be a problem.  The only way the server can
> realize the options were sent out of order is to look at all the options.  While
> editing, the best text I can come up with:
> 
> This feels somewhat dirty.  I don't like it, because it creates inconsistency in
> the protocol.  A PCP server that is liberal in what it accepts could accept out-
> of-order Options and process them properly.  But a PCP server that is
> following the specification would return an error, choke, or have broken
> operation (from the perspective of the PCP client).
> 
> -d
> 
> 
> > > processing the packet. It will not have to go through the list
> > > trying
> > to find a subsequent mandatory option.
> >
> > Thanks, got it.
> >

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 24 Feb 2011 14:47:30 -0500

Good point.