Subject: Faster DD Exchange

From: Anup Kumar T <[email-masked]>
Date: Wed, 14 Dec 2005 22:27:31 -0500

According to RFC 2328, we send 1 DD packet, wait till the ack is seen and 
only then send the next DD pkt.  We can improve upon this. The idea is to 
send N DD packets initially. Then, as and when an ack is seen, send the 
next DD pkt. The existing DD Exchange procedure will have to be modified.
 
Once the trigger is set by the initial N DD packets, the successive 
exchanges will be faster (The waiting time is reduced). 
 
The routers can be made to negotiate the value of N before they enter into 
DD Exchange.  If they cannot negotiate (may happen during interoperation), 
they will default to the normal behaviour i.e. to send 1 DD packet.
 
- Anup

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 08:55:42 -0500

>they will default to the normal behaviour i.e. to send 1 DD packet.
Anup,

Why would we want to introduce a non-backward compatible change to OSPF 
DD Exchange? 
Have you quantitatively measured the improvement?  How does your loosely 
defined proposal
behave in the presence of OSPF packet loss? Since we're not going to 
entertain this (unless
someone can show a significant improvement in overall adjacency bring), 
I'm not going to
even get into the technical details.

On a related note, Richard Ogier has proposed a fully backward 
compatible change to OSPF
DD Exchange in the context of the OSPF MANET work. His proposal is for 
an OSPF router
NOT to include LSAs which have been received with the same or more 
recent instance from
the neighbor with whom you are forming an adjacency. This is one of 
those ideas that
once you hear you wonder why you didn't think of it :^).

Acee

---

From: Erblichs <[email-masked]>
Date: Thu, 15 Dec 2005 13:45:10 -0800

Group,

	Yes, filtering of LSAs are possible, but let me
	suggest something else and then comment on the
	filtering..

	Lets see how can we say get a X speedup for
	DD pkt xchanges?

	For those routers that have a multiple connections
	with a nbr:

		* split the LSDB into an equal number
	 	  of  groups as the number of nbr connections
	         (hopefully each having approx
	          the same number of hdrs that need to be
		  resolved), 
		   * Amdahl's(spelling) law says you can at best
		     get close because the flow workloads can't be
		     perfectly EQUAL.

		* then process each group concurrently, with
		  each group having a different set of DD pkts,
		
		* at the completion of the exchange of DDs
		  or complete LSDB xchange, recombine the
		  LSDB.

	Thus the speedup can be 2x, 4x, 8x etc when the
	individual link speeds are a bottleneck. This is
	mostly helpful with kb/sec links or where we have
	a overwhelming ability to process pkts in incoming
	ports simultaneously,

	The speedup can even be greater if one side has the
	LSAs that need resolving for we are continually waiting
	for the next DD pkt. And it is not sent until we see
	the ACK. So in extreme circumstance we can cut in half
	our expected DD exchange time. Two links can result in
	a 4x speedup due to each ACK requiring a min of 1 RTT!!!!!
		
	It is also helpful
	when one wishes to send smaller than MTU size DD
	pkts for fewer rexmits. This last item assumes that
	with wireless the chance of say a 9k jumbo has a
	significantly greater chance needing rexmits than
	say a 254byte pkt.

	This is in effect aggregation.

	Mitchell Erblich
	PS: On a side note, doesn't the Ogier proposal assume
	that the effort to filter the LSA headers that are to be 
	removed from DD exchanges beneficial?

	 * Some of the LSA hdrs being xmited CAN to be filtered,

	 * That the number of filtered hdrs is significant.
	
	 * Doesn't the complete exchange of LSA headers verify
	   synchronization?

	 * Won't the LSAs hdrs that are filtered result in
	   the recvr having a subset of EXPECTED set of hdrs?
	   Doesn't this require a check that missing hdrs are
	   already present?

	 * For short duration lifetimes of LSAs or short remaining
	   lifetimes of LSAs,  we can DELAY and update the nbr with a 
	   newer instance during DD exhange.

	==============================

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 18:14:49 -0500

Hi Mitchell,

I won't comment on your proposal (I'll wait for the draft ). However, 
see inline for
answers to your questions.

>	 * Doesn't the complete exchange of LSA headers verify
No - you don't need to advertise LSA you know that your neighbor already 
has. The
Database exchange is a "pull" model. You advertise what you have and the 
neighbor
with whom you are establishing an adjacency decides whether he needs it.

>	   Doesn't this require a check that missing hdrs are
Nope. See above.

>	   newer instance during DD exhange.
Reliable flooding solves this by flooding to all neighbors that are >= 
Exchange state.

Thanks,
Acee

---

From: Nitin Kakkar <[email-masked]>
Date: Fri, 16 Dec 2005 08:39:54 +0530

Group,
We had submitted a draft on IETF on it. Same is being sent to group for your
kind reviews. A copy attached here.
Regards
Nitin

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, December 16, 2005 4:45 AM
To: [email-masked]
Subject: Re: Faster DD Exchange

Hi Mitchell,

Nope. See above.

Thanks,
Acee

---

From: Nitin Kakkar <[email-masked]>
Date: Fri, 16 Dec 2005 08:36:07 +0530

We were working on the same, We have a small draft for it, please have a
look and let us know your opinion.
Regards
Nitin

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Erblichs
Sent: Friday, December 16, 2005 3:15 AM
To: [email-masked]
Subject: Re: Faster DD Exchange

Group,

		

		
	It is also helpful

	Mitchell Erblich