[aodvv2-discuss] Re: Questions - Miscellaneous

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 16 Apr 2015 09:23:11 -0700


Hello folks,

I hope we can have a teleconference soon -- tomorrow would be O.K. with me.

Comments below...

On 4/14/2015 10:42 AM, Victoria Mercieca wrote:



This email is the miscellaneous comments.

* Buffering - we state that there are positive and negative effects
- should we make this statement if we aren't going to explain it?
We already had one comment about this from Chris Dearlove


It is O.K. with me to leave it as is. If you want to include explanations, here are some examples:
Negative: real-time traffic, scheduled delivery, voice
Positive: almost anything using TCP

* For RREQ, in the text we say 'set metric =
Route[OrigAddr].Metric'. In the Appendix we say 'set to zero by
default, or MIN_METRIC[MetricType]'. Should we change one, or the
other, or explain that Route[OrigAddr].Metric is in fact zero or
MIN_METRIC, since the OrigAddr is on one of the router's
interfaces? Same for TargAddr in RREP.


The intention is to enable the AODVv2 router to set a nonzero metric for one of its clients. This can be considered the non-default case.


* The Route.Timed flag - this seems a bit redundant. If a route is
not timed, its expiration time is MAX_TIME, so cant we use
route.ExpirationTime != MAX_TIME to check if the route is timed?


This is O.K. with me. I think it used to be that way a long time ago.

* Should MessageType be part of each message when we draw the
diagrams? Its a RFC 5444 message header field, like hop count and
hop limit, which we do show in the diagram.


Either way is O.K. with me. It's probably better to leave it out, because it does not add any information.

* Should we use ":=" or just "="?


I think ":=" is way better in pseudocode and in algorithms. There is a strong difference between asserting equality and specifying assignment.


* Should we use CurrentTime or Current_Time. Most of our values use
ThisNotation rather than This_Notation.


Whatever people think is more readable. Readability is often improved by consistency, but not always.

* Can we rename OrigAddrMetric and TargAddrMetric to OrigMetric and
TargMetric to simplify a little? We already renamed OrigAddrSeqNum
and TargAddrSeqNum to OrigSeqNum and TargSeqNum.


That's fine with me.

* Can we try to avoid using "List" when there's only one thing in
it? PrefixLengthList, SeqNumList, MetricList, ValidityTimeList in
RREQ and RREP. Lotte's notation might be useful to try to work in
(e.g. add this address with these TLVs, next address with these
TLVs) - definitely needs some thought.


I am O.K. with whatever people find easiest to understand. I thought about changing
tothe suggested format, but didn't get around to it. It's a pretty big textual change.

* RERR for broken link - I haven't yet changed anything about each
metric type requiring a separate message. If anyone has
suggestions then I welcome them.


I thought the text was already there. I'll go have a look in a few minutes.

* RFC5444 section - not yet updated the layout to reflect Lotte's
recent email.


I'm behind, but hope to catch up one by one this morning.

* Security section

1. Changes to the security section will impact the Overview and
the Applicability sections (and maybe more). We need to be
careful that we dont end up with any conflicting statements.
2. Contemplating moving this section to flow nicely from the rest
of the text - before the IANA section and maybe before the
"configuration parameters" section, maybe even before Optional
Features? Any objections?


(1) Point noted... (2) Most of the RFCs have the Security Considerations quite late
in the text. Moving it forward might be considered weird, I don't know.


* Appendices

1. Considering renaming "Features of IP needed by AODVv2" to
"Features Required of IP" - any objections?
2. Considering renaming "Shifting Network Prefix Advertisement
Between AODVv2 Routers" to "Router Client Mobility" - any
objections?


I don't care about the first one, but the second one does not have to involve "Mobility".
It could be load balancing by the gateways. You might say "Relocation" instead.

* Did we reach a decision on Addresses without TLVs attached?
Lotte's conversation with Henning pointed out that we should not
identify an Address by the lack of a certain TLV associated with
it. So should we always add both OrigSeqNum TLV and TargSeqNum TLV
in all RteMsgs? When we put TargSeqNum TLV in in RREQ we can give
it no value to save on a little bit of message length.


I don't agree with the technical discussion on that matter, for several reasons.
More later.

Regards,
Charlie P.

Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2015