Subject: [Ospf-wireless-design] Minutes from first design team meeting

From: Abhay Roy <[email-masked]>
Date: Thu, 5 Aug 2004 17:15:42 -0700 (PDT)

Selected notes from OSPF design team meeting @IETF, August 4, 2004
(Tom Henderson and Abhay Roy)

Attendees:

  Acee Lindem
  Joe Macker
  Abhay Roy
  Tom Henderson
  Thomas Clausen
  Padma Pillay-Esnault

(manet as transit network or stub)

padma:  Would like a pointer to wireless models and background
information on this problem domain.  Also would like to understand what
is the optimum architecture scenario for this design effort.

acee:  is it possible for the manet cloud to be a transit for two fixed
wireline networks?

abhay: should be possible for manet to be transit

joe:  would like to see a wireless interface, need to understand first
order performance drivers.  existing MANET protocols probably handle
many of existing stub network configuration

Joe:  look at the stuff that reliable multicast transport has worked on.
A mix of streaming reliable and unreliable flows.  The NORM work.

tom: similarly, should we consider the generic flooding protocol under
development in MANET as a potential service to leverage?

joe: not sure. if it gets developed as something which we can reuse then
it's a possibility.

acee: should manet be like a stub area or be an interface scope? worry
about containing manet instability.

abhay: it's more of a deployment question. we should allow the
flexibility of being able to introduce a manet interface in any place in
the network.

(discussion on unreliable flooding)

abhay: in high mobility scenario it seems attractive to not have to
worry about acks. like a hybrid approach. tricky to switch between
reliable and unreliable. granularity could perhaps be per lsa.

tom: maybe just do reliable for now as long as possibility to perhaps add
unreliable later

[not clear if we will address unreliable flooding in first phase]

(hello optimizations)

acee: if hello overhead is not high, perhaps we should not attempt
to optimize it. focus on biggest overheads (flooding).

abhay: we are introducing various TLVs in hellos which make the overhead
a bit higher. not sure, if the overhead will remain low.

(discussion on scaling limits)

padma:  have seen up to 250 neighbors/node in certain customer networks

acee:  using modern memory and microprocessors, the I/O performance
dwarfs anything that is in the protocol.  I/O must be tuned.

joe:  some customers have asked for things on the order of a thousand
nodes, but some expectations are unrealistic

abhay: they do want 1000 nodes in the network, but not necessarily in
one area. we could work on some clustering like solution.

(area mobility and multi-area)

joe: fred's earlier work included how a node could move from one area
to other due to mobility

abhay: so far we are focussing one a single area. area mobility is
challenging in various respects. for e.g. if you could attach to
multiple areas how to choose?

[general agreement to keep the immediate solutions to single area]

(discussion on Cisco implementation status)

joe:  is this going to be a design team?  or is Cisco already committed
to a particular approach?

abhay: cisco is already developing the chandra draft

thomas:  what timeframe do we need to work towards to make sure that
design team outputs are not overcome by events?

abhay:  cisco will implement IETF standards when that becomes ready.
cisco looking for guidance on what areas we are charterd to work on, and
may sit back (for Phase II) on additional features that are of interest
to Cisco but not in charter of design team.

thomas:  would like the reverse-- would like cisco to educate the design
team on what the most useful features might be, rather than sitting back
(because cisco has direct customer input)

(discussion on layer2/3 APIs)

joe:  has done a lot of work on radio/router APIs.  things that can be
done to enhance performance (link sensing).

abhay: cisco has PPPoE interface along these lines. So it's possible
for radio to pass in information about link characteristics and also
about neighbor going down.

abhay: not everything needs to be standardized with respect to layer-2
information, because it doesn't change the protocol.

tom:  some things do, if they affect interoperability (like hello
suppression in lieu of layer-2 neighbor discovery).

tom:  also, some layer-2 issues are relatively straightforward (neighbor
up/down), but other such as time varying link quality being reflected in
the link metrics is trickier and requires hysterisis, etc.

(joe discussion on his experience with fading channels and extra things
that need to be done in protocols, such as hysterisis, and not relying
too much on reception of layer-3 hellos without low-pass filtering them,
to make them work in practical radio environments)

(goals of group)

abhay: need a contained charter to focus on what we work on

joe:  how to document results and issues of this design team?

padma:  need to write some of this guidance down (lessons learned about
wireless)

tom:  maybe OSPF MANET problem statement (Baker et al) is a good
starting point

joe:  that would need more work

thomas?: how long will group run for?

abhay: can we do something before next ietf? or will it take longer?

joe:  depends on what we decide to do and how hard it ends up being.

acee: we should finish the (new) problem statement before next ietf.

joe:  not necessarily going for the optimal solution in this group--
would like to start with something "simple"

tom:  what is "simple"?  maybe we should agree on modest scenarios

[general belief that the design team could take upto an year]

abhay: should the design team produce one final document?

(meeting outcome)

i) Agreed to work on a problem statement/scope (small 2-3 pages) as a
first step.  Acee and Joe to help craft a tighter problem statement.
Design team members should provide their inputs as to what is important
to have included in this statement.

In particular, what are the scenarios of most interest to participants
(can't design something to fit every conceivable scenario)

ii) group will provide some kind of draft specification?  not quite
consensus on this-- whether a single document, or modular.

iii) some kind of an informational document about the challenges of
wireless is also desirable (no one took action item to produce such a
document).

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

---

From: Abhay Roy <[email-masked]>
Date: Mon, 9 Aug 2004 09:24:15 -0700 (PDT)

Folks,

It was brought up during OSPF WG meeting that we should have a
lead to drive the design team activities. I would like to nominate
Tom Henderson for the job.

Regards,
-Roy-

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 10 Aug 2004 10:49:02 -0400

I second the nomination.  Tom seems to have done much
simulation work...and could guide the team towards
focused discussions.

-Madhavi

---

From: Joe Macker <[email-masked]>
Date: Tue, 10 Aug 2004 13:54:43 -0400

Tom is a good choice.
-Joe

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 12 Aug 2004 11:50:17 -0400

> a bit higher. not sure, if the overhead will remain low.

While I agree that Hello optimizations are probably 'second order'
when compared to the benefit of optimizing flooding, I don't think we
should dismiss it.  The more dense the network and low mobility, the
more benefit optimized Hellos will yield.   And, every bit of savings
will help...albeit without introducing unacceptable complexity.  I
would still like to see us consider/examine Hello optimizations in
this design team.  Maybe we'll come out with a hybrid approach.

-Madhavi

---

From: Richard <[email-masked]>
Date: Thu, 12 Aug 2004 16:04:32 -0700

(hello optimizations)

-Madhavi

I agree with Madhavi that Hello optimization (e.g., incremental

Hellos) can achieve a significant reduction in overhead in dense

networks, and in addition can allow the Hello Interval to be smaller

for faster reaction to topology changes in highly mobile networks.

I also agree with Abhay that the unicast Hello requests (and

the unicast replies to these requests) in Cisco's solution can

generate a lot of overhead in dense, highly mobile networks,

possibly cancelling the benefit of the incremental Hellos.

(I mentioned this last week on the OSPF list.)

To see how much overhead can be reduced by using incremental

Hellos versus full Hellos, I ran some ns-2 simulations yesterday.

I compared the incremental Hello protocol of TBRPF (RFC 3684)

to a modification of this protocol which uses full Hellos

similar to OSPF (each seen neighbor is included in each Hello).

(The TBRPF Hello protocol does not use unicast Hello requests,

but instead reports each neighbor change in 3 consecutive Hellos.)

Both protocols were run over IP over IEEE 802.11 with rate 2 Mbps.

The simulation model used 200 nodes in a 670x670 meter square,

the random waypoint model with a maximum node speed of 20 m/s,

a transmission radius of 250 meters, and a pause time of 0.

The Hello Interval was 1 second (reasonable for high mobility).

The simulation was run for 200 seconds, and produced the

following results (packet size includes IP and MAC headers):

Full Hellos       Incremental Hellos (TBRPF)

-----------       --------------------------

No. of Hello packes     42139             42132

Avg packet size           420 bytes         117 bytes

Hello overhead            708 kbps          198 kbps

The results show that incremental Hellos reduced the overhead

by about 72%.  It is reasonable to ask what the overhead

would be for LSA dissemination.  Although I didn't generate

LSAs for this experiment with 200 nodes (takes too long),

I did run it for 100 nodes, and the total overhead (for both

Hellos and LSAs) was reduced by about 48% by using

incremental Hellos, from 276.4 kbps to 143.0 kbps.

(TBRPF uses a very efficient mechanism for disseminating

partial topology information, but we shouldn't rule out

using equally efficient mechanisms for OSPF.)

Also, note that this method for incremental Hellos

always performs better than full Hellos, so there

is no need for a hybrid approach.

There might also be an IPR issue. SRI's IPR statement

for TBRPF states that any part of TBRPF that becomes

part of an IETF standard can be used by anyone for

free.  I'm not sure the same is true for Cisco.

Richard

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 17 Aug 2004 15:35:55 -0400

Since we seem to be having the Hello discussion on another thread,
I'll just comment on the IPR issue:

Our patents are defensive, and if there are any questions about our
IPR statement or licensing, they can be directed to Robert Barr -
Cisco's patent attorney ([email-masked]).

-Madhavi

On Thu, Aug 12, 2004 at 04:04:32PM -0700, Richard wrote: