Subject: RE: [Ospf-wireless-design] new material to review and discuss

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 22 Oct 2004 10:14:12 -0700

Yes, I could give a short update at the IETF meeting.

Perhaps my document was a bit much for people to digest last week, but in a nutshell, I would like to come to agreement on the following points:

- Design team adopts problem statement as modified by design team list discussions
- Design team focuses on defining a MANET interface type, not a MANET area type.   
- Design team focuses first on defining an optimized flooding mechanism for LSA dissemination.
- Design team focuses on acknowledged (reliable) flooding, leaving periodic flooding as a future optimization.

and having done so, I would like to consider as a next step the tradeoffs between MPRs and CDS as the relay node set used for flooding (which is described in much detail in Section 3.2 of the draft that I sent around).

Tom

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Friday, October 22, 2004 9:21 AM
> To: Henderson, Thomas R; [email-masked]
> Cc: Rohit Dube
> Subject: Re: [Ospf-wireless-design] new material to review and discuss
> 
> 
> Tom, 
> 
> Can we schedule a OSPF wireless design update for the Washington 
> IETF? What I think would be good would be a presentation on the
> attached document with ample time for WG questions. 
> 
> Did anybody else have anything relevant to the OSPF wireless 
> effort that
> they wanted to present in Washington? I've had a lot going on lately
> and realized today that time is running short. 
> 
> Thanks,
> Acee
> 

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

---

From: "Acee Lindem" <[email-masked]>
Date: Fri, 22 Oct 2004 13:55:22 -0400

Here is my take...

> - Design team adopts problem statement as modified by design team list discussions

Agreed. However, I think it is still extended work plan is still open for debate.  Do we
need to change/optimize additional OSPF mechanisms for wireless (e.g., database exchange).
Possibly, there be a better other mechanisms or policies that would yield more
bang-for-the-buck.

> - Design team focuses on defining a MANET interface type, not a MANET area type.

I think that since all the work done heretofore has been based on the MANET interface
type we need to stick with it. I know there have been suggestions that the OSPF area
might be a better boundary for flooding changes (I think I may have said this ;^). However,
there are no proposals on the table.

> - Design team focuses first on defining an optimized flooding mechanism for LSA dissemination.

Agreed.

> - Design team focuses on acknowledged (reliable) flooding, leaving periodic flooding as a future optimization.

Agreed.
>
> and having done so, I would like to consider as a next step the tradeoffs between MPRs
> and CDS as the relay node set used for flooding (which is  described in much detail in Section 3.2 of the draft that I sent 
> around).

Tom

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 23 Oct 2004 01:18:24 +0200

Tom, Acee et. al.,

Quoting "Henderson, Thomas R" <[email-masked]>:

> Perhaps my document was a bit much for people to digest last week, but in a
> nutshell, I would like to come to agreement on the following points:
>

I've been everywhere but in the office lately, so I apologize for not having had
time to comment on your document. I've read it, though, and it's quite good!

I would like to voice agreement with the above items, with exception for the
last: I believe that we definitely should include both reliable and periodic
flooding as options-to-consider, also initially. Indeed, I do believe that one
of the realizations of the MANET working group is, that periodic floding may be
beneficial in manet-style networks (Richard, Joe back me up here). As such, I
believe that scoping this completely out of the discussion at this stage would
be ill adviced. I would advocate a sensible hybrid approach, if at all
possible.

> and having done so, I would like to consider as a next step the tradeoffs
> between MPRs and CDS as the relay node set used for flooding (which is
> described in much detail in Section 3.2 of the draft that I sent around).

Just one brief comment here: I disagree with the terminology chosen. MPRs do
form a CDS -- indeed the MPR algorithm is an instance of a CDS algorithm. As
such, it doesn't make much sense to chose between them. I'd suggest that we,
rather than "chose between them" consider which features we need -- and then
pick an algorithm that fits (notice, I did write "pick", not "develop" -- for a
reason).

I know what's meant by "MPR vs CDS" above, since I've been part of the process
and discussion -- but to the outsider, this might be a source of
misunderstanding, so I'd reccomend that we do not present it as a "choise" of
either or....

Cheers,

--thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 23 Oct 2004 01:29:59 +0200

> Possibly, there be a better other mechanisms or policies that would yield

I just have to ask: we know from our research that there are mechanisms which
would yield more "bang-for-the-buck" in the manet-type scenario. However these
would in many ways divert from the traditional OSPF-mechanisms (both in scope
and form), and have not been proven by large-scale deployments etc. To which
extend are we going to include such in the work of this design-team?

My personal feeling is, that this could cause undesired research-creep: to my
knowledge, there's no concensus on such, as well as no "real-world-experience"
(well, Richard and I have at some point had similar thoughts on e.g. database
exchange, but that does not a coherent mechanism yield nor does it indicate
wider concensus). So it might be a process of maturing such mechanisms, and
convincing ourself that it's usefull. As a researcher, I'd think this would be
interresting (of course) to venture down that path.

It's a trade-off, but I wanted the teams input.

--thomas

> between MPRs
> > and CDS as the relay node set used for flooding (which is  described in
> much detail in Section 3.2 of the draft that I sent
> > around).
>
> Tom
>
>

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 25 Oct 2004 13:36:41 -0400

Hi Thomas,

> be ill adviced. I would advocate a sensible hybrid approach, if at all

We are also very interested in looking into a hybrid scheme...however, as a 
'Phase II' task for the DT.  To meet the DT timeline, it seems that we 
had reached agreement as a DT last month to focus on reliable flooding 
for Phase I as indicated in Section 1.2.  I propose that we follow 
this, and defer the hybrid scheme for our next set of tasks (Phase II).

Regards,
Madhavi

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 25 Oct 2004 13:39:54 -0400

Hi Thomas,

> It's a trade-off, but I wanted the teams input.

I completely agree with your take on it.  We're also toying with some
database exchange optimizations...but, as you said so well above, it might
be a process of maturing such mechanisms.  My vote it to chalk this
up to a Phase II task for the DT....so it doesn't bog us down in Phase I.

Regards,
Madhavi

---

From: Richard <[email-masked]>
Date: Wed, 27 Oct 2004 09:39:51 -0700

Hi Thomas,

>interresting (of course) to venture down that path.

I think it depends on how novel the proposed mechanisms are. Some of
the techniques we are proposing have been throroghly tested in other
protocols such as IS-IS and therefore are more mature and less
"researchy". For example, the periodic DD packet technique I am
proposing is just an adaptation of the periodic sequence numbers packets
of IS-IS. To achieve efficient, reliable flooding in MANETs, *some*
novelty is needed, since this has not been done before. For example,
Cisco's proposal (in which ACKs are multicast and non-MPR nodes can
forward LSAs) is novel, and perhaps more "researchy" than simply
adapting the IS-IS technique.  It might be better to adapt the
well-tested technique from IS-IS than to invent new mechanisms
for efficient, reliable flooding. If adapting the IS-IS technique
results in more efficient flooding in highly mobile networks,
and if it also leads more quickly to a mature protocol, it would
be a shame to ignore this approach. If we wait until Phase II before
we consider this approach (which does not use ACKs), then we *might*
find that the ACK-based flooding mechanism developed in Phase I
is obsolete.

Regards,
Richard

>>>- Design team focuses on defining a MANET interface type, not a MANET area
>>>
>>type.
>>
>>>- Design team focuses first on defining an optimized flooding mechanism for
>>>
>>LSA dissemination.
>>
>>Agreed.
>>
>>>- Design team focuses on acknowledged (reliable) flooding, leaving periodic
>>>
>>flooding as a future optimization.
>>
>>Agreed.
>>

---

From: Joe Macker <[email-masked]>
Date: Mon, 25 Oct 2004 11:13:17 -0400

Are we planning to meet separately as a design team in DC as in San Diego?
I thought that was a very productive forum last time..

Sorry about nasty message wrapping in my last few e-mails, just switched clients and didn't catch the default settings right away...

-Joe

---

From: Joe Macker <[email-masked]>
Date: Fri, 22 Oct 2004 15:47:05 -0400

> - Design team focuses first on defining an optimized flooding mechanism for LSA dissemination.
optimized flooding seems a little general given the next statement. I 
assume here we mean we will work on a mechanism for reduced forwarder 
sets (e.g., MPR, whatever)...below is the reliability aspect.?

Is that the correct interpretation...?

> and having done so, I would like to consider as a next step the tradeoffs between MPRs and CDS as the relay node set used for flooding (which is described in much detail in Section 3.2 of the draft…

(you probably have see my last note by now)...its redundant so forget 
it...read this instead

I reread the new 3.2 section, I see you defined MPR as source-dependent 
CDS and explained  CDS better, but there's some implication MRP isn't 
CDS. Maybe this is all from Richard's tutorial.  From a graph theory 
point of view I am still confused.  I prefer the terms SI-CDS and SD-CDS 
used in literature.

SD-CDS = source dependent CDS
SI-CDS = source independent CDS

But the section is well-written and provides a discussion dropoff point.
Good work...

One thing to note in section 3.2.1.4
Specifically, some researchers (e.g., [10]) have shown simulation
    results that show smaller size relay node sets when using CDS,
    although in the author's opinion, this evidence may be
    scenario-dependent and does not strongly favor one or the other.

-------------------------
I agree with you Tom, as further evidence for further discussion...

in fact "some researchers [Wu etal, and others] state the opposite of 
the above is true"

That basically typical SD-CDS (MPR-like)algorithms produce smaller sets 
than SI-CDS algorithms...

We analysed SD-MPR against a global knowledge clustering algorithm 
(SI-CDS) for up to 100 nodes in a random graph.. ther results showed 
about the same relay set size.  The SI-CDS was much simpler.. Just one 
example I realize that..

Some numbers may also depend how people count the relay set in use..
In a SD-CDS algorithms not all relays are active in the forwarding for 
every packet (in SI they are), since this is source dependent (at least 
previous hop dependent)...

"active relays" used for a given source are usually smaller in SD.

In conclusion, I think it is scenario and algorithm dependent and also 
depends on how one counts the forwarding set used (active vs. total number).
--------------------------------

---

From: "Acee Lindem" <[email-masked]>
Date: Fri, 29 Oct 2004 08:09:49 -0400

Hi Joe,

----- Original Message ----- 
From: "Joe Macker" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 25, 2004 11:13 AM
Subject: Re: [Ospf-wireless-design] new material to review and discuss

> I thought that was a very productive forum last time..

For me it would have to be Tuesday. I'm in a transitionary period and am only
going to be at the IETF Monday and Tuesday.

>
> Sorry about nasty message wrapping in my last few e-mails, just switched clients and didn't catch the default settings right 
> away..