Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 8

From: Richard Ogier <[email-masked]>
Date: Sun, 01 Oct 2006 08:21:08 -0700

Aniket Desai wrote:

> Hi,
>
> Multicasting retransmitted LSAs is not a "flaw" in MDR draft. It is a 
> modular function that; if anything; can benefit any OSPF 
> implementation (even the wired one). Whether it is an MDR or an MPR 
> solution; they all can use the same. I think the criterion for 
> distinguishing the solutions is set to flooding and adjacencies (or 
> maybe only flooding). Retransmissions are secondary as they all can 
> use the same scheme.

Well said, Aniket.  OSPF retransmits LSAs as unicasts (even in a
broadcast network), and so does OSPF-MDR.  This is not a flaw and
results in very good performance as simulations have shown.  This also
minimizes changes to OSPF, which is one of our objectives.
Since the number of adjacencies is small in OSPF-MDR, unicasting
retransmitted LSAs on adjacencies does not generate a lot of overhead.
Philippe pointed out the benefit of multicasting retransmitted LSAs,
and I am open to the suggestions of others, so I said we will
evaluate the use of multicast retransmitted LSAs in OSPF-MDR, and
possibly include it if it improves performance significantly
(at this point I am not sure it will).  I thought we are supposed
to be working together, so I thought it would be a *good* thing
to be open to the suggestions of others.  Instead, it is taken
as a sign of weakness and implies a flaw?

Moreover, the fact that the OSPF-MDR team is open to the suggestions
of others is NOT a good reason to have multiple experimental drafts.
It only means that in the end OSPF-MDR will be a product of the WG,
not a proprietary product of one company.
As I mentioned in another message, progress will be faster
if we agree on a SINGLE approach.  An *approach* does not imply
we have a final spec that is cast in concrete, but a good spec
that can be improved based on input from the WG.
If we have two experimental drafts, then some team is going to
spend a lot of effort trying to show their solution is best, only
to find that their efforts have been futile.  To add insult to
injury, it is also possible that the best solution will lose
because of politics!  I don't want to waste my time
if the end result will be determined by politics.
(I believe Tom expressed a similar sentiment.)

At the IETF meeting in Dallas, we did seem to have rough consensus,
with only INRIA opposing.  Those were good times.  Now, for unknown
reasons, Cisco people are coming out and trying to promote having
multiple experimental drafts. (Somebody who has been reading the
exchange told me it looks like "political bullying".)

At the IETF meeting, Bill Fenner said that if we can't agree on
a single solution, then "we are going to find a way to break
the loop, and not everybody might like it, so I encourage
everyone to work together to break the loop themselves."
(This is an exact quote from the audio recording.)
Maybe the best solution is for the ADs (and perhaps another
unbiased judge) to decide which approach to go with, based
on a fair comparison given all the relevant evidence (including
a position paper written for each approach).

Richard

>
>
> Sincerely,
>
> Aniket
>
> At 01:42 PM 9/29/2006, Padma Pillay-Esnault wrote:
>
>> Richard Ogier wrote:
>>
>>> Philippe Jacquet wrote:
>>>
>>>> Dear Aniket,
>>>>
>>>> I thought I already gave a proof of the fact that in OSPF-MPR, LSA 
>>>> retransmission cost is O(1). Complexity issue is also important 
>>>> since autonomous systems may have limited processing power. It 
>>>> makes also a point if  an old well proved algorithm appears to be 
>>>> less costly and more performant than a new more intricate algorithm.
>>>>
>>>> The proof is not really MPR related, it is just a consequence of 
>>>> multicast LSA retransmissions that I explained before. That way you 
>>>> don't need to browse your neighborhood to check who has acked and 
>>>> who has not, you simply need a counter.
>>>>
>>>> I understand that you sugested Dr Ogier to include this feature in 
>>>> MDR (as another option?).
>>>
>>>
>>>
>>>
>>> Yes, although I first suggested it on 9/18/2006 as
>>>                                                         ^^^^^^^^^
>>
>>
>> Richard, it seems that the MDR draft is in perpetual change each time 
>> absorbing yet another optimization when
>> someone finds yet another "flaw".
>>
>> To me this shows how much this is an experimental draft and it 
>> doesn't make sense to me to rush this into a
>> standard.
>>
>> As far as rough concensus - I don't see one - in the light of 
>> extensive email threads and discussions in
>> various working groups.
>>
>> Simulations are not real world implementations and  I thought that 
>> standards are about
>> real world implementations. My conclusion is - experimental drafts is 
>> the way to go.
>>
>> Padma
>>
>>>> 4. Ack the first reception of an LSA, and ack any LSA received in 
>>>> an LSU
>>>> that contains the router in the Ack list.  Retransmitted LSAs are 
>>>> multicast.
>>>
>>>
>>>
>>>
>>> An LSA option bit can be used to indicate which LSAs are retransmitted,
>>> and the neighbors that should Ack the LSA can be listed at the end of
>>> the LSU packet.  It looks like you are assuming that *every* adjacent
>>> neighbor must Ack *every* LSA, which is simpler but results in more
>>> Ack overhead.  In any case, as you say, the choice to multicast
>>> retransmitted LSAs is independent of whether you use MDRs or MPRs.
>>> We can experiment with this technique and possibly include it in
>>> a future version of the MDR draft.
>>>
>>>> If you think twice you will realise that the multicast LSA 
>>>> retransmission has also deeper consequences: it allows to make 
>>>> completely independent the flooding forwarding graph and the 
>>>> adjacency graph. You could have an MDR adjacency graph over the MPR 
>>>> flooding.
>>>
>>>
>>>
>>>
>>> As previously discussed, making the flooding relays independent of the
>>> adjacency graph could affect performance. (Also, using both MDRs and 
>>> MPRs
>>> would add complexity.) But this could be done whether or not 
>>> retransmitted
>>> LSAs are multicast.
>>>
>>> Richard
>>>
>>>
>>>>
>>>> Of course there will remain the problem of links advertizement and 
>>>> how to advertize links that are non synchronized, thing we don't do 
>>>> in OSPF-MPR, but this is at an another level of the protocol.
>>>>
>>>> Best regards,
>>>> Philippe
>>>>
>>>>
>>>> Aniket Desai wrote:
>>>>
>>>>>
>>>>> I believe that the grief resulted from the flooding algorithm; 
>>>>> which was indeed trying to "over-optimize". But I am sure it can 
>>>>> be turned into an option. And as far as neighbor scanning goes, 
>>>>> there is no getting away from it due to retransmissions. Not only 
>>>>> that, any router must get its adjacent neighbors out of loading 
>>>>> state; for which, it must scan all of them against each received 
>>>>> new LSA anyway. So what is the problem? MDR flooding is not 
>>>>> scaling from O (n) to O (n^2) or something. It is still O (n).
>>>>>
>>>>> I feel that legacy OSPF by itself is a complex protocol. OSPF is 
>>>>> complex because it seeks to synchronize a subset of neighbors of 
>>>>> an interface, and any flooding procedure must account for that; 
>>>>> because any new received LSA may be forwarded *AND* it may be an 
>>>>> important piece in synchronizing any neighbor of that interface 
>>>>> (section 13 of RFC 2328). Why was there an expectation that MANET 
>>>>> flooding would be less complex than the legacy OSPF flooding? It 
>>>>> is not appropriate to compare OSPF MANET flooding to OLSR 
>>>>> flooding; because afterall; this is *OSPF*. I am still unable to 
>>>>> understand how using MPR solution would reduce the flooding 
>>>>> algorithm to O (1) as has been implied again. I will be extremely 
>>>>> happy to study the draft carefully still; if it was available! I 
>>>>> would seriously like to know if I am missing anything?
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ospf-manet mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/ospf-manet
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ospf-manet mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/ospf-manet
>>
>
>
>

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

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 01 Oct 2006 11:22:04 -0700

> as a sign of weakness and implies a flaw?
Did you notice that "flaw" was in quotes ?

> not a proprietary product of one company.

Being a sponge and absorbing other ideas until this last minute makes 
the proposal
look immature and not ready for standardization other than experimental
and that was my point.

> (I believe Tom expressed a similar sentiment.)
I sincerely think you are crossing the line here -
you cannot accuse people of politics or whatever unless you have proof
of that. BTW, other people could be having the same impression that
you are bullying them by being so aggressive.

I have been watching this discussion on the side line and
my first comment gets an unveiled accusation of being political!

Isn't this "shout down" ?
Pray, on what grounds can you judge the ethics of another ?

> exchange told me it looks like "political bullying".)
Silence does not mean that there is consensus.

> a position paper written for each approach).

The crux of the problem here is that this "evidence" is not considered
proof of concept by many.

 I think you have lost me when you presented "results" on a proposal
that was not simulated yet. Note the " ". The slides clearly presented
"results" instead of *extrapolation* in Dallas and this was clearly 
misleading.

Padma

>>>>> multicast LSA retransmissions that I explained before. That way 
>>>>> you don't need to browse your neighborhood to check who has acked 
>>>>> and who has not, you simply need a counter.
>>>>>
>>> Richard, it seems that the MDR draft is in perpetual change each 
>>> time absorbing yet another optimization when
>>> real world implementations. My conclusion is - experimental drafts 
>>> is the way to go.
>>>
>>> Padma
>>>
>>>>> adjacency graph. You could have an MDR adjacency graph over the 
>>>>> MPR flooding.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> adjacency graph could affect performance. (Also, using both MDRs 
>>>> and MPRs
>>>>> how to advertize links that are non synchronized, thing we don't 
>>>>> do in OSPF-MPR, but this is at an another level of the protocol.
>>>>>
>>>>> Best regards,
>>>>> Philippe
>>>>>
>>>>>
>>>>> Aniket Desai wrote:
>>>>>
>>>>>>

---

From: Richard Ogier <[email-masked]>
Date: Mon, 02 Oct 2006 10:52:20 -0700

Padma,

Padma Pillay-Esnault wrote:

> Richard Ogier wrote:
>
>>  Aniket Desai wrote:
>>
>>> Hi,
>>>
>>> Multicasting retransmitted LSAs is not a "flaw" in MDR draft. It is 
>>> a modular function that; if anything; can benefit any OSPF 

I guess I didn't notice.  Thanks for pointing this out.

> look immature and not ready for standardization other than experimental

I didn't say it is ready for standardization.  It is a good approach
that can be improved based on input from the WG.  I think the best
plan is to focus on this approach rather than have multiple experimental
drafts.  This is essentially what Acee recommended at the Dallas meeting,
where he said we need more experience with people optimizing and
implementing the MDR approach.

> my first comment gets an unveiled accusation of being political!

The accusation was not aimed at you, it was a general statement
intended for others.  Also, note that I used the words "possible"
and "if".

> "results" instead of *extrapolation* in Dallas and this was clearly 

I am not sure exactly what "results" you are referring to, but
when I use the phrase "simulation results", it means that simulations
of some sort were performed.  Maybe you can tell me exactly what you
think was extrapolated.

Richard

>>>>>> I thought I already gave a proof of the fact that in OSPF-MPR, 
>>>>>> LSA retransmission cost is O(1). Complexity issue is also 
>>>>>> important since autonomous systems may have limited processing 
>>>>>> power. It makes also a point if  an old well proved algorithm 
>>>>>> appears to be less costly and more performant than a new more 
>>>>>> intricate algorithm.
>>>>>>
>>>>>> I understand that you sugested Dr Ogier to include this feature 
>>>>>> in MDR (as another option?).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Of course there will remain the problem of links advertizement 
>>>>>> and how to advertize links that are non synchronized, thing we 
>>>>>> don't do in OSPF-MPR, but this is at an another level of the 
>>>>>> protocol.
>>>>>>
>>>>>> Best regards,
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>> Aniket Desai wrote:
>>>>>>
>>>>>>>
>>>>>>> there is no getting away from it due to retransmissions. Not 
>>>>>>> only that, any router must get its adjacent neighbors out of 
>>>>>>> loading state; for which, it must scan all of them against each 
>>>>>>> received new LSA anyway. So what is the problem? MDR flooding is 
>>>>>>> not scaling from O (n) to O (n^2) or something. It is still O (n).
>>>>>>>
>>>>>>> (section 13 of RFC 2328). Why was there an expectation that 
>>>>>>> MANET flooding would be less complex than the legacy OSPF 
>>>>>>> flooding? It is not appropriate to compare OSPF MANET flooding 
>>>>>>> to OLSR flooding; because afterall; this is *OSPF*. I am still 
>>>>>>> unable to understand how using MPR solution would reduce the 
>>>>>>> flooding algorithm to O (1) as has been implied again. I will be 
>>>>>>> extremely happy to study the draft carefully still; if it was 
>>>>>>> available! I would seriously like to know if I am missing anything?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>