Subject: [manet] RFC 5444 usage - one specific point.

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

So far I see one specific point for WG agreement - anything else is editorial. (Editorial matters, but it's not changing rules, so I'm trying here to address one specific rule issue.) Some comments have clearly overlooked this, but whether to telegraph it further (e.g. mention in non-normative introduction) is back to editorial.

The draft currently says:

   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.

Should we change that SHOULD to a MUST? Obviously IETF-style we don't run votes as such, but what are people's opinions?

As I see it:

Argument for MUST: If the protocol has strong requirements the multiplexer needs to respect those.

Argument for SHOULD: But the protocol might make an impossible demand, such as zero delay when we all know nothing has zero delay. SHOULD isn't MAY, it needs to do its best.

Possible third course, something like (open to wordsmithing - I considered putting the caveat at the end, for example).

   o  The multiplexer MAY delay messages briefly in order to assemble
      more efficient packets.  It MUST, as far as possible, respect any
      constraints on such delays requested by the protocol.

Argument against third course, we've seen before that anything that includes wording like that is open to IESG not being happy.

On balance, I think SHOULD is appropriate, assuming SHOULD is interpreted as it should be - do this unless there really is a good reason not to. But I could live with any of the three (if allowed).

(If there aren't any strong views, I think we will stick with what's there.)

We can see what the rough consensus over WGLC is on this one.

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

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

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

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Mon, 18 Apr 2016 12:13:24 +0200

> Should we change that SHOULD to a MUST? Obviously IETF-style we don't run votes as such, but what are people's opinions?

Unless we specify what kind of "constraints" a protocol can specify, a
MUST would be a bit strange.

> On balance, I think SHOULD is appropriate, assuming SHOULD is interpreted as it should be - do this unless there really is a good reason not to. But I could live with any of the three (if allowed).

SHOULD would be okay... especially because (normally) multiplexer
would restrict the amount of constraints of the protocol by its API
anyways.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 10:37:48 +0000

Playing devil's advocate (because I prefer SHOULD) if we went MUST then we would, as you say, need to state somewhere (probably in this paragraph, but I haven’t checked the draft) that the protocol MAY accompany each message with a maximum delay before sending, which the multiplexer MUST etc.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 18 April 2016 11:13
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] RFC 5444 usage - one specific point.

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

> Should we change that SHOULD to a MUST? Obviously IETF-style we don't run votes as such, but what are people's opinions?

Unless we specify what kind of "constraints" a protocol can specify, a MUST would be a bit strange.

> On balance, I think SHOULD is appropriate, assuming SHOULD is interpreted as it should be - do this unless there really is a good reason not to. But I could live with any of the three (if allowed).

SHOULD would be okay... especially because (normally) multiplexer would restrict the amount of constraints of the protocol by its API anyways.

Henning Rogge

---

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

> Playing devil's advocate (because I prefer SHOULD) if we went MUST then we would, as you say, need to state somewhere (probably in this paragraph, but I haven’t checked the draft) that the protocol…

Which would be a little bit insane, on most operation systems there is
NO WAY for userspace to be sure how long it will take for an IP packet
to be transmitted.

It might just sit in the outgoing transmission queue for a while...

Henning Rogge

---

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

I think it's a question of timescales. Though that opens up whole cans of worms. But the sort of timing that might be imposed might be that NHDP and OLSRv2 might be OK with a few tenths of seconds extra delay. Which is probably longer than operating system delays.

But I think we currently have the balance about right. And I read you as agreeing.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 18 April 2016 11:39
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] RFC 5444 usage - one specific point.

> Playing devil's advocate (because I prefer SHOULD) if we went MUST then we would, as you say, need to state somewhere (probably in this paragraph, but I haven’t checked the draft) that the protocol…

Which would be a little bit insane, on most operation systems there is NO WAY for userspace to be sure how long it will take for an IP packet to be transmitted.

Henning Rogge

---

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

> But I think we currently have the balance about right. And I read you as agreeing.

I remember a Bufferbloat discussion where someone measured a delay of
30 seconds on LTE... just because there was a long, full and unmanaged
queue in the way.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 18 Apr 2016 14:03:12 +0200

On Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge <[email-masked]> wrote:

> > So far I see one specific point for WG agreement - anything else is
> editorial. (Editorial matters, but it's not changing rules, so I'm trying
> here to address one specific rule issue.) Some comments have clearly
> overlooked this, but whether to telegraph it further (e.g. mention in
> non-normative introduction) is back to editorial.
> >
> > Should we change that SHOULD to a MUST? Obviously IETF-style we don't
> run votes as such, but what are people's opinions?
>

IMO, I think it is not efficient to delay messages, I think it is strange
to delay without saying how much that multiplexer is delaying to get to
efficiency, so it seems that multiplexer efficiency is needed to be defined
because it can be different than protocol efficiency.

Therefore, I think we should change MAY to may and SHOULD to should, or if
not changed we need to specify a maximum delay for the multiplexer, because
leaving it without limit is not correct.

> > Argument for SHOULD: But the protocol might make an impossible demand,
> such as zero delay when we all know nothing has zero delay. SHOULD isn't
> MAY, it needs to do its best.
> >
> > Possible third course, something like (open to wordsmithing - I
> considered putting the caveat at the end, for example).
> >
> > Argument against third course, we've seen before that anything that
> includes wording like that is open to IESG not being happy.
> >
> > On balance, I think SHOULD is appropriate, assuming SHOULD is
> interpreted as it should be - do this unless there really is a good reason
> not to. But I could live with any of the three (if allowed).
>

IMO, It should say that the multiplexer MUST NOT delay messages if the
protocol request constraints on delay. We don't want to change the
multiplexer into having its own protocol without having a RFC for it.

AB

---

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

Multiplexer efficiency is straightforward - if you put two messages in one packet you save a packet transmission. On some MACs as long as packets are of reasonable size, the packet size is pretty irrelevant, only the number of packets matters.

There’s a good synergy of this with RFC 5148 if you are using that, but that’s not the subject here.

And as for changing to lower case, don’t do that. It is overwhelmingly good practice that in normative sections of a report, use MAY, SHOULD,. MUST etc. as 2119 terms and avoid all other use of those words. But here, as I have said, I think SHOULD is appropriate.

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

www.baesystems.com/ai<http://www.baesystems.com/ai>

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 18 April 2016 13:03
To: Henning Rogge
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] RFC 5444 usage - one specific point.

*** 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>.

On Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Apr 18, 2016 at 11:07 AM, Dearlove, Christopher (UK)

IMO, I think it is not efficient to delay messages, I think it is strange to delay without saying how much that multiplexer is delaying to get to efficiency, so it seems that multiplexer efficiency is needed to be defined because it can be different than protocol efficiency.
Therefore, I think we should change MAY to may and SHOULD to should, or if not changed we need to specify a maximum delay for the multiplexer, because leaving it without limit is not correct.

IMO, It should say that the multiplexer MUST NOT delay messages if the protocol request constraints on delay. We don't want to change the multiplexer into having its own protocol without having a RFC for it.
AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 18 Apr 2016 18:14:46 +0200

IMO. The number of packets is not the only thing that multiplexer should
look into but the time is important as well. The draft may need to show
efficiency not only looking at number of packets sent but also number of
messages in a packet. The draft must mention the delay of multiplexing if
it is stating efficiency, however, it is delaying packets not messages.
Therefore, the texts mentioned in your message needs to say that
multiplexer may delay packets. However, there is a need to determine this
in the draft.

AB

On Mon, Apr 18, 2016 at 2:12 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Multiplexer efficiency is straightforward - if you put two messages in one
> packet you save a packet transmission. On some MACs as long as packets are
> of reasonable size, the packet size is pretty irrelevant, only the number
> of packets matters.
>
>
>
> And as for changing to lower case, don’t do that. It is overwhelmingly
> good practice that in normative sections of a report, use MAY, SHOULD,.
> MUST etc. as 2119 terms and avoid all other use of those words. But here,
> as I have said, I think SHOULD is appropriate.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> *From:* Abdussalam Baryun [mailto:[email-masked]]
> *Sent:* 18 April 2016 13:03
> *To:* Henning Rogge
> *Cc:* Dearlove, Christopher (UK); [email-masked]
> *Subject:* Re: [manet] RFC 5444 usage - one specific point.
>
>
>
>
>
> **** 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>.*
>
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Apr 2016 16:17:26 +0000

The draft already says that a multiplexer may delay packets. Hence by obvious implication it may choose not to. It says it might delay for efficiency. Obviously it would not delay if the tradeoff were deemed unsatisfactory. Part of the latter is that the protocol might choose to make a suggestion as to what matters to it.

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 18 April 2016 17:15
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] RFC 5444 usage - one specific point.

*** WARNING ***
IMO. The number of packets is not the only thing that multiplexer should look into but the time is important as well. The draft may need to show efficiency not only looking at number of packets sent but also number of messages in a packet. The draft must mention the delay of multiplexing if it is stating efficiency, however, it is delaying packets not messages. Therefore, the texts mentioned in your message needs to say that multiplexer may delay packets. However, there is a need to determine this in the draft.
AB

On Mon, Apr 18, 2016 at 2:12 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Multiplexer efficiency is straightforward - if you put two messages in one packet you save a packet transmission. On some MACs as long as packets are of reasonable size, the packet size is pretty irrelevant, only the number of packets matters.

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

From: Abdussalam Baryun [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 18 April 2016 13:03
To: Henning Rogge
Cc: Dearlove, Christopher (UK); [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] RFC 5444 usage - one specific point.

*** WARNING ***