Re: Comment on draft-ogier-manet-ospf-extension-00.txt

"Spagnolo, Phillip A" <phillip.a.spagnolo@BOEING.COM> Mon, 23 February 2004 20:54 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19471 for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Feb 2004 15:54:29 -0500 (EST)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00CFFD3C@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 15:54:29 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3600453 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 15:54:28 -0500
Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 15:54:28 -0500
Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA07300 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Feb 2004 14:54:27 -0600 (CST)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id OAA12466 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Feb 2004 14:54:26 -0600 (CST)
Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1NKr1s21014 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Feb 2004 12:53:01 -0800 (PST)
Received: from xch-nw-26.nw.nos.boeing.com ([192.48.4.100]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 23 Feb 2004 12:51:34 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: Comment on draft-ogier-manet-ospf-extension-00.txt
Thread-Index: AcP6RHDmAPVg5G9HSoODQXfPBkyp8QAAwBDQAAGWxFA=
X-OriginalArrivalTime: 23 Feb 2004 20:51:34.0128 (UTC) FILETIME=[D26D5700:01C3FA4E]
Message-ID: <2AFCB5FA378DEE4CA704B9AD7764637901839BA3@xch-nw-26.nw.nos.boeing.com>
Date: Mon, 23 Feb 2004 12:51:33 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Spagnolo, Phillip A" <phillip.a.spagnolo@BOEING.COM>
Subject: Re: Comment on draft-ogier-manet-ospf-extension-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable

Richard,

Section 6.1 of your draft states:
   A router can decide to suppress ACKs for a given LSA if a new
   instance of the LSA (with a larger sequence number) is usually
   received every RxmtInterval seconds (e.g., 5-10 seconds).  An
   exponential moving average of the time between LSA updates, or of the
   number of LSA updates during the last RxmtInterval seconds, can be
   maintained for each LSA. Two thresholds can be defined to employ
   hysteresis in deciding whether to suppress ACKs for a given LSA.

We thought the above mechanism would effectively reduce the amount of
overhead due to useless acks.  It potentially allows for a hybrid
operation between reliable flooding during periods of low link change
and periodic flooding under high link change.  Therefore, we decided to
take a look at this technique in isolation, as applied to OSPF.
Specifically, we looked at a QualNet OSPFv2 simulation with
Point-to-Multipoint interfaces on 802.11b network, a random waypoint
mobility model, and only the above suggested modifications (no other
wireless-oriented changes such as flooding optimizations).

However, somewhat to our surprise, the simulation results suggest that
the performance gains may be elusive, at least in the mobility model we
tested.  Specifically, 

- the approach adapts to the link changes passively by predicting the
future based upon the history.  However, we found it difficult to
predict based on the past, looking at both fixed and exponentially
weighted windows with different window sizes and weights.  In fact, it
looked almost as if the interarrivals were exponentially distributed
(modulo the MinLSInterval).  Not only was there a degree of
unpredictability in the actual generation of the LSAs, the practice of
OSPF flooding further filters the interarrival process from the
perspective of a given node that may be multiple hops downstream of an
originator.  Due to inaccurate estimates, the overall overhead went up
in all simulations, and the delivery ratio went down.   The LSAcks are
reduced, but LSUs are increased (more retransmissions).  

- even if each node suppresses the ACKs, the LSAs are flooded through
out the network during rapid link changes around the originator.  These
LSAs generate much higher overhead than the ACKs (overhead due to LSA
transmissions dominates that of the ACKs).  

- the approach assumes senders use the same RxmtInterval as its own
value and requires sender uses same RxmtInterval for all neighbors. This
requirement may force the RxmtInterval to be interchanged between
neighbors like the hello and dead intervals, or make it into an area
parameter.

We are preparing a draft that will provide more details about this and
related topics, but just wanted to note that the early results were not
promising.

Phil