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
- Re: Comment on draft-ogier-manet-ospf-extension-0… Spagnolo, Phillip A
- Re: Comment on draft-ogier-manet-ospf-extension-0… Richard Ogier
- Re: Comment on draft-ogier-manet-ospf-extension-0… Spagnolo, Phillip A