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

From: John Dowdell <[email-masked]>
Date: Mon, 18 Apr 2016 16:05:47 +0100

First let me say that I wholeheartedly welcome this document. I asked for it when I was unable to map AODVv2 messages on to the 5444 format to the satisfaction of the 5444 author team. Some of the other AODVv2 co-authors have had similar issues, so it’s good that we have this draft that will hopefully put us and anyone coming after us on the right track. I’m also sold on the idea of a multiplexer to increase the efficiency of over the air transmission.

Some comments:

4.2, transmission, first bullet: " Outgoing messages are created by their owning protocol, and MAY be modified by any extending protocols if the owning protocol permits this.” Fair enough, so messages from the hosted protocol can be modified by an extension to that protocol before getting to the 5444 parser. “

Messages MAY also be forwarded by their owning protocol.”. Also ok, there are no extension protocols.

"It is strongly RECOMMENDED that messages are not modified in the latter case.” I’m not following this. Why is it ok to modify messages that have been impacted by an extension to the hosted protocol, but it’s not ok to modify messages that have not been subject to extension processing? What does ‘modify’ mean in this context anyway?

4.2, transmission, second bullet: “…  The owning protocol MUST indicate which interface(s) the messages are to be sent on …”. I have struggled with this for a long time. The hosted protocol is isolated from the interface by at least the 5444 multiplexer, and therefore has no idea which interfaces are being used for transmission or reception. Is there an implicit requirement that the demultiplexer must indicate the interface that a message came in on (and, if different, the associated outgoing interface), so that outgoing messages can be directed accordingly?

4.2, transmission, third bullet: " The multiplexer SHOULD combine messages … provided that in so doing the multiplexer does not cause an IP packet to exceed the current MTU .. (Note that the multiplexer cannot fragment messages; creating suitable sized messages is the responsibility of the protocol generating the message.)”

First problem; how does the hosted protocol know the MTU if it is isolated from the interface?

Second problem; I completely disagree that the hosted protocol, which has no knowledge of interface or MTU, and may not be the only hosted protocol, should be in charge of making short enough messages that fit the MTU size. Since the multiplexer is potentially conducting all kinds of compression, the hosted protocol is required to carefully craft a message that fits what it believes is the MTU, if it has been told, only for the multiplexer to optimise and shave off some bytes (and maybe many bytes), potentially combine it with messages from some other hosted protocol and send it out the interface. The hosted protocol could have used those bytes to send more information, and less overhead would have been generated. If the 5444 mux/demux is in charge of making whole messages magically reappear in one piece at the receiving end, it doesn’t matter to me how many fragments the message was spread across in transit.

4.2, transmission, fifth bullet: “ … the multiplexer SHOULD … include a Packet Sequence Number in the packet”. I’m not sure this is necessary. The hosted protocol is most likely using its own sequence numbers in its own messages, and understands that messages can arrive out of sequence. Additionally, packets are only sent hop by hop (section 1.2.1 bullet 3) and never forwarded. I can see that having a packet sequence number could be useful for system-level debugging, but otherwise I can’t see the need.

4.2, reception, "Each message MUST be sent to its owning protocol.” Can you clarify that if an extension protocol is being used, that such a protocol might want or need to process the message first? Bullet 4 discusses the extension protocol too.

6.4 " Such a protocol-independent optimizer MAY be used by the router generating a message, but MUST NOT be used on a message that is forwarded unchanged by a router.” I understood that 5444 operates one hop at a time and the messages are presented back to the host protocol for action. If the host protocol chooses to forward the message unchanged, I understand that it would be more efficient to wave the message through at the 5444 level, but surely that is not allowed?

A suggestion: Given that AODVv2 is the first “customer” for 5444 outside of the team that also wrote the OLSRv2 series RFCs, can someone from that team please review the relevant sections in the AODVv2 draft and assess how well that draft matches up to this draft? Thus someone coming after us can be directed to AODVv2 as the first “correct" independent usage in the manet working group  of RFC5444, and could meet a potential AD-level question of ‘did we eat our own dog food?’. I use “correct” here not to say that all potential use cases are covered, but at least AODVv2 correctly follows the model that the authors of 5444 intended.

And finally … I’d still like to see even a minimal API specification, it would have saved me days if not weeks of wasted effort going in the wrong direction. Also, I’d still like to see a statement of components that are reserved entirely for use by the 5444 process, and what can be usefully used by the hosted protocol.

Regards
John

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 15:50:45 +0000

John
> 4.2, transmission, first bullet: " Outgoing messages are created by their owning protocol, and MAY be modified by any extending protocols if the owning protocol permits this.” Fair enough, so messa…

The final delivery to the multiplexer is (conceptually, of course implementations can optimise - always true if the result is undetectable) is from the owning protocol.

> Messages MAY also be forwarded by their owning protocol.”. Also ok, there are no extension protocols.

To what?

> "It is strongly RECOMMENDED that messages are not modified in the latter case.” I’m not following this. Why is it ok to modify messages that have been impacted by an extension to the hosted protoco…

Because one is in the endpoint, one is not. If you modify messages at the endpoint (e.g. OLSRv2 adding MPRs to NHDP's HELLO messages) you can add an ICV afterwards and still get end to end security. If you modify in between the two then you can't.

> 4.2, transmission, second bullet: “…  The owning protocol MUST indicate which interface(s) the messages are to be sent on …”. I have struggled with this for a long time. The hosted protocol is isol…

I need to work out how implicit that is, what's been said. But yes, the protocol may need to know which interface a message came in on. NHDP does. I thought we'd added an indication of what the (de)multiplexer needs to deliver - addresses, packet header, interface.

> First problem; how does the hosted protocol know the MTU if it is isolated from the interface?

Just been having that conversation. Apart from not producing single messages that are too large - which is a problem many things not directly sitting on IP have - that paragraph is about the multiplexer, it's not the protocol's problem.

> Second problem; I completely disagree that the hosted protocol, which has no knowledge of interface or MTU, and may not be the only hosted protocol, should be in charge of making short enough messages that fit the MTU size. Since the multiplexer is potentially conducting all kinds of compression, 

No, it's not. It's prohibited from doing so. It says so in this draft. 

> the hosted protocol is required to carefully craft a message that fits what it believes is the MTU, if it has been told, only for the multiplexer to optimise and shave off some bytes (and maybe many bytes),

You are confusing the optional concept of having a parser with a multiplexer. There is no such function guaranteed to exist.

Consider 5444 as consisting of who things that ought to be in two different RFCs. One is the multiplexer. One is a specification of packet and message format. Note, no such thing as a parser. A parser is an implementation choice that arises from "You know, OLSRv2 and SMF are using the same format. Why don't I just write that code once?". If you want to optimiser how to do that, that's up to you. But in terns of the 5444 model, that's all protocol.

> potentially combine it with messages from some other hosted protocol and send it out the interface. The hosted protocol could have used those bytes to send more information, and less overhead would have been generated. If the 5444 mux/demux is in charge of making whole messages magically reappear in one piece at the receiving end, it doesn’t matter to me how many fragments the message was spread across in transit.

If it's fragmented, it's fragmented by IP, because the multiplexer doesn't fragment. As that text says. I prefer things not to be fragmented by IP, especially on unreliable radio links.

> 4.2, transmission, fifth bullet: “ … the multiplexer SHOULD … include a Packet Sequence Number in the packet”. I’m not sure this is necessary. The hosted protocol is most likely using its own seque…

But I can. It's useful in some NHDP/OLSRv2 combinations to track the link reliability. But if you know you don't care, the that's a SHOULD - i.e. you made an informed decision not to, so you can not do.

> 4.2, reception, "Each message MUST be sent to its owning protocol.” Can you clarify that if an extension protocol is being used, that such a protocol might want or need to process the message first…

No. It goes to the base protocol. If you think the extension protocol needs to see it early in the processing, that's up to you to specify in the base protocol (or in an extension draft that modifies the base protocol) how that's done.

> 6.4 " Such a protocol-independent optimizer MAY be used by the router generating a message, but MUST NOT be used on a message that is forwarded unchanged by a router.” I understood that 5444 operat…

I think this was intended to clarify, but may not have done so. As noted, parsing is up to you. However when you are creating a message in the protocol, as a matter of practical implementation you might choose to optimise the message. You might also decide to write an independent parser. You might choose to combine the two. All good. You might then be tempted to use the optimising parser in the 5444 multiplexer in an intermediate router. Not good. This is intended to say that - don't do this. Of course if you were never tempted, not a problem.

> A suggestion: Given that AODVv2 is the first “customer” for 5444 outside of the team that also wrote the OLSRv2 series RFCs,

Not so. RFC 6621.

> can someone from that team please review the relevant sections in the AODVv2 draft and assess how well that draft matches up to this draft? 

If someone would fund me to do so, I'd be delighted. In the meanwhile that will get done if I ever get the time. And the whole approach of the AODVv2 authors of private discussions that aren't held here, where they should be, and failure to ask basic questions years ago instead of talking privately and then when comments are received often ignoring them (there are comments I have made several times on several drafts before they eventually happened) isn't actually helping that happen.

> Thus someone coming after us can be directed to AODVv2 as the first “correct" independent usage in the manet working group  of RFC5444, and could meet a potential AD-level question of ‘did we eat our own dog food?’. I use “correct” here not to say that all potential use cases are covered, but at least AODVv2 correctly follows the model that the authors of 5444 intended.

I think this fails to take on board that the authors of 5444 didn't set out to create something and foist it on you, which is a message I get too often from the AODVv2 author team. We created 5444 for our protocols, then were half persuaded, half bounced, into generalising it by a DYMO author. So the intent was the WG as a whole, not simply the 5444 authors.

> And finally … I’d still like to see even a minimal API specification, it would have saved me days if not weeks of wasted effort going in the wrong direction. 

And again. No. Not appropriate. And I think based on the misconception I note above and below.

> Also, I’d still like to see a statement of components that are reserved entirely for use by the 5444 process, and what can be usefully used by the hosted protocol.

Don't understand this. I think it's based on the misconception that there's a parser object in the multiplexer.

Regards
John

_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
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: Jiazi YI <[email-masked]>
Date: Tue, 19 Apr 2016 00:49:34 +0200

>
>
>
> > "It is strongly RECOMMENDED that messages are not modified in the latter
> case.” I’m not following this. Why is it ok to modify messages that have
> been impacted by an extension to the hosted protocol, but it’s not ok to
> modify messages that have not been subject to extension processing? What
> does ‘modify’ mean in this context anyway?
>
> Because one is in the endpoint, one is not. If you modify messages at the
> endpoint (e.g. OLSRv2 adding MPRs to NHDP's HELLO messages) you can add an
> ICV afterwards and still get end to end security. If you modify in between
> the two then you can't.
>

I can understand for the purpose of integrity checking, we couldn't modify
when the messages are being forwarded.
But RFC5444 is designed for reactive protocol also, which (in most cases),
by nature, will modify the message in intermediate routers. It sounds a bit
strange for me if such operation is not recommended by RFC5444.

Jiazi

---

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

RECOMMENDED (which is the same as SHOULD) means do this unless you understand this, and know why you are not doing it, with a good reason.

That pretty much covers the scenario. Modifying messages has a significant downside, so don’t do it unless you need to.

Reactive protocols with link metrics are a case where people have done that tradeoff and made a decision to do otherwise. That fits the RECOMMENDED pattern. (There’s more that they could do, such as controlling that variation, but that’s really beyond our scope here.)

But having this as RECOMMENDED should make people devising other protocols stop and think before doing it gratuitously.

(Personally I could live without the strongly before RECOMMENDED, but at least one other author wanted it there, and I didn’t demur.)

--
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: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 18 April 2016 23:50
To: Dearlove, Christopher (UK)
Cc: John Dowdell; [email-masked]
Subject: Re: [manet] Review of 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>.

I can understand for the purpose of integrity checking, we couldn't modify when the messages are being forwarded.
But RFC5444 is designed for reactive protocol also, which (in most cases), by nature, will modify the message in intermediate routers. It sounds a bit strange for me if such operation is not recommended by RFC5444.

Jiazi