[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[manet] Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt

Christophe,

On Jul 25, 2006, at 9:15 PM, Christophe.Jelger at unibas.ch wrote:

Ian,

See my comments inline.

Quoting Ian Chakeres <ian.chakeres at gmail.com>:

Given that these protocols are going to run over wireless interfaces
(like IEEE 802.11), the main contributor to congestion is channel
access (not bits). Therefore; if each protocol uses a separate packet
it can result in a significant increase in channel access.

ok that's something I didn't think of. However if this is the only point in
favor of aggregation I'm afraid I'm still not really convinced. One drawback of
aggregation is increased delay. That is, each node will have to wait some small
amount of time (1ms?, 10ms?) to be able to aggregate packets.

That depends how it is done. If you run a protocol with periodic message emissions on one node, and then that node needs to forward an "occasional" external message, you have two options" either hold the external message while you wait for your next scheduled periodic message to be up for transmission (which incurs a delay). Or you may chose to immediately generate the next periodic message and transmit this immediately with the "external" message, and then reset your periodic schedule.

The devil is in the details. I believe that one detail would be that the MANET routing protocols which use periodic messages are perfectly capable of dealing with triggered "out of schedule" messages, and to reset the schedule as appropriate. Of course, one must not forget that it being *possible* to do something does not mean that it is *mandatory* to do so: if in the example given above the next periodic message was scheduled to be sent in 4 hours, it might possibly be that one would not want to reschedule, but just send the external message.

But yes, making a good message scheduler that's general enough to understand these things is part of the exercise of an implementation



Let me give a simple example. OLSR will use NHDP, it will also add
certain TLVs to NHDP for determining MPRs. OLSR will also send other
messages. It does not really make sense to separate the two onto
different multicast addresses or ports.


And even more: even looking at the messages from a single nodes perspective, OLSRv2-nodes use NHDP for their local topology maintenance and will thus generate TC messages and NHDP-HELLO messages. Since HELLO messages are sent more frequently than TC messages, even a simple scheduler would say "if I am to send a TC message at the latest at deadline XXX, send it with the last HELLO message with a deadline <XXX" - in terms of "number of channel access cycles" it would thereby be "free" to run OLSRv2 on top of NHDP, since OLSRv2 TC messages and NHDP HELLO messages would thereby be sent aggregated.

Continuing to add to this example, imagine that a portion of the
network is also running DYMO and NHDP. If separate multicast groups
were used these messages would consume even more channel access
opportunities.

One more continuation, it is likely that either reactive or proactive
may use SMF with NHDP. Again, if a separate link-local address is used
then these messages cannot be aggregated.

Realistically, if a certian deployment (provider) requires each part
of the solution to use a different multicast group this could be
implemented, but I think the default (interoperable behavior) should
be to use a single multicast address to reduce channel access.

ok I understand your points but I'm just not much convinced about the
aggregation feature. Of course it's somehow elegant but I'm not sure the extra
complexity is worth the effort.


Christophe, which complexity is it that you are worried about? The parsing of multi-message packets is something we've done in OLSR since before RFC3626. The scheduling issues, you can make a scheduler as complex as you like: taking into account aggregation in a clever way -- or as simple as you like by simply not doing aggregation. We've done that in OLSR since before RFC3626 too.


Christophe, do you think we should define one default multicast
address and one for each component?

Well IMHO I'm still in favor of having separate multicast addresses for e.g.
respectively DYMO, OLSRv2 and NHDP. But hey after all this is not the most
important issue to be resolved so I won't fight very hard. ;-) 

I think it is important, so I will fight very hard ;)

I do not see what different multicast addresses with identical scope for each component would buy us. Again, speaking with the OLSRv2-hat, I definitely would want my TC and HELLO messages to be aggregateable, and would therefore either say "thou shall send both to generic-manet- mcast-address-XXX", or say "thou shall send both to olsrv2-mcast- address-XXX", but I would *never* want to send them to different addresses.

Anything that would prevent me from aggregating such TCs and HELLOs would, in my opinion, be broken.


--thomas

_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet