Subject: [Ospf-wireless-design] OSPF Wireless Design Team Minutes

From: Acee Lindem <[email-masked]>
Date: Wed, 09 Mar 2005 13:49:29 -0500

All,

Yesterday morning Tom Henderson, Thomas Clausen, Joe Macker, Emmanuel 
Baccelli,
and I got together to design team issues, progress, and actions. This 
E-mail includes my
notes from the meeting. Please feel free to add comments and corrections.

One of the first things we discussed was how to handle the evolution of 
requirements.
All of us agreed that if we were going to make any progress we needed to 
stick to the
original charter of the design. Joe reiterated that the MANET WG is 
actively pursing
protocols optimized to MANET environments including reactive protocols. 
I added
that it would be interesting to see how either the protocols and/or 
concepts could
be seamlessly integrated with OSPF (however, that also is not within the 
scope
of the design team).

We diverged and had a brief discussion of wireless link metrics and agreed
that while the handling of these could have a profound effect on the 
effectiveness on
a wireless routing protocol but  they were also not within the scope of 
the design team
or the OSPF WG.

Right now our immediate goal is to work toward a decision on the selection
of a recommended flooding mechanism by the next IETF. This would include
both the both the selection of who to flood to and the dissemination of 
2-Hop neighbor
information. We also discussed the difficulties of making a decision 
when design
team members have ownership of the proposals.

Tom updated us on the progress with GTSNet and  indicated there were people
in the process of coding Ogier's flooding extensions. GTSNet is the primary
tool for evaluating flooding mechanisms.

Tom and Joe indicated one thing that was needed in the MPR (Chandra)
proposal was how to reduce the number of adjacencies in very dense
environments. In other words, how does one operate with a partial topology.

We concluded with a discussion of metrics should go into the
 MPR or CDS selection preference. Joe brought up some work his
team had done with radio quality as a determining factor.

Thanks,
Acee

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

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 9 Mar 2005 18:24:16 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Acee Lindem
> Sent: Wednesday, March 09, 2005 1:49 PM
> To: [email-masked]
> Subject: [Ospf-wireless-design] OSPF Wireless Design Team Minutes 
> 
> All,
> 
> Yesterday morning Tom Henderson, Thomas Clausen, Joe Macker, 
> Emmanuel Baccelli, and I got together to design team issues, 
> progress, and actions. This E-mail includes my notes from the 
> meeting. Please feel free to add comments and corrections.
> 
> One of the first things we discussed was how to handle the 
> evolution of requirements.
> All of us agreed that if we were going to make any progress 
> we needed to stick to the original charter of the design. Joe 
> reiterated that the MANET WG is actively pursing protocols 
> optimized to MANET environments including reactive protocols. 
> I added
> that it would be interesting to see how either the protocols 
> and/or concepts could be seamlessly integrated with OSPF 
> (however, that also is not within the scope of the design team).
> 
> We diverged and had a brief discussion of wireless link 
> metrics and agreed that while the handling of these could 
> have a profound effect on the effectiveness on a wireless 
> routing protocol but  they were also not within the scope of 
> the design team or the OSPF WG.
> 
> Right now our immediate goal is to work toward a decision on 
> the selection of a recommended flooding mechanism by the next 
> IETF. This would include both the both the selection of who 
> to flood to and the dissemination of 2-Hop neighbor 
> information. We also discussed the difficulties of making a 
> decision when design team members have ownership of the proposals.
> 
> Tom updated us on the progress with GTSNet and  indicated 
> there were people in the process of coding Ogier's flooding 
> extensions. GTSNet is the primary tool for evaluating 
> flooding mechanisms.
> 
> Tom and Joe indicated one thing that was needed in the MPR 
> (Chandra) proposal was how to reduce the number of 
> adjacencies in very dense environments. In other words, how 
> does one operate with a partial topology.
> 
Thanks Acee for the good summary.

The radio quality issue is really about an additional weighting factor not
so much a determining factor.  Degree is still used but is not an overriding
metric. 

I also brought up a suggestion to look at adjancency failure/arrival models
in evaluating approaches not just mobility.  Realistic time varying radio
channels will be of this nature and mobility models along does not
completely exercise 'real world" robustness and repairing efficiency
Mobility alone within a bouncing box tends to have more persistent adjacency
behavior as was shown in Richard's work. Having said that, I believe the
work to date is good, but I think we need this additional consideration.

---

From: Richard Ogier <[email-masked]>
Date: Tue, 15 Mar 2005 12:55:26 -0800

Acee Lindem wrote:

> One of the first things we discussed was how to handle the evolution 
> of requirements.
> All of us agreed that if we were going to make any progress we needed 
> to stick to the
> protocols optimized to MANET environments including reactive 
> protocols. I added
> be seamlessly integrated with OSPF (however, that also is not within 
> the scope
> of the design team).

Or vice versa. The MANET charter includes a statement to pay attention
to the OSPF-MANET protocol work. So, even though I don't have time to
present/discuss my work in the MANET WG, if the SI-CDS approach is
found to be best for the OSPF extension, then it might also be
the best choice for flooding and proactive routing in MANETs
(independently of OSPF). It would nice to have a unified solution
that works well in both cases. In fact, the extended OSPF itself
might be the best solution for proactive routing in MANETs,
if it is efficient enough.

> both the both the selection of who to flood to and the dissemination 
> of 2-Hop neighbor

This should not be a problem for my draft. There are no IPR claims
for my draft, and I plan to turn it over to the design team at some
point, to add details, enhancements, etc.  I just want to be in
control until it is evaluated in simulations (so that if it does not
perform well, I am the only one to blame). So, it seems to me that
the main thing we are waiting for is performance evaluation.

Richard

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 22 Mar 2005 14:26:10 -0500

Good notes.  One FYI comment inline...

> so much a determining factor.  Degree is still used but is not an overriding

Good!  We modified our overlapping relay selection algorithm a while ago
to incorporate wireless link metrics into the selection process...in 
addition to degree, overlap, and Willingness.  We didn't update our draft 
to include this since we think the selection algorithm of overlapping relays 
need not be standard, allowing flexibility.  The behavior of an active 
overlapping relay once selected is what should be standard.

> work to date is good, but I think we need this additional consideration.

This sounds very reasonable.

Thanks,
Madhavi

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 22 Mar 2005 18:09:03 -0500

> > > We concluded with a discussion of metrics should go into 
> the MPR or 
> > > CDS selection preference. Joe brought up some work his 
> team had done 
> > > with radio quality as a determining factor.
> > The radio quality issue is really about an additional 
> weighting factor 
> > not so much a determining factor.  Degree is still used but 
> is not an 
> > overriding metric.
> 
> Good!  We modified our overlapping relay selection algorithm 
> a while ago to incorporate wireless link metrics into the 
> selection process...in addition to degree, overlap, and 
> Willingness.  We didn't update our draft to include this 
> since we think the selection algorithm of overlapping relays 
> need not be standard, allowing flexibility.  The behavior of 
> an active overlapping relay once selected is what should be standard.
> 

Thanks for the comment.
I think you're right it is more of a recommended practice.

But it can be a reasonably first order effect in some scenarios.

-Joe

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 24 Mar 2005 09:22:57 -0500

> team members have ownership of the proposals.

There is no issue with Overlapping Relays either, as this topic came 
up in the initial stages of the design team.  Here's a link to our
IPR statement.

https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=446

-Madhavi

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 24 Mar 2005 10:19:23 -0500

Hi All,

> be seamlessly integrated with OSPF (however, that also is not within the 

I agree that this is not within the scope of the DT right now.  However,
we must be cognizant of this fact.  Meaning, the DT should minimize the
changes to OSPF and the optimized flooding scheme, realizing that the
MANET WG may come out with a different flooding scheme down the line that
may need to be adopted.   As we all decided in the DT charter, we
should minimize the changes to OSPF, and any changes should be able to
work with standard OSPF nodes.

This is the approach that we (Cisco) have taken in our Overlapping Relays.  
The Overlapping Relays reduce the overhead in flooding as compared to 
standard OSPF (I will share some internal scalability testing that we did
in another email), without much changes to the way flooding works in OSPF.  
Essentially, Overlapping Relays suppresses redundant transmissions by 
neighbors without compromising reliability.  It uses timers and 
knowledge of 2-hop neighborhood which is already available in LSAs (this 
can also be done via Hellos if necessary), without modifying/affecting 
adjacencies, data plane, etc.  At most, it slightly delays flooding, but 
within the retransmission time.  Studies on packet delivery ratio and
throughput have shown favorable results (again, I will share our
scalability testing in another email.)

We have been receiving very positive feedback on its behavior *and* 
simplicity/compatability from our customers that have been using code 
drops of our implementation.

Thanks,
Madhavi