Subject: RE: [Ospf-wireless-design] DT Direction...

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 14 Sep 2004 16:06:28 -0700

> -----Original Message-----
> From: Madhavi W. Chandra [mailto:[email-masked]] 
> Sent: Wednesday, September 01, 2004 9:23 AM
> To: [email-masked]
> Subject: [Ospf-wireless-design] DT Direction...
> 
> Phase I of OSPF-MANET Design Team
>
> Assumptions for Phase I: 
> o single flat area
> o goal is to reduce overhead
How about adding:
  o MANET wireless channel is considered to be a special 
link type, in parallel with existing five OSPF link types
  o radio transmissions are broadcast and may or may not
reach all nodes on the link

> 
> Requirements based on customer feedback:
> - Define Wireless interface
> - Optimize Reliable Flooding mechanism
> - Reduce overhead
>   - Hello process
>   - Database exchange process
> 

So far, no one has sent in the kind of (physical) requirements 
that I was mainly interested in, such as the need to handle 
certain size networks, with certain topological properties
(density), and rates of topological change, within a given
bandwidth constraint (and possibly other performance requirements).  
The above quoted requirements are not really requirements but 
are techniques to reduce overhead.

So far, I have not heard anyone raise objection to the general
principle of reducing OSPF overhead for these types of networks.
However, what we will probably need to decide upon is "how
much overhead reduction is enough?"  When do we declare success?

> Timeline:
> For credibility of DT and realistic adoptment, we should have a 
> focused problem statement and milestone deliverables.  I will
> suggest the following:
> 
> * Problem statement consensus by Sept. 15 
> * Design Wireless Interface scope by Oct 15
> * Design of Flooding mechanism by Dec 1
> * Design to Optimize Hello process by Jan 15
> * Design to Optimize Database Exchange by Feb 15 
> * Draft submission to WG by March IETF

I agree with the objective of a March IETF target to
wrap up this design team.  I do not know whether some of
the incremental milestones will come to pass like that,
but I would support working towards an Oct 15 target
for defining the scope of the extensions.

>
>
> Possibilites for Phase II of Design Team:
> - Clustering mechanism for scalability
> - Unreliable Flooding mechanism
> - Multiple areas

I am OK with deferring unreliable (periodic) flooding until
we see how far we can get with acknowledged flooding.  The
point of our simulation-based contribution was to convey that,
in our recent experience, we have not been able to approach 
the overhead savings offered by periodic flooding.  Therefore,
I would be partial to a solution that keeps the door open to
a future periodic flooding mechanism of some sort (whether
it be by OLSR-like flooding semantics, or manipulation of
retransmission timeout intervals like Richard previously 
suggested).

Tom 

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

---

From: Richard <[email-masked]>
Date: Tue, 21 Sep 2004 07:59:23 -0700

>retransmission timeout intervals like Richard previously 

For the record, as stated in the current version of my draft
(and in my emails), I no longer propose manipulation
of retransmission timeout intervals, but prefer the
hybrid approach in which the source decides whether to send
ackable LSAs or periodic non-ackable LSAs, depending on how
often the LSA changes. Since reliable flooding is more efficient
in low-mobility wireless networks, and periodic unreliable
flooding is more efficient in high-mobility networks, I think
a hybrid approach is best. But I have no problem focusing on
reliable flooding in Phase I.

Richard