Hello Vicky,
I have already agreed that if RFC 5444 handles MTU problems, then we are
good.
Given past history, I thought it would be prudent to find out, if we
really wanted
to enable proper operation of AODVv2.
Even if we don't specify it, implementers will. Some will get it wrong.
But we'll be done! Who knows, maybe it's best to just not say anything and
hope the IESG doesn't notice.
As a protocol designer, I believe we really should avoid fragmentation.
In the field, pointing the finger at RFC 5444 will be pointless (so to
speak).
Regards,
Charlie P.
On 11/23/2015 2:35 PM, Victoria Mercieca wrote:
Hi Charlie,
The bit that clarifies it for me is:
"The writer has to deal with the problem of MTU size of interfaces to fragment the messages correctly."
I take from that, that AODVv2 doesn't need to know the MTU and that RFC5444 is capable of understanding the MTU and fragmenting messages that are too long. If it wasn't capable of this, anyone could break RFC5444 by giving it too much information to send.
In the end, an RFC5444 message is a set of addresses with associated TLVs. RFC5444 doesn't need to understand what the RERR is and how it's used. It sees it as a set of (address + TLVs) which can easily be divided into messages, however RFC5444 deems fit. And probably even reassembled at the receiving end before giving it to AODVv2.
Regards,
Vicky.
On 23 Nov 2015 20:05, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
One has to wonder how OLSRv2 derives the MTU constraints...
And how does an implementation of NHDP go about limiting the
information?
SMF is Experimental.
LOADng is inadequate in many ways.
The maximum message size which Henning mentions is exactly what I
think needs to be specified.
If, for instance, an RFC 5444 implementation does this correctly
and provides a maximum message size,
it is this size which AODVv2 needs to respect when creating
protocol messages. If an implementor has
to use an RFC 5444 implementation that fails to specify this
constraint, then some choice has to be made
according to the most likely MTU at layer 3.
I am very skeptical that RFC 5444 will know a lot about RERR
messages to handle them correctly.
Stan, I hope we can have a reasonable discussion about this. I
feel like my cheerleading team is too small.
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 email
in error, please delete it and immediately notify the sender.
_____________________________________________________
