Subject: [manet] Comment on manet gateway autoconf draft.

From: "HyunWook Cha" <[email-masked]>
Date: Tue, 4 Nov 2003 11:41:37 +0900

Hello, Christophe.

I briefly read your draft. 
Please see following comments.

.GW_INFO_REFRESH_PERIOD(2 secs) is too short. This can degrade overall
manet capability.

.B_DISTANCE/F_DISTANCE 
- suffer from frequent change of global address in case of relatively
high mobility as you mentioned.
 
.B_STBILITY/F_STABILITY 
- I think this can not help prefix(addres) stability after all. In
manet, it is not queranteed that a given path with prefix continuity
will survive as you hope. In addition, your scheme allows forwarding of
GW_INFO with same prefix as already configured one when node receives
GW_INFOs. So, it is possible that a node can not receive fresh GW_INFO
for current prefix after upstream link fails although alternate path
toward correspon ding gateway exists and it should change its address.
- Irrespective of type of underlying routing protocols, this appoach can
cause inconsistency of route entry for gw and default route entry. This
is ok for proactive routing protocols except for above issue. However,
as for reactive routing protocols, prefix continuity does not help at
all and routing header is needed to avoid ingress filtering problem.
Becuase routing entry is created through routing protocol(you told that
in your draft), path along which packets travers can be different from
one with prefix continuity. If this is right, you should consider
applicability to reactive routing protocols again.

.Why do not you allow configuration of multiple global addresses from
multiple gateways?

I want to hear your answer.

Thank you in advance.

HyunWook 

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 04 Nov 2003 14:10:42 +0100

Hi HyunWook and thanks for your comments,

I will reply to your comments one by one, see my answers below.

> .GW_INFO_REFRESH_PERIOD(2 secs) is too short. This can degrade overall

Well in fact this value may change, and actually it is not easy to find 
a suitable value. I mean, if this value is too big then we won't have 
any reactivity to topological changes. In the mean time, I do not agree 
with you when you say that it degrades the performance of the manet, as 
with our proposal each node does one (local to its 1-hop neighborhood) 
broadcast every GW_INFO_REFRESH_PEIOD. The size of the broadcasted 
message itself is very small (24 bytes for the data + IPv6 header). I 
don't think such a small overhead can that much degrade performance.

> high mobility as you mentioned.

As mentioned in the draft, we cannot have shortest-path and stability at 
the same.

> will survive as you hope. 

The aim of our proposal is to maintain such a path. The maximum time 
during which prefix continuity may be broken is equal to NEIGH_LIFE 
(i.e. 6 seconds). Once again it's a trade-off between stability and 
reactivity.

> In addition, your scheme allows forwarding of

This is correct. The lifetime of an upstream neighbor entry is equal to 
NEIGH_LIFE. Once again we did not want to be too reactive because a 
GW_INFO may be lost (due to collisions) but the neighbor may still be in 
radio range. In that case we do not want to change the upstream neighbor 
too quickly.

> applicability to reactive routing protocols again.

Well in fact this is mentioned in the draft, i.e. there might be a 
different next hop entry for default route (added by our protocol) and 
for gateway/128 route (added by proactive routing protocol), in the case 
of proactive protocols. With F_DISTANCE, it is easy to show that the 
alternate path is also a shortest-path. With F_STABILITY, the alternate 
path may be longer than shortest-path, but (during a stady-state period) 
all nodes on this path use the same prefix, so we don't need a routing 
header : that is our main objective.

Now with reactive protocols, we don't add a default route. The reactive 
routing protocol is in charge of route discovery. If the prefix 
continuity condition is satisfied, it means that there exists, between a 
node A with prefix P and its gateway G, a path of nodes with prefix P. 
If we want to avoid the need of a routing header, there should be a 
condition in routing protocol operation : "don't accept R_REP (for a 
destination address outside manet) from nodes that use a different 
prefix". This condition would impose (in a recursive manner) that the 
path would be composed of nodes with prefix P.

> .Why do not you allow configuration of multiple global addresses from

Mainly because we favor prefix continuity. A node could have more than 
one global address but it should then use the one for which prefix 
continuity is maintained. In our proposal we use only one global 
address, but it is changed (with some delay) if a topological change 
occurs. In fact and again our proposal avoids the need of a routing 
header. Actuallly it can of course be interesting to have multiple 
global addresses, and this something we may add in the future, if we 
manage to come up with a cleaver idea on how we can use these addresses 
efficiently.

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 6 Nov 2003 13:58:10 +0900

Hellow, Cristophe.
Please see my comments below.

[snip]
------------------------------------------------------------------------
-----------------------------
> don't think such a small overhead can that much degrade performance.
Uhm... I understand that. But, receiver nodes should process GW_INFO in
routing module or seperate specific module whether the GW_INFO is
accepted or not. I think this is also unnecessay bandwidth consumption
and processing overhead. 

> > - Irrespective of type of underlying routing protocols, 
> this appoach 
> > can cause inconsistency of route entry for gw and default 
> route entry. 
> > This is ok for proactive routing protocols except for above issue. 
> > However, as for reactive routing protocols, prefix 
> continuity does not 
> > help at all and routing header is needed to avoid ingress filtering 
> > problem. Becuase routing entry is created through routing 
> protocol(you 
> > told that in your draft), path along which packets travers can be 
> > different from one with prefix continuity. If this is right, you 
> > should consider applicability to reactive routing protocols again.
> 

Above condition is not sufficient. Broadcast RREQ message can traverse
any node irrespective of its prefix. So, reverse path established by
RREQ is shortest one toward the gateway but intermediate nodes may have
different prefix than a requesting node as well as intermediate node
replying with RREP. Thus, you should insert additional requirement into
processing of RREQ that only intermediate nodes with the same prefix as
requesting node can forward RREQ. This can lead that upper layer session
is disconnected even before lifetime of prefix is expired. 

> manage to come up with a cleaver idea on how we can use these 

If the main purpose of maintenance of prefix continuity is to avoid
routing header, I do not agree. IMO, usage of routing header has
following advantages.
- not require prefix continuity, but prefix stability can be maximized.
As long as a node can find route information for a gateway, it can
refresh its address. This can help tranport layer survivability.
- can use the shortest path established by routing protocol. This can
compensate bandwidth consumption caused by routing header  while
traffics can traverse non-optimal paths without routing header.
- ok when intermediate nodes do not want internet connectivity or not
yet configure its global address just after bootstraping. It needs only
route information for a gateway through RREQ and RREP exchange. 

What do you think about this?

Regards,

HyunWook Cha

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 12 Nov 2003 17:28:37 +0100

Hi HyunWook / all,

Well I agree when you say that using a routing header maximizes prefix 
stability. If we also want to maintain transport layer sessions then we 
also need something like your proposal (or MIPv6). I am not opposed to 
the use of routing header, in fact I'm mainly worried about the 
complexity to write some code that needs to add a routing header. I 
guess this has to be kernel code, I don't know if it can written as an 
external module or not, and how complex it is for a lambda user to 
install such code. If anybode has experienced in writing code with 
routing header can give us some hints he is very welcome. ;-)

I think MIPv6 is a good example of what I mean : a user that is not 
experienced with Linux cannot install it easily. I personaly think that 
it can refrain people from using it, mainly because it is too complex to 
setup.

Note that with our proposal, we can also use routing headers, but 
decided not to include it in the draft because we wanted to avoid this 
(unknown) complexity (when writing the code). Our proposal (developed by 
Arnaud Frey) is already implemented as a (user level) daemon which can 
be installed by any user that knows how to use a shell. The code is 
still in a debugging state, a few things have to be checked and 
validated but a first beta version should be available soon.

Christophe

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 13 Nov 2003 05:30:07 +0900

I don't know why you concern implementation so much. 
You should not assume particular OS. 

I don't see any problem to use routing header. We suggested to use it in
global6 draft. Are you saying that kernel implementation is complex? 
I disagree with your statement.

ryuji

> >What do you think about this?

regards,
ryuji

---

From: Christophe Jelger <[email-masked]>
Date: Thu, 13 Nov 2003 18:07:04 +0100

Hi Ryuji,

I'm not saying kernel implementation is complex (actually I don't have 
experience in kernel code), I'm rather saying that such code usually 
requires that a user who wants to install it needs to have some 
knowledge in patching a kernel and stuff like that. Well for people like 
us it is easy to install MIPv6, but for a basic user it requires too 
much effort and I think it can prevent people from using it. I took the 
example of MIPv6, because I think many users would be interested by 
MIPv6, but if installation is too complex people may just give up using it.

I also think MANET is a good example. I you tell basic users that he can 
use MANET functionalities and that it requires very little effort to 
install, then they may use it. If you tell them they need to be network 
specialists to install it then they will probably just forget about it. 
Note that I'm not saying that therefore the research community should 
not propose protocols/ideas/whatever that are complex to setup, this is 
completely different. I was just trying to motivate the fact that we 
decided to avoid the routing header stuff because we want something that 
is simple to develop and install. The main goal there is to propose 
something that can be tried very easily.

Regards,
Christophe

---

From: Li Li <[email-masked]>
Date: Thu, 13 Nov 2003 15:10:28 -0500

I'm looking for simulation package of OLSR on OPNET, preferably implemented
on the latest version of OPNET, v10. Any information is much appreciated!

Li Li

---

From: "HyunWook Cha" <[email-masked]>
Date: Thu, 13 Nov 2003 15:28:28 -0600

Hello, Christoph.

I think that you should consider performance rather than complextity of
installation.
As I mentioned before, a manet node do not have to worry about prefix
continuity (which can be harmful in manet) by using routing header.
That is, upper layer sessions will keep forwarding as long as route for
the target gateway can be found.

Although installation procedure is very simple and easy to use, bad
performance will be accepted by users. I think that it is ok if kernel
implemenation does not require kernel patch and its form is a module.
Again, think the performance at first.

HyunWook Cha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christophe Jelger
> Sent: Thursday, November 13, 2003 11:07 AM
> To: manet
> Subject: Re: [manet] Comment on manet gateway autoconf draft.
> 
> 
> 
> Hi Ryuji,
>

---

From: Christophe Jelger <[email-masked]>
Date: Fri, 14 Nov 2003 09:28:51 +0100

Hi again,

Well actually I don't agree with your statement when you say that prefix 
continuity can be harmful ... harmful to what ? Moreover I also disagree 
when you say "bad performance" as I don't think prefix continuity would 
lead to bad peformance, I mean in terms of packet delay for example. In 
contrast I agree that if we want to maximize prefix stability then 
routing might be sub-optimal. Again if we don't care about prefix 
stability (prefix continuity is inherent to the protocol), then routing 
would be optimal (a node finds the closest gateway), and transport layer 
sessions can be maintained with MIPv6.

Actually I think it is good to have different solutions/proposals, they 
can be compared and if implementations are available one can choose one 
or another. Well I don't really know if this address autoconfiguration 
stuff is being discussed at the IETF meeting (I could not go there), but 
if it does not become a MANET objective we won't have to bother about 
finding the best solution.

Regards,
Christophe

HyunWook Cha wrote:

>>>I don't see any problem to use routing header. We suggested 
>>>      
>>>
>>to use it in
>>    
>>

---

From: "HyunWook Cha" <[email-masked]>
Date: Mon, 17 Nov 2003 16:35:45 +0900

Hello, Christophe.

I think that I am understanding your idea well enough. As you know from
my previous comments
(http://www.ietf.org/mail-archive/working-groups/manet/current/msg03221.
html,
http://www.ietf.org/mail-archive/working-groups/manet/current/msg03176.h
tml), I can not agree that it works efficiently when multiple gateways
are available and the topology of a manet is changed frequently. More
specifically, I can not expect that your idea can maximize prefix
stability though you insist that (I told the reason at my first
comment). Have you ever simulated your idea using NS-2 or whatever? The
second performance issue is caused by inconsistency between default
route established by your idea and routing protocols (This was already
mentioned, too). This can affect the performance of your idea in terms
of end-to-end delay. This issue also requires that your idea and the
scheme using routing header should be compared through simulations. You
think that we can not address the prefix stability and optimality of
route at the same time. Why do not you use a routing header? (I want to
avoid redendant explanation,) Whether multiple addresses(prefixes) can
be configured and used or not, the use of routign header can maximize
the stability of current prefix and make use of an obtimal route for the
current gateway discovered by routing protocols (if we can say that a
route is "obtimal" when it is established through a routing protocol.).

Uhm.... I do not know when this area (internet connectivity) was issued
for the first time, what the current consensus of the whole working roup
about this subject and when this subject will be discussed more
actively. Actually, any other issues except routing protocols including
ospf extension were not addressed.(Am I right?) However, I believe that
this issue can support deployment of manet technologies. Will you come
at Seoul meeting (59th one)? If so, we can share further thoughts each
other.

Regards,
HyunWook Cha

> From: Christophe Jelger [mailto:[email-masked]] 
> Sent: Friday, November 14, 2003 5:29 PM
> To: 'manet'
> Cc: [email-masked]