Subject: Re: advertising non-adjacent links (was RE: [Ospf-manet] How canwe get GTNet software?)

From: Philippe Jacquet <[email-masked]>
Date: Wed, 03 May 2006 22:54:24 +0200

Henderson, Thomas R wrote:

>Philippe, comments inline:
>
>  
>
>>-----Original Message-----
>>From: Philippe Jacquet [mailto:[email-masked]] 
>>Sent: Friday, April 28, 2006 6:07 AM
>>To: Henderson, Thomas R
>>Cc: [email-masked]
>>Subject: Re: advertising non-adjacent links (was RE: 
>>[Ospf-manet] How canwe get GTNet software?)
>>
>>Dear Tom,
>>
>>Maybe the discomfort comes from the fact that we tried to go 
>>too fast on 
>>MANET over OSPF. Since people seem already reluctant to have 
>>flooding on 
>>non adjacent links, we may expect even more reluctance to have data 
>>routed over non adjacent links. 
>>    
>>
>
>I do not think these issues are the same.  Retransmissions are related
>to preserving database synchronization and are hence related to
>adjacencies.  When the topic of flooding over non-adjacent links has
>arisen in the past, an implementor complained that it would be too
>disruptive to their implementations to decouple retransmissions from
>adjacencies.  Richard has also pointed out numerous times that OSPF
>already allows data to be forwarded over non-adjacent links.
>  
>

Yes but you agree that receiving LSA's over non adjacent links would not 
affect protocol consistencies since transmissions are in broadcast mode. 
In any case adjacencies will be preserved thanks to broadcasted 
acknowledgement (or implicit acknowledgement via LSA retransmission). 
Forwarding data over non adjacencies is another story and may impact 
basic protocol consistency. For example the two end nodes of the link 
may not agree in including the link in the shortest path and this may 
cause temporary loop. I think this is unlikely but I cannot tell this is 
impossible.

>I am not disputing that there may be reluctance to forward data over non
>adjacent links, only that this reluctance has never been justified
>adequately in my opinion (including this message).
>  
>

What I wanted to tell in this message that we, the design team, have the 
charge to prove that forwarding on non adjacent links won't disrupt the 
protocol basic mechanism.  Otherwise we would have to introduce very 
minimal changes to this basic requirement.

>  
>
>>Indeed data doesn't have 
>>sequence number 
>>and loops of data packets could be possible (although it is rather 
>>unlikely). I would say that MANET belongs more to the land of best 
>>effort, and OSPF belongs more to the land of exactitude, so 
>>to speak, in 
>>terms of routing. I am sure that MANET-OSPF can find a good 
>>compromise 
>>in between.
>>
>>For example, I don't think that we have to sacrifice some performance 
>>for exactitude (or not more than temporarily). In particular, 
>>synchronization overhead can be greatly reduced by using signature 
>>exchange between direct neighbors. If in the near future there is a 
>>trend towards using such an optimization, then the performance issues 
>>related to synchronization overhead will disappear.
>>    
>>
>
>You seem to be suggesting that the reduction of synchronization overhead
>by making the existing process more efficient can approach the
>efficiency of just suppressing some of the adjacencies.  I think that
>remains to be seen and would add that it is may be the combination of
>both that would be the most efficient.  I don't know what the level of
>acceptance of changes to database synchronization procedures would be,
>relative to the acceptance of procedures to suppress some adjacencies  
>  
>

I think both topics was introduced before the creation of the design team:

http://www.watersprings.org/pub/id/draft-spagnolo-manet-ospf-wireless-interface-01.txt 

http://www.watersprings.org/pub/id/draft-clausen-manet-ospf-dbx-00.txt

Broadcasted synchronization is the natural counterpart of broadcasted 
LSA.  I am not suggesting that we should  do everything at the same 
time, in the same document. A suggested roadmap could be
1. reducing flooding overhead <MPR, CDS, MPR-CDS>
2. reducing adjacencies/topology <where we are>
3. reducing synchronisation overhead.

>Regards,
>Tom

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

---

From: Richard Ogier <[email-masked]>
Date: Thu, 04 May 2006 09:27:28 -0700

Philippe Jacquet wrote:

>>> From: Philippe Jacquet [mailto:[email-masked]] Sent: 
>>> Friday, April 28, 2006 6:07 AM
>>> To: Henderson, Thomas R
>>> Cc: [email-masked]
>>> Subject: Re: advertising non-adjacent links (was RE: [Ospf-manet] 
>>> How canwe get GTNet software?)
>>>
>>> Dear Tom,
>>>
>>> Maybe the discomfort comes from the fact that we tried to go too 
>>> fast on MANET over OSPF. Since people seem already reluctant to have 
>>> flooding on non adjacent links, we may expect even more reluctance 
>>> to have data routed over non adjacent links.   
>>
>>
> Yes but you agree that receiving LSA's over non adjacent links would 
> not affect protocol consistencies since transmissions are in broadcast 
> mode. In any case adjacencies will be preserved thanks to broadcasted 
> cause temporary loop. I think this is unlikely but I cannot tell this 
> is impossible.
>
>
> What I wanted to tell in this message that we, the design team, have 
> the charge to prove that forwarding on non adjacent links won't 
> disrupt the protocol basic mechanism.  Otherwise we would have to 
> introduce very minimal changes to this basic requirement.
>
>
>>  
>>
>>> Indeed data doesn't have sequence number and loops of data packets 
>>> could be possible (although it is rather unlikely). I would say that 
>>> MANET belongs more to the land of best effort, and OSPF belongs more 
>>> to the land of exactitude, so to speak, in terms of routing. I am 
>>> sure that MANET-OSPF can find a good compromise in between.
>>>
>>> For example, I don't think that we have to sacrifice some 
>>> performance for exactitude (or not more than temporarily). In 
>>> particular, synchronization overhead can be greatly reduced by using 
>>> signature exchange between direct neighbors. If in the near future 
>>> there is a trend towards using such an optimization, then the 
>>> performance issues related to synchronization overhead will disappear.
>>>   
>>
>>
Philippe, By "broadcasted synchronization", I assume you mean something like
the signature exchange method, or the periodic DD packets that I proposed.
These are methods that could potentially reduce synchronization overhead as
compared to OSPF's database exchange. But broadcasted synchronization 
may not
be a good approach for the following reasons:

1. It involves even more changes to OSPF than have already been proposed.
2. It would cause significant additional delays in arriving at a solution.
3. It is not clear that this approach will improve overall performance.

This is certainly a good topic for research.  But I don't think we should
say "before deciding which approach to take, let's wait another year so
we can design and evaluate solutions that use signature exchange and
periodic DD packets".  We are already more than a year behind our
original schedule for OSPF-MANET.  One reason I worked hard last year
to design/code/evaluate OSPF-MDR was to avoid further delays.
If someone wanted the signature exchange approach to be seriously
considered, they could have worked hard last year to design/code/
evaluate an OSPF extension that uses signature exchange.
Instead, they wait a year and then suggest waiting even longer
in the hopes that someone will eventually do the work???
I guess this debate could drag on for a few more years.
That is why I agree with what Joe Macker said at
the IETF meeting: we should not over-optimize.

Richard