Hello folks,
MTU handling is not specified in RFC 5444. I think that is a mistake,
and should be corrected, but that's the way it is right now.
It will not hurt to identify this requirement on the mandated platform.
It is needed for correct operation.
Right now all we have is a (!non-normative!) reference buried somewhere
in a mail message in a universe far far away.
Vicky, regarding the OLSRv2 quote:
OLSRv2 only says "One or more messages sent by a router at the same time SHOULD be combined into a single packet, subject to any constraints on maximum packet size (such as derived from the MTU over a local single hop) that MAY be imposed."
clearly an RFC5444 responsibility and nothing said about exceeding the MTU,
Hi Charlie and all,
Hello Vicky and all,...So you're asking us to make demands about the quality of the
I am looking at the second paragraph of section 6.5:
When multiple interfaces are available, an AODVv2 router transmittingI would like to add a sentence to this paragraph stating, in effect, that
a multicast message to LL-MANET-Routers MUST send the message on all
interfaces that have been configured for AODVv2 operation, as given
in the AODVv2_INTERFACES list (Section 4.1). Similarly, AODVv2
routers MUST subscribe to LL-MANET-Routers on all their AODVv2
interfaces.
proper operation of AODVv2 relies on correct setting of the MTU handling
by RFC 5444. Perhaps exactly that:
Operation of AODVv2 relies on correct setting of the MTU handling
for RFC 5444.
implementation of another RFC? I don't think that's in our jurisdiction.
If somebody's RFC5444 implementation can't handle unexpected MTUs, they
should consult their debugger, not to the specification of a higher-layer
protocol.
Regards,
Charlie P.
On 11/23/2015 10:40 AM, Victoria Mercieca wrote:
Hi all,
I did a quick search through the IETF pages. From the main IETF
documents referencing RFC 5444:
* OLSRv2 only says "One or more messages sent by a router at the
same time SHOULD be combined into a single packet, subject to any
constraints on maximum packet size (such as derived from the MTU
over a local single hop) that MAY be imposed." - clearly an
RFC5444 responsibility and nothing said about exceeding the MTU,
* SMF did not mention MTU at all,
* NHDP says "An implementation of this protocol MAY limit the
information included in each HELLO message, for example, to
accommodate smaller MTU sizes."
* LOADng makes no mention of MTU.
So we shouldnt need to mention it, in my opinion.
Also see
https://github.com/benpicco/oonf_api/blob/master/docs/rfc5444/rfc5444_writer.txt
where Henning Rogge appears to make a comment (point 1.4) about MTU
and the RFC5444 writer:
The writer has to deal with the problem of MTU size of interfaces to
fragment the messages correctly. Each outgoing interface might have its
own MTU, but even making sure that all generated messages will fit into
the smallest interface MTU used for the message might not enough. If
there
are interfaces somewhere in the MANET with a smaller maximum message
size
(either because of a small MTU of the link or a large amount of packet
TLVs for this link), all messages in the whole MANET must be small
enough
to fit through this bottleneck.
Because of this you have to specify a maximum message size (in bytes)
when initializing the writer AND specify a MTU for each registered
interface.
Is that enough of an answer?
Kind regards,
Vicky.
On Mon, Nov 23, 2015 at 6:14 PM, Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>> wrote:
Charlie,
I’m not sure what you mean when you say “this needs to be
verified”. Verified, as in “someone needs to go off and re-read
5444”? Or as in “some additional testing needs to be done”? Or,
“algorithmically, routing protocols on top of 5444 need to be able
to check on a message-by-message basis”? I’m OK with the first
one, but “not-so-much” with the second, and I’m opposed to the
third.
As to your last question – obviously, other protocols care about
MTU. That’s self-evident. But other protocols don’t run on top of
5444. A reasonable, apples-to-apples comparison here would be BGP.
I don’t recall (though I could have missed something) BGP being
worried about segmenting of control plane messages, since it (BGP)
relies on TCP to carry the traffic. The same notion applies here –
we’re relying on 5444. Not necessarily because we want to, but
because it has been mandated that we have to.
The fact that I see this (running over 5444) as a rather sucky
requirement doesn’t mitigate the fact that it’s a requirement.
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>] *On Behalf Of
*Charlie Perkins
*Sent:* Monday, November 23, 2015 12:41 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:* [aodvv2-discuss] Re: Draft 13c
Hello Stan,
If you are going to make assumptions about what RFC 5444 does,
then I think
this needs to be verified.
Do you disagree that other protocols have been required to care
about MTU?
Regards,
Charlie P.
On 11/23/2015 9:05 AM, Stan Ratliff wrote:
A couple of comments inline.
On Mon, Nov 23, 2015 at 11:56 AM, Victoria Mercieca
<vmercieca0@xxxxxxxxx <mailto:vmercieca0@xxxxxxxxx>> wrote:
Hi Charlie,
Thanks for the quick reply :o) Comments in line:
On Mon, Nov 23, 2015 at 4:28 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
Thanks for your responses! I have some more follow-up
below.
On 11/23/2015 7:35 AM, Victoria Mercieca wrote:
Hi Charlie,
Thanks for looking over the changes.
Comments in-line:
On Mon, Nov 23, 2015 at 2:02 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
I have a few comments on draft 13c, but based
only on the highlighted
sections from the Diff file. That way of
commenting has limitations that
result when whole sections of text are moved.
It then becomes difficult
to compare those sections for changes.
Which is why I chose to move the section, after I
made the changes which were identified in the
previous diff. However there were some small
changes at the same time as I changed the section
order this time, so I apologise for that.
No problem, it just means that I will make a separate
set of comments slightly later.
Plus I didn't compare draft 13c against draft
12. I fear that will be
pretty difficult. I miss the "Changes"
section, which had been kept up
to date in previous revisions.
The Changes section is not gone, it was just
unnecessary for it to contain changes between
every version of the draft we ever released. I
have omitted to keep it up-to-date in the minor
updates, but I will update it correctly before
releasing a version 13 to MANET.
O.K. I realize that my comment sounds like a
complaint, whereas I intended it to
be more of an explanation why my commentary should be
considered incomplete.
Multiple valid routes for the same address
and prefix length but
different metric type may exist in the
Local Route Set, but the
decision of which of these routes to
install in the Routing
Information Base to use for forwarding
is outside the scope of
AODVv2.
This is written under the presumption that the
RIB cannot contain
multiple routes for the same destination.
However, I do not think
we should presume that. It is perfectly
reasonable to have a RIB
that includes the metric type as a selector.
I dont interpret this text in the same way. "which
of these routes to install" does not mean that
only one may be installed.
Yes, I see that your interpretation is reasonable. I
forgot that "which" can be plural.
AODVv2 MUST NOT store routes that cost
more than
MAX_METRIC[MetricType].
Somehow this loses the perhaps important
information that
typically MAX_METRIC would be chosen to be the
maximum
value that is representable. Mandating
something that is not
possible to violate is like saying the speed
of light MUST NOT
exceed some constant value usually denoted as
'c'.
Of course its possible to violate - when you add
incoming metric to the link cost. OK, the actual
comparison is "advertised cost < MAX_METRIC - link
cost", but saying "MUST NOT store routes that cost
more than MAX_METRIC" is perfectly readable. Would
you prefer "MUST NOT attempt to store routes that
cost more than MAX_METRIC"?
Well, if MAX_METRIC were 255 for an unsigned character
value, it would be "cannot".
And, in fact, beneath Table 3 we have the following
text:
MAX_METRIC[MetricType] MUST always be the maximum
expressible metric
value of type MetricType. Field lengths
associated with metric
values are found in Section 11.6.
Following this mandate, MAX_METRIC would be 255 and
*not equal to* MAX_HOPCOUNT.
I would be happier if we did adhere to the quoted
paragraph.
So MAX_METRIC[HopCount] = 255, and "AODVv2 cannot store
routes that cost more than MAX_METRIC[MetricType]."
If such an external process signals that
the link is bidirectional,
the value of Neighbor.State MAY be set
to Confirmed.
The previous formulation was quite a bit more
readable and, thus
in my opinion, better. Perhaps for the most
pedantic reviewers,
we could insert a definition something like:
mark a neighbor as Blacklisted
set Neighbor.State to the value Blacklisted
and go back to more readable language.
This hasnt actually changed since version 12. Also
your comment does not apply to the sentence you
have quoted. What would you like the "If such an
external process..." sentence to say?
It could say:
If such an external process signals that the
link is bidirectional, mark
the neighbor as Confirmed.
I dont like this. I'm sure in the past we have been
criticised for using text like "mark the neighbor as
confirmed" when the exact thing it needs to say is "set
Neighbor.State to Confirmed".
It is currently very clear exactly what needs to
happen. In the later sentence, it seems overkill
to say "update the matching Neighbor Table entry
by marking the neighbour as blacklisted, by
setting Neighbor.State to the value Blacklisted".
How about:
blacklist the matching Neighbor Table entry
or even:
blacklist the matching neighbor
This is not an important point. And, the more details
that are added will
certainly cause it to be even less probable that a
careful reader would take
the wrong interpretation. However, at some point I
hope that we can
take some decisions in the direction of improved
readability, even at the
cost that a determined misinterpreter can find
misinterpretation.
Again, what specifically needs to be done to blacklist it,
is to set Neighbor.State to Blacklisted. I dont think we
need to be wordier.
If one relies on the actual definition of
"SHOULD" and "MUST", then
I think the changes in section 6.9.2 are
ill-advised.
When LocalRoute.State changes from Active
to Invalid as a result of a
broken link or a received Route Error
(RERR) message, other AODVv2
routers MUST be informed by sending an
RERR message containing
details of the invalidated route.
The MUST should be a SHOULD. This is because
(a) interoperability is
not affected and (b) if the system designer
has a better mechanism to
notify for errors, we should not penalize that
design and (c) for some
systems, routes may only be used once or only
upon rare occasions.
So we dont have to report when routes are broken?
These are active routes, therefore they are in
use, so we need to report them!!!
We dont say that we should report routes that
become invalid due to timeouts, do we? I think
your comment applies in that case, but I dont
think we mention reporting timed out routes!
You are reacting against a definition of "SHOULD" that
seems to be contrary to
what is specified in RFC 2119. There, "SHOULD" means
"MUST" -- unless you have
a better way. Usually, such formulations are
allowable in order to cause diligent
implementers to improve the performance of the
implementation without
causing the result to be non-conformant.
If there is no cost in interoperability, and if
another design can work better than
what is recommended for AODVv2 in particular
circumstances, then RFC 2119
allows us to enable that better design by specifying
"SHOULD" instead of "MUST".
3. SHOULD This word, or the adjective "RECOMMENDED", mean
that there
may exist valid reasons in particular circumstances to
ignore a
particular item, but the full implications must be
understood and
carefully weighed before choosing a different course.
This doesnt look to me like it means "if you have a better
way". I still think we MUST report broken routes.
I dont see a good reason to 'ignore this particular item'.
What other design might work better? We need to
report broken routes which are in use. Otherwise routers
keep using them, and packets keep getting dropped
and no-one knows!
Bravo, Vicky. IMO, this MUST stay a MUST.
In section 7.4.2. RERR Reception:
1. Update the Neighbor Table according to
Section 6.3
It's probably a good idea. Could you describe the
expected improvement?
Well, doesn't it make sense to put an entry in the
Neighbor Table when you receive a message from a
neighboring router? Maybe we dont need it for
RERR, I was trying to be consistent.
Oh, I was not complaining... on the contrary! I was
just wondering if you had
something particular in mind...
------------------
Regarding the deletion of MTU-related mandates:
This is a bad idea. Even TCP is built to
respect MTU considerations. It is
especially a bad idea to avoid mentioning MTU
when specifying RERR.
If necessary, I could find quite a few
examples in other RFCs where MTU
dictates certain size restrictions.
I'm pretty sure the RFC 5444 authors don't
want to be saddled with
creating multiple RERR messages when AODV
makes one that is too long.
Fragmentation has its own pitfalls, well known
in the Internet.
Please reconsider this. Were there complaints
about it??
John made a very valid point on this topic in his
review on November 4th, and we discussed it in a
few further emails. How can we know when we hit
the MTU since RFC5444 is creating the message, we
are just giving it contents. We are giving RFC5444
"message header info" + (however many routes we
are reporting) * ("address + associated TLVs").
RFC5444 is best placed to determine when to create
a second message, since we dont know how RFC5444
is going to arrange our information. To create a
second RERR, all it needs to do is use the same
"message header info" and include a separate set
of "address + associated TLVs". I dont imagine
this will be too difficult.
If RFC 5444 wants to specify this behavior, my opinion
of RFC 5444 will
approximately double in the positive direction. In the
meantime, please
verify with them that it will work as we need.
If not, then we have to specify the proper behavior to
avoid fragmentation.
How can we? When we dont know how the information we give
to RFC5444 will be presented in its packet format?
Basically, we're in the position of relying on RFC5444 to
carry the signaling traffic. If we're going to trust 5444 to
carry the traffic, we (by necessity) MUST trust 5444 to handle
segmentation/reassembly of AODVv2 control messages. Vicky is
correct - we don't know the segment size on the 5444
connection, and by definition, we cannot know. The current
text, minus the MTU restrictions, is the correct approach,
given the requirement to run over 5444.
Stan
I don't remember that the MTU specification was an
issue raised against
AODVv2. Can you tell me if it was something in one of
the latter reviews?
It was a specific comment from a quite thorough review by
John, in his email dated 4th November.
Regards,
Charlie P.
Regards,
Victoria.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this
in error, please delete it and immediately notify the sender.
_____________________________________________________
