[aodvv2-discuss] Fwd: Re: Fwd: [manet] A few more AODVv2 comments
- From: Lotte Steenbrink <lsteen@xxxxxxxxxxxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Thu, 26 Mar 2015 10:26:46 +0100
Hi everyone, it seems that my E-mail didn't get through to the list yesterday
:( it's too late now, but for the sake of completeness... I'm trying again.
Anfang der weitergeleiteten E‑Mail:
> Von: Lotte Steenbrink <lsteen@xxxxxxxxxxxxxxxxxx>
> Datum: 24. März 2015 19:06:41 MEZ
> An: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
> Betreff: Re: [aodvv2-discuss] Re: Fwd: [manet] A few more AODVv2 comments
>
> Hi,
> Again, nitpicking just before the deadline:
>
> Section 10: it's called extension type, not extension byte
>
> The general tone of the document seems to indicate that hop count is still
> special and can be omitted, while the change in section 9.2.1, point 4 seems
> to suggest otherwise...same for the change in S9.3.3., point 3.
> (For the record, I'm still in favor of setting the value for Hopcount from 3
> to 0 and making it mandatory as an extension type just like any other metric,
> but even if that's not going to happen I' like our solution to be consistent
> :) )
>
>
> Cheers, Lotte
>
>> Am 20.03.2015 um 02:07 schrieb Charlie Perkins
>> <charles.perkins@xxxxxxxxxxxxx>:
>>
>> Due to operator error, that version did not show the replacement of "general
>> format:"
>> by "general structure:", sorry about that.
>>
>> Regards,
>> Charlie P.
>>
>>
>>> On 3/19/2015 5:48 PM, Charlie Perkins wrote:
>>> Hello Vicky and all,
>>>
>>> Attached, please find a revised text incorporating most of the suggested
>>> changes. I have to leave right now, so unfortunately I have not proofread
>>> the results but I wanted to send it out to you. I did not change the
>>> pseudocode in the Appendix, which needs to be done.
>>>
>>> I am sick. Bad timing. I hope to be well before stepping onto the airplane
>>> tomorrow.
>>>
>>> Regards,
>>> Charlie P.
>>>
>>>
>>>> On 3/19/2015 4:52 AM, Victoria Mercieca wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> This could be changed to say "Lower layer trigger that a link is no
>>>>> longer bidirectional"
>>>> or "Lower layer triggers, for example message reception or link status
>>>> notifications".
>>>> The fact we are receiving L2 frames could be seen as a confirmation of
>>>> bidirectionality?
>>>
>>> Done.
>>>
>>>>>>
>>>>>>
>>>>>> I would have explicitly said NHDP HELLO message, not just message later
>>>>>> in that section (though it is the only NHDP message).
>>>>>>
>>>>>
>>>>> That enlargement fits well in Section 4 during the discussion where NHDP
>>>>> is mentioned, and I put it there.
>>>> Easily added in the list though?
>>>
>>> I didn't think it fit nicely into that list, but on your recommendation I
>>> put it there also.
>>>
>>>>>>
>>>>>> Blacklist removal seems to be MAY at one point, and SHOULD at another.
>>>>>>
>>>>>
>>>>> Fixed.
>>>>>
>>>>>> Also that’s discussing things that trigger additions to blacklists (e.g.
>>>>>> failure to receive RREP_Ack) and removals due to timeouts. Might there
>>>>>> not also be specific reasons to remove from blacklists (e.g. receiving
>>>>>> NHDP HELLO that indicates that if using that option)?
>>>>>>
>>>>> Yes, this is a good point.
>>>> True, we have already put in that if RREP_Ack is received from a router on
>>>> the blacklist, it is removed from the blacklist. Maybe in Section 6.2
>>>> where we discuss adding to the blacklist if we receive notification of a
>>>> non-bidirectional link, we also mention "If any of these triggers signal
>>>> that bidirectional connectivity exists to a blacklisted router, the router
>>>> can be immediately removed from the blacklist." or something similar?
>>>
>>> Done.
>>>
>>>
>>>>>> It seems rather a lack of progress that we are still at the only form of
>>>>>> metric that an implementation will know what to do with is a hop count.
>>>>>>
>>>>>
>>>>> That's not true. It is known how to use other metrics, and in fact
>>>>> specifications for AODV were written for the other metrics. However
>>>>> those specifications have been considered to be out of scope for the base
>>>>> document.
>>>>>> Well, almost. Most of the discussion of metrics appears to require only
>>>>>> an increasing function. Except the penultimate bullet in the first list
>>>>>> in Section 8.1 appears to be explicitly additive. Once you decide on
>>>>>> additive, you can make the whole metrics decision much more open.
>>>>>>
>>>>>
>>>>> Having gone to the trouble of including mechanism for alternative
>>>>> metrics, it would seem a shame to make such a severe restriction.
>>>>>
>>>> Is it enough to say that the current draft will support any additive
>>>> metric / increasing metric, using Cost(R) = AdvRte.Metric + Cost(L), where
>>>> Cost(L) > 0, but also that LoopFree may be further optimised for other
>>>> metrics? Not mentioning specific metric types but making it extra clear
>>>> that its possible with the current spec to use a different metric. Note -
>>>> our Section 7.4 doesnt actually say a different LoopFree may also be
>>>> required.
>>>
>>>
>>>>>> I’d go with Henning’s suggestion to fix a single data type (32 bit
>>>>>> integer perhaps) which would replace the second paragraph of 7.4 and
>>>>>> make things much more easily extensible.
>>>>>>
>>>>>
>>>>>
>>>>> A single data type for metric cannot accurately represent the costs of
>>>>> the routes. All you can get is monotonicity. Or maybe I misunderstand?
>>>>>
>>>>>> Section 8.1, from the numbered points onwards, appears to give three
>>>>>> descriptions of how you handle competing routes. One is good, if
>>>>>> completely rigorous. Two is fine if the other one is more human readable
>>>>>> (and possibly belongs in an earlier section). Three appears more than is
>>>>>> wanted. (I also note the use of both AND and && in the second.) Note
>>>>>> that I haven’t actually checked if all three are consistent (that’s not
>>>>>> trivial when they switch between formulae and terms like stale) let
>>>>>> alone if they work. (I recall someone has done some work on the latter
>>>>>> point, is that published/referenceable?)
>>>>>>
>>>> I agree with this, and perhaps the pseudo-code version is better left in
>>>> the appendix in A.1.1? And we may not need the summary at the end of 8.1?
>>>> We do have inconsistency with where LoopFree is checked. It is step 3 in
>>>> section 8.1, which means it is currently not checked if the advertised
>>>> route is lower cost, and is only checked if its repairing an invalid route.
>>>
>>> Well, actually, that's pretty much right. I'm not sure about deleting the
>>> summary.
>>> Any summary can be viewed as duplicative. However, there are people in the
>>> world
>>> who like to get an overall understanding of what's going on, even at the
>>> cost of a
>>> few sentences.
>>>
>>>> But in the appendix we check LoopFree first before even checking SeqNum. I
>>>> suppose the correct thing would be to check it after determining the
>>>> incoming information is not stale.
>>>
>>> Not really, because if the information is not stale and the cost is less we
>>> want to
>>> use the route without calling LoopFree().
>>>
>>>
>>>> Suggestions:
>>>>
>>>> 8.1:
>>>> Switch step 2 and 3.
>>>> Add in to the new Step 2: "If LoopFree returns true, continue to step 3."
>>>> The final point in the new Step 3 should be: "If the advertised route's
>>>> cost is the same or greater than the stored route, but the stored route's
>>>> state is Invalid, the advertised route can be used to repair the Invalid
>>>> route, since it has been proven LoopFree in step 2."
>>>> Remove the rest of the section. At least remove the pseudo-code since this
>>>> is slightly inconsistent as is, and is present in a more accurate form in
>>>> the appendix.
>>>>
>>>> A.1.1:
>>>> /* rules from 8.1 */
>>>> if (AdvRte.SeqNum < Route.SeqNum) /* advertised route is stale */
>>>> return null;
>>>>
>>>> if (!LoopFree(advRte, rte))
>>>> { /* incoming route cannot be guaranteed loop free */
>>>> return null;
>>>> }
>>>>
>>>> if (
>>>> (advRte.SeqNum > Route.SeqNum) /* stored route is stale,
>>>> use advRte */
>>>> OR
>>>> ((advRte.SeqNum == Route.SeqNum) /* same SeqNum */
>>>> AND
>>>> [(advRte.Cost < Route.Metric) /* advRte is better */
>>>> OR
>>>> ((Route.State == Invalid))] /* advRte can repair stored
>>>> */
>>>> {
>>>> Update_Route_Table_Entry (rte, advRte);
>>>> }
>>>>
>>>>
>>>>> One publication is cited. Another publication about AODVv1 would still
>>>>> be valid and could be cited.
>>>>>> Section 8.3 first paragraph I think would be better separating out
>>>>>> AODVv2 from IP. Whether to forward a packet is a decision made
>>>>>> consulting IP’s table, not AODVv2’s use of invalid. I think that means
>>>>>> you should indicate that invalid routes should be struck from IP’s table.
>>>>>>
>>>>> Well, not exactly, because invalid routes still contain valid sequence
>>>>> number information.
>>>> So we have a local table which includes all the routes, including Invalid
>>>> ones, and we insert or remove entries in the main IP routing table
>>>> depending on state, so that the IP routing table contains all the AODVv2
>>>> routing table's Active and Idle routes but not the Invalid ones.
>>>
>>> That is not enforced by the specification. In our implementation we
>>> modified the
>>> IP route table, and it is by no means incorrect to do so.
>>>
>>>
>>>>>>
>>>>>>
>>>>>> Third paragraph in 8.3 precursor table appears from left field. (Unless
>>>>>> I’ve missed an earlier reference, I haven’t done an electronic search).
>>>>>> While postponing details is fine, the fact that there is such a thing,
>>>>>> related to a route, and might matter, wants flagging up earlier. At the
>>>>>> least indicated as a possible addition in Section 6.1.
>>>>>>
>>>>>
>>>>> The precursors are indeed mentioned as an optional part of the route
>>>>> table entry. I added a cross reference in section 6.1 also. What more
>>>>> should be done? It was earlier thought that specification details about
>>>>> optional features should be in the optional section. For myself, I think
>>>>> the feature is important enough to belong in the main body of the text,
>>>>> but I had earlier been requested to describe it as optional ...
>>>> Maybe to soften it, change to "Implementations which support the optional
>>>> feature of precursor lists as described in Section 12.2 MUST also expunge
>>>> the route's precursor list at the time that the route itself is
>>>> expunged."? Or is this an implementation detail we dont really need to put
>>>> here? We could have a Delete_Route_Table_Entry in the appendix where we
>>>> stress that the precursors list should be expunged?
>>>
>>> I don't really see what's wrong with keeping normative text about
>>> precursors in
>>> the section about precursors, and can't understand moving it to an appendix.
>>>
>>>
>>>>>>
>>>>>>
>>>>>> Section 8.4 invalid route may be expunged. What’s the intended status of
>>>>>> the least recently used comment? Is that a may within a may, or a should
>>>>>> within a may (you may do this, if you do, you should do it that way), or
>>>>>> just a suggestion?
>>>>>>
>>>>>
>>>>> It is a MAY and a SHOULD within the MAY.
>>>> Does this make that clearer: "Any Invalid route MAY be expunged, but the
>>>> least recently used Invalid route SHOULD be expunged first."?
>>>
>>> I used a slightly modified version of your text. But
>>> really the existing text was pretty unambiguous.
>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>> The binary exponential backoff on page 25 needs more about what is and
>>>>>> is not proposed (and how its parameters – not specified – relate to
>>>>>> other parametesr).
>>>>>>
>>>>>
>>>>>
>>>>> Here is the text from RFC 3561:
>>>>> To reduce congestion in a network, repeated attempts by a source node
>>>>> at route discovery for a single destination MUST utilize a binary
>>>>> exponential backoff. The first time a source node broadcasts a RREQ,
>>>>> it waits NET_TRAVERSAL_TIME milliseconds for the reception of a RREP.
>>>>> If a RREP is not received within that time, the source node sends a
>>>>> new RREQ. When calculating the time to wait for the RREP after
>>>>> sending the second RREQ, the source node MUST use a binary
>>>>> exponential backoff. Hence, the waiting time for the RREP
>>>>> corresponding to the second RREQ is 2 * NET_TRAVERSAL_TIME
>>>>> milliseconds. If a RREP is not received within this time period,
>>>>> another RREQ may be sent, up to RREQ_RETRIES additional attempts
>>>>> after the first RREQ. For each additional attempt, the waiting time
>>>>> for the RREP is multiplied by 2, so that the time conforms to a
>>>>> binary exponential backoff.
>>>>>
>>>>> Would that be sufficient?
>>>> "SHOULD utilize a binary exponential backoff as described in RFC 3561." ?
>>>> Or:
>>>> "SHOULD utilize a binary exponential backoff where the wait time is
>>>> doubled for each retry based on an initial value of RREQ_WAIT_TIME."
>>>
>>> SHOULD utilize a
>>> binary exponential backoff, as described in <xref target="RFC3561"/>,
>>> where the initial wait time is RREQ_WAIT_TIME and the
>>> wait time is doubled for each retry based.
>>>
>>>>>>
>>>>>>
>>>>>> I’m not at all sure about the packet queuing comments. Do we have good
>>>>>> experience here? Is affixed buffer right? Is that “usually positive”
>>>>>> comment known to be so? I know enough about buffering to know I don’t
>>>>>> know enough about buffering, and that there are some counterintuitive
>>>>>> results in the field.
>>>>>>
>>>>>
>>>>> I have had quite a bit of experience with buffering. This draft is not
>>>>> the place to review those results,
>>>>> but one thing for sure is that TCP session initiation packets ought to be
>>>>> buffered.
>>>>>
>>>>>>
>>>>>>
>>>>>> I haven’t read section 9 in any detail yet, but I will note that figure
>>>>>> 1 is really about message contents, not message structure (or format).
>>>>>
>>>>>
>>>>> The contents of the message are organized according to the structure in
>>>>> the figure. We could mix up the contents in any order, and they
>>>>> would still truthfully be the contents. The ordering of the contents
>>>>> follows the structure as shown. I'm not sure how to make this clearer.
>>>> I agree with you, it mirrors what the RFC5444 message will look like, and
>>>> this is why we explain the messages in this order. Maybe using the word
>>>> "format" makes it seem like this should be more specific, but it's for
>>>> RFC5444 to handle the specifics of the format. We could replace "have the
>>>> following general format:" with "have the following contents:" and it
>>>> would appease Chris here without really making much difference? The reader
>>>> gets the idea of the message structure anyway from the way we've written
>>>> the rest of the section.
>>>
>>> First, let's try replacing "general format" by "general structure" and see
>>> if he likes it.
>>
Other related posts:
