Subject: [manet] draft-ietf-manet-rfc5444-usage-03

From: Charlie Perkins <[email-masked]>
Date: Wed, 13 Apr 2016 16:59:38 -0700

Hello folks,

This is not a short document.  It is not easy to read.

I have only read halfway through it.  Among the first problems with the 
draft, keeping in mind that I have not finished it:

  * It should be no more than Informational, and more likely
    Experimental owing to the next point.
  * The protocols that somehow manage to conform to this formulation of
    correctness are written by the authors themselves.  Thus, it seems
    unrealistic to imagine that the restrictions actually allow
    general-purpose routing protocol designs.
  * It is improper for adherence to one simple parser design to
    constrain protocol design for such a wide class of routing problems
    as are represented by ad hoc networks.
  * As practiced to date, RFC 5444 has inhibited the use of default
    values for system parameters.   In the document this is exhibited as
    a feature which is erroneously claimed to be required for future
    extensibility.
  * The document requires the protocol to know about MTU but discussion
    on the list inhibits the protocol from knowing about MTU.
  * The document disallows the protocol from specifying crucial
    parameters such as time allowable for  aggregation of control messages.
  * Addresses are presumed to be included in a message for no particular
    reason unless described by yet another address TLV. This increases
    message size on the speculation that the protocol will want to be
    used with other unrelated protocols in the future.  In normal
    protocol design, addresses are put into a message for reasons that
    are specific to the message.

On average, the design of the multiplexer is presumed to be the highest 
priority and the design of the routing protocol a distinctly less 
important matter.  Moreover, the multiplexer design is subservient to 
whatever is easiest for the container designers to parse.  This is 
putting the cart before the horse.

I will try to finish reading the draft soon, but I think that Last Call 
for this document is premature at best.  I would strongly suggest that 
it be delayed until the current two major [manet] items can be finished.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 14 Apr 2016 09:09:07 +0000

Charlie
> This is not a short document.  It is not easy to read.

If you have any specific observations, please let us have them.

> I have only read halfway through it.  Among the first problems with the draft, keeping in mind that I have not finished it:

  *   It should be no more than Informational, and more likely Experimental owing to the next point.
This is entirely wrong. The document is not Informational, it specifies rules. It has absolutely no need to be Experimental as it has a large amount of experience, with a reactive protocol as well as proactive, behind it, and multiple instances of running code.
It was also accepted as a WG item as intended for Proposed Standard.

  *   The protocols that somehow manage to conform to this formulation of correctness are written by the authors themselves.  Thus, it seems unrealistic to imagine that the restrictions actually allow general-purpose routing protocol designs.
I’m not sure how to respond to this. It’s written by the people with the most experience of RFC 5444, at least one of whom for a reactive protocol as well as NHDP and OLSRv2. It’s built on collectively decades of experience, and all of the co-authors have implemented RFC 5444 and protocols using it, some more than once. The idea that this makes us unsuited is one I do not understand.

  *   It is improper for adherence to one simple parser design to constrain protocol design for such a wide class of routing problems as are represented by ad hoc networks.
Sorry, you are well out of line there. This was a WG decision, specified in RFC 5498. A document written by your then DYMO co-author Ian Chakeres (also WG chair) and agreed by the WG. It wasn’t foisted on you by the authors - quite the reverse, we had making it work as a generic specification put onto us.

  *   As practiced to date, RFC 5444 has inhibited the use of default values for system parameters.   In the document this is exhibited as a feature which is erroneously claimed to be required for future extensibility.
I don’t know what you are talking about here. RFC 5444 isn’t concerned with system parameters. What’s claimed to be useful for extensibility is that which is already experienced to be useful for extensibility, and examples given.

  *   The document requires the protocol to know about MTU but discussion on the list inhibits the protocol from knowing about MTU.
Even if someone on the list said that the protocol is inhibited from knowing about MTU, that’s not relevant. Does this document say that? No. But I also don’t recall anyone saying that. Any protocol (or even many applications) that run directly or indirectly over IP need to have some idea about MTU, possibly with rules of thumb as to how much to subtract due to expected headers. This is no different.

  *   The document disallows the protocol from specifying crucial parameters such as time allowable for  aggregation of control messages.
That is exactly backwards. From Section 4.2
   o  The multiplexer MAY delay messages briefly in order to assemble
      more efficient packets.  It SHOULD respect any constraints on such
      delays requested by the protocol.
If you want to argue that the SHOULD ought to be a MUST then fine, I’d have some sympathy with that, but we were trying not to overly constrain. But that the protocol can inform the multiplexer is clearly there.

  *   Addresses are presumed to be included in a message for no particular reason unless described by yet another address TLV.  This increases message size on the speculation that the protocol will want to be used with other unrelated protocols in the future.  In normal protocol design, addresses are put into a message for reasons that are specific to the message.
Yes, this is a design feature that is highly desirable for extensibility. That’s the experience of a lot of time working with a protocol (OLSR) without that, and this. I can already see how possible extensions to AODVv2 could use this freedom. While bytes do matter, so does extensibility.
Frankly, what protocols need is to go in one direction or the other. One direction is a tightly optimised ultra-compact message for very specific use, in particular for systems based on microcontrollers and very constrained wireless links. It’s quite open to you to create a separate message structure for that. You’re already part way there with first specifying what’s in a message, then how that’s represented in RFC 5444. In an ideal world we’d have done the same for OLSRv2. The other direction, while not oblivious to efficiency concerns, is prepared to add a few octets (and we are talking a low single figure number) to allow extensibility. Even the authors missed some extensibility options back in earlier days, whoever it was that insisted on a per-message address length, rather than inheriting from whatever IP stack you were running on, was right.
An appendix (or probably in light of timescales) separate draft on an ultra-compact representation of AODVv2, explicitly not intended to be extensible, would be interesting, and might find some application.
> On average, the design of the multiplexer is presumed to be the highest priority and the design of the routing protocol a distinctly less important matter.  Moreover, the multiplexer design is subservient to whatever is easiest for the container designers to parse.  This is putting the cart before the horse.
The multiplexer is in place, that’s RFC 5498. This isn’t new. The horse is already in front of the cart.

> I will try to finish reading the draft soon, but I think that Last Call for this document is premature at best.  I would strongly suggest that it be delayed until the current two major [manet] items can be finished.
That’s completely unacceptable. Who knows how long you are going to continue to work on AODVv2 out of sight of this WG. And this really is the cart before the horse. Your co-authors of AODVv2 requested further clarification of RFC 5444, and we put in the work to do that. Clarifying the base before building on it is the right order.
Also, why two WG documents? The only other significant document is DLEP, which is both independent of this (it doesn’t use 5444 - and that’s because it’s not a MANET routing protocol) and already out of the gate.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 17 Apr 2016 23:02:08 -0700

Hello Chris,

I can't fully respond right now but a few points:

On 4/14/2016 2:09 AM, Dearlove, Christopher (UK) wrote:
>     constrain protocol design for such a wide class of routing
>     problems as are represented by ad hoc networks.
>
> Sorry, you are well out of line there. This was a WG decision, 
> specified in RFC 5498. A document written by your then DYMO co-author 
> Ian Chakeres (also WG chair) and agreed by the WG. It wasn’t foisted 
> on you by the authors - quite the reverse, we had making it work as a 
> generic specification put onto us.
>

Ian has told me more than once that he is *very very* surprised at some 
of the restrictions that have been legislated as a result of RFC 5498.  
Speaking for myself, when that was happening I somehow imagined that it 
would be better to have the address aggregation facilities, but I didn't 
realize the costs.

Maybe when the WG accepted this document, it was not clear how costly 
that decision would be.

>
>   * The document requires the protocol to know about MTU but
>     discussion on the list inhibits the protocol from knowing about MTU.
>
> Even if someone on the list said that the protocol is inhibited from 
> knowing about MTU, that’s not relevant. Does this document say that? 
> No. But I also don’t recall anyone saying that. Any protocol (or even 
> many applications) that run directly or indirectly over IP need to 
> have some idea about MTU, possibly with rules of thumb as to how much 
> to subtract due to expected headers. This is no different.
>

Somebody asked to remove all mention of MTU from AODVv2.  I argued that 
we had to have it but lost the argument.

> If you want to argue that the SHOULD ought to be a MUST then fine, I’d 
> have some sympathy with that, but we were trying not to overly 
> constrain. But that the protocol can inform the multiplexer is clearly 
> there.
>

If the protocol says something about delay, that MUST be respected.

Regarding "exactly backwards" -- I wish I could count how many SHOULDs 
have been converted to "MUSTs" based on the theory that implementers 
don't give a darn about SHOULDs.  Believe me, I do know the RFC 2119 
definitions, but I lose every such argument.

However, even if implementers really really did respect the meaning of 
SHOULD, in this case it would still have to be MUST.

>   * Addresses are presumed to be included in a message for no
>     particular reason unless described by yet another address TLV. 
>     This increases message size on the speculation that the protocol
>     will want to be used with other unrelated protocols in the
>     future.  In normal protocol design, addresses are put into a
>     message for reasons that are specific to the message.
>
> Yes, this is a design feature that is highly desirable for 
> extensibility. That’s the experience of a lot of time working with a 
> protocol (OLSR) without that, and this. I can already see how possible 
> extensions to AODVv2 could use this freedom. While bytes do matter, so 
> does extensibility.
>
> Frankly, what protocols need is to go in one direction or the other. 
> One direction is a tightly optimised ultra-compact message for very 
> specific use, in particular for systems based on microcontrollers and 
> very constrained wireless links. It’s quite open to you to create a 
> separate message structure for that. You’re already part way there 
> with first specifying what’s in a message, then how that’s represented 
> in RFC 5444. In an ideal world we’d have done the same for OLSRv2. The 
> other direction, while not oblivious to efficiency concerns, is 
> prepared to add a few octets (and we are talking a low single figure 
> number) to allow extensibility. Even the authors missed some 
> extensibility options back in earlier days, whoever it was that 
> insisted on a per-message address length, rather than inheriting from 
> whatever IP stack you were running on, was right.
>
> An appendix (or probably in light of timescales) separate draft on an 
> ultra-compact representation of AODVv2, explicitly not intended to be 
> extensible, would be interesting, and might find some application.
>

Heading down that path we're going to have to specify every protocol 
twice.  I thought it would be better to avoid having the extra bytes in 
the first place.  Besides that there are simple ways to enable both 
economical size and extensibility.  But one sentence rings in my mind 
containing the words "Hell No".

I'm not clear on that part about restricting to a per-message address 
length, but it's not a big deal for most protocols and not for AODVv2, 
so we could talk about that later if ever.

> horse is already in front of the cart.

Well, it does not have to be.

>
> >I will try to finish reading the draft soon, but I think that Last 
> Call for this document is premature at best.  I would strongly suggest 
> that it be delayed until the current two major [manet] items can be 
> finished.
>
> That’s completely unacceptable. Who knows how long you are going to 
> continue to work on AODVv2 out of sight of this WG. And this really is 
> the cart before the horse. Your co-authors of AODVv2 requested further 
> clarification of RFC 5444, and we put in the work to do that. 
> Clarifying the base before building on it is the right order.
>

We're trying to resolve the very few remaining comments.  I would think 
that something as far reaching as this usage document could take a good 
while.  I'd hate to have that front of finishing AODVv2.

> Also, why two WG documents? The only other significant document is 
> DLEP, which is both independent of this (it doesn’t use 5444 - and 
> that’s because it’s not a MANET routing protocol) and already out of 
> the gate.
>
>

O.K. I thought it was still under discussion...

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 09:19:21 +0000

With regard to MTU, as I said I don’t recall any such comment. A vague someone asked doesn’t advance us. It is of course possible to AODVv2 to try to abuse MTU, but simply knowing it isn’t an abuse.

Realistically, what’s AODVv2’s interaction with MTU, given the multiplexer? Don’t produce messages that, together with all the other headers expected (IP, UDP, 5444) will exceed MTU. Is there a possible MTU - even ones I’ve come across as low as 600 bytes - and a possible AODVv2 message that is even close to that? (The multiplexer then has its own issues in deciding how to group messages in packets. But that’s its problem. And not hard. Yes, AODVv2 could also request certain messages be kept together - except I don’t think it does - but the multiplexer could ignore that if it has to.)

As for the idea that AODVv2 is closer to being finished that this draft, that’s just not remotely plausible. We’re in LC here. We don’t have an AODVv2 draft that make LC even a question. And the continuing practice of the authors discussing almost everything off list then just “here’s a new draft” with very few comments makes proper handling of the document by the WG really hard, or worse.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Charlie Perkins [mailto:[email-masked]]
Sent: 18 April 2016 07:02
To: Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] draft-ietf-manet-rfc5444-usage-03

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hello Chris,

Ian has told me more than once that he is *very very* surprised at some of the restrictions that have been legislated as a result of RFC 5498.  Speaking for myself, when that was happening I somehow imagined that it would be better to have the address aggregation facilities, but I didn't realize the costs.

Maybe when the WG accepted this document, it was not clear how costly that decision would be.

Somebody asked to remove all mention of MTU from AODVv2.  I argued that we had to have it but lost the argument.

Regarding "exactly backwards" -- I wish I could count how many SHOULDs have been converted to "MUSTs" based on the theory that implementers don't give a darn about SHOULDs.  Believe me, I do know the RFC 2119 definitions, but I lose every such argument.

However, even if implementers really really did respect the meaning of SHOULD, in this case it would still have to be MUST.

Heading down that path we're going to have to specify every protocol twice.  I thought it would be better to avoid having the extra bytes in the first place.  Besides that there are simple ways to enable both economical size and extensibility.  But one sentence rings in my mind containing the words "Hell No".

I'm not clear on that part about restricting to a per-message address length, but it's not a big deal for most protocols and not for AODVv2, so we could talk about that later if ever.

We're trying to resolve the very few remaining comments.  I would think that something as far reaching as this usage document could take a good while.  I'd hate to have that front of finishing AODVv2.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 18 Apr 2016 12:09:18 +0200

On Mon, Apr 18, 2016 at 8:02 AM, Charlie Perkins
<[email-masked]> wrote:
> The document requires the protocol to know about MTU but discussion on the
> list inhibits the protocol from knowing about MTU.

The only thing where the MTU should be relevant for ALL RFC5444
protocols is that you should not produce a RFC5444 Message that
(including IP/UDP/RFC5444-Packet headers) does not fit into the MTU.

Henning Rogge