search

Lotterleben / AODVv2-Draft

0 stars 0 forks source link

TBD values #22

Open Lotterleben opened 8 years ago

Lotterleben commented 8 years ago

As Ulrich pointed out, some values are marked as TBD, namely:

I think we need to make up our minds there, don't we? :)

pv0 commented 8 years ago

MAX_METRIC I think we defined as something like 'maximum representable value based on length of metric value field' (below the table in Local Settings) so it doesn't need a "TBD" exactly, but not sure how you can fit in the explanation. Does it need to be in the table?

INFINITY_TIME could be any value which isn't going to be interpreted as an actual time, could we use zero? Is it too implementation-specific? We don't specify exactly how to handle time, and it wouldn't matter if different implementations chose a different way.

Maybe MAX_METRIC and INFINITY_TIME could just be explained underneath rather than given a value in the table?

Unless I missed something, MAX_PACKET_SIZE, BUFFER_SIZE_BYTES, and BUFFER_SIZE_PACKETS are only mentioned in the Local Settings table. Should we even bother having these? If so, they concern how big the buffer should be - it would be hard to determine what this value should be, as it should take into account the number of route requests in progress, the number of router clients that wish to send (could be more than one per route request), the amount of traffic it would be beneficial to buffer, what if one router client might be sending a lot of packets and fill the buffer but another router client is trying to establish a TCP connection, would you try to buffer only TCP packets, how much memory is available, how big are the packets expected to be? Lots of factors... Charlie, are there values you would recommend based on experimental evidence? Same for CONTROL_TRAFFIC_LIMIT?

The TBD for Unallocated could instead be "Undefined"?

Lotterleben commented 8 years ago

I don't think they need to be in the table but it would be more concise... If we can come up with a short-ish description that should be fine, shouldn't it? A row can have multiple lines after all...

regarding MAX_Metric, We could use your description I think, and regarding infinity I agree it seems implementation specific... Maybe we don't need a default there at all?

Lotterleben commented 8 years ago

MAX_PACKET_SIZE, BUFFER_SIZE_BYTES, and BUFFER_SIZE_PACKETS seem like leftovers from text that was deleted, I'd vote to get rid of them

Lotterleben commented 8 years ago

Re: unallocated -> undefined: +1.

charliep51 commented 8 years ago

Hello folks,

We need to specify that packets can (in fact SHOULD) be buffered. That is important.

I will try to catch up on emails today. It's been rush-rush-rush since last week.

Regards, Charlie P.

On 5/24/2016 2:30 AM, Lotte Steenbrink wrote:

MAX_PACKET_SIZE, BUFFER_SIZE_BYTES, and BUFFER_SIZE_PACKETS seem like leftovers from text that was deleted, I'd vote to get rid of them

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Lotterleben/AODVv2-Draft/issues/22#issuecomment-221215399

pv0 commented 8 years ago

We do still specify that buffering can be used, but we defined these three in the Constants section (BUFFER_SIZE_PACKETS and BUFFER_SIZE_BYTES and MAX_PACKET_SIZE) which aren't referred to anywhere else. We can leave the current text about buffering but remove these constants, and therefore wont need to define defaults for them.

Lotterleben commented 8 years ago

+1 to what Vicky says

Lotterleben commented 8 years ago

for the record: ask @charliep51 for a suggestion for CONTROL_TRAFFIC_LIMIT

charliep51 commented 8 years ago

One good way to specify the control traffic limit is to configure a maximum percentage of the wireless medium that can be used for control traffic, and a granularity for time interval during which that percentage is enforced.

So, for instance we might specify that no more than 10% of the wireless medium may be used for control traffic during one second. In the abstract, these quantities might be specified as "MAX_CONTROL_TRAFFIC_PERCENTAGE" and "ENFORCEMENT_INTERVAL"

This is probably good enough. A couple of observations:

If more details are needed, then the implementor can work through the details as follows:

I don't know how much of this belongs in the normative specification. It might fit better into an appendix. Anyway the method outlined above doesn't take too much programming and is pretty easy for the processor.

charliep51 commented 8 years ago

Hello folks,

Should I make a non-normative Appendix to show an example for configuring CONTROL_TRAFFIC_LIMIT?

Here is my discussion from github:

One good way to specify the control traffic limit is to configure a maximum percentage of the wireless medium that can be used for control traffic, and a granularity for time interval during which that percentage is enforced.

So, for instance we might specify that no more than 10% of the wireless medium may be used for control traffic during one second. In the abstract, these quantities might be specified as "MAX_CONTROL_TRAFFIC_PERCENTAGE" and "ENFORCEMENT_INTERVAL"

This is probably good enough. A couple of observations:

  • it's not required for interoperability
  • we don't want to over-specify it so that the processor has to go wild with exactitude
  • The specification should be a SHOULD.
  • Control packets should be enqueued for transmission as we have already specified.

If more details are needed, then the implementor can work through the details as follows:

  • determine an average control packet size
  • determine the transmission rate supported by the wireless medium
  • determine how many control packets MAX_CTL can be sent during a MAX_CONTROL_TRAFFIC_PERCENTAGE of the ENFORCEMENT_INTERVAL
  • During the ENFORCEMENT_INTERVAL, count the number of control packets sent
  • If the number attains the value MAX_CTL, disable transmission of control packets for the duration of the current ENFORCEMENT_INTERVAL.
  • Every time a new ENFORCEMENT_INTERVAL expires, reset the count of control packets to zero.

I don't know how much of this belongs in the normative specification. It might fit better into an appendix. Anyway the method outlined above doesn't take too much programming and is pretty easy for the processor.

Regards, Charlie P.

On 6/8/2016 9:31 AM, Lotte Steenbrink wrote:

Assigned #22 https://github.com/Lotterleben/AODVv2-Draft/issues/22 to @charliep51 https://github.com/charliep51.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Lotterleben/AODVv2-Draft/issues/22#event-686071002, or mute the thread https://github.com/notifications/unsubscribe/ABbdvgwGF1E9uw5idZ4pH4RDTL5RU_3qks5qJu50gaJpZM4Igwok.

Lotterleben commented 8 years ago

Hi Charlie, I think your latest set of bullet points makes for a pretty good explanation already... One question though, you said

So, for instance we might specify that no more than 10% of the wireless medium may be used for control traffic during one second.

..Should we provide some guidelines for a suitable percentage or does that depend mostly on the kind of traffic that's going to go over the wireless medium?

charliep51 commented 8 years ago

Here are some comments on Vicky's revision for this issue. Regarding the following: +These protocol constants MUST have the same values for all AODVv2 routers in the ad hoc network. If the values were configured differently, the following consequences may be observed: ... ... Since in each of the 5 cases listed, there are not any interoperability problems, or serious performance degradations, I think the "MUST" should be "SHOULD" in the first sentence.

The default value for RREP_RETRIES can be 2 for wireless media without bidirectional MAC symmetry. But for MAC layers that provide bidirectional operation (such as 802.11), RREP_RETRIES could be less.

Since AODVv2 routers don't communicate time between each other, I don't think the comment is valid:

pv0 commented 8 years ago

So, while we refer to CONTROL_TRAFFIC_LIMIT throughout the draft, in the Constants section, should I expand this to then refer to ENFORCEMENT_INTERVAL and MAX_CONTROL_TRAFFIC_PERCENTAGE? Or Charlie, would you like to do this in the TBD-issue-22 branch? I would say we dont need the fine detail of the last set of bullet points.

pv0 commented 8 years ago

choose SHOULD not exceed 5%