Subject: Prioritized Treatment of OSPFv2 Pkts.. draft 9..

From: Erblichs <[email-masked]>
Date: Tue, 22 Feb 2005 01:05:05 -0800

Group,

	This draft has been in draft for about 2 years and
	maybe I think it is moving in the right direction.

	Over the years, I have learned alot about CA
	in what works and what doesn't. Here is a set of
	suggested changes for this document in "prioritized
	order" ..

	This set of Recommendations really includes Congestion
	Relief/Mitigation as modifing the rexmit interval 
	assumes that congestion is already present and we
	will decrease the amount of congestion based on our
	actions.

	A) (4)Implicit Congestion Detection and Action based on That:

	"can implicitly detect it based on the number of
	unacknowledged LSAs to this router"

	No.........

	FYI: LSAs are placed on a rexmit list when initially
	xmited. To implicitly detect the level of nbr scope 
	congestion, one must timestamp each LSA placed on this
	nbr rexmit list.

	Only the LSAs that have a age greater than the arch
	specified rexmit interval can then be summed and then
	divided by the number of these late ack'ed LSAs. The
	greater the result value, the greater the current level 
	of nbr congestion which is time dependent. If the value
	is at X.xx and we have 10k LSAs present, I don't know
	that we can even consider the adj router as congested.
	It is possible that we have the acks in our in pkt list,
	so minimally a delayed rexmit should follow only AFTER
	we check our input FIFO pkt list for these acks.

	One could also measure the avg time the LSAs are present
	on the rexmit list per nbr, to check the min LSA ack
	time. The rexmit interval should be 5 secs more than this
	min value as a begining value.

	The reason for this is that we may aggregate the LSAs
	into the control pkt, have a unknown latency to xmit
	the pkt, the recv'r then needs to process the pkt (maybe
	behind a LSA storm), then
	send the pkt, which we then have another media xmit
	latency, AND then we have to process it which may be
	behind another LSA storm.

	B) (5) Throttling Adjs to be brought up Simultaneously:

	FYI: Not all pre-full adjs are equal! The best load
	dependent measurement that a single adj should be
	based on the size of the sum of the LS Request sizes.
	This sum is close to "0" for what I consider warm
	LSDBs, which are almost fully populated with LSAs.
	Versus the number of tobe LSAs present * LSA size for a "cold"
	LSDB. Thus, I feel that warm LSDBs should not be
	counted. They will only exchange Database Description
	pkts and force lookups of each LSA header.

	Simply a warm LSDB exchange occurs between the DR and
	BDR after they formed their adjs with others. Just the
	originated LSAs from the DR and BDR need to be specified
	in the LS Request pkt. Close to 0% of LSAs. A cold
	LSDB exchange is when two DRs merge their LSDBs after
	a merge. 100% od LSAs would need to be specified in the
	LS Request pkts.

	So, to summarize, only cold LSDB adjs SHOULD be counted
	and throttled to minimize LSA flooding loads..

	Fewer simultaneious adj formations CAN result in significantly
	longer convergence times due to repetative SPF calcs based
	on multiple no MTU sized Update pkt flooding.

	If the number of cold LSDB adjs is too small then the resultant
	 Update pkts may not at least MTU size and repetative pkts
	will need to be flooded.

	The order should NOT be FCFS. Recently dropped adjs
	should be penalized and placed at the end of the order.
	Hopefully, the event that caused the lost of the adj
	was infrequent and transient.

	C) (1) Classify all OSPF pkt in two classes..

	If we assume that we can pre-process the OSPF hellos and
	other control pkts and ...

	  have one FIFO list: We just need to be able to set a
	  flag to determine whether we have experienced
	   tail-drop (lose a pkt off the end due to a memory
	   shortage) and if we haven't we know that all rec'ed
	   pkts are present. If we assume that a adj loss due
	   to a LSA storm is rare, then we process the control
	   pkts as normal. IFF we loose an adj (we identify the
	   number of pkts on this list), process that count of
	   pkts and determine whether we continue with the adj
	   or destroy it. This is based solely on whether the hello
	   pkt was found, but just delayed its processing due
	   to a large number of LSAs showing up before it.

	  have one FIFO list, but we support RED (random early
	  discard) of non hello pkts to make sure that we don;t loose
	   hello pkts based on memory exhaustion and
	  proceed as above.

	  have two or more FIFO lists, and allocate one to hello
	  pkts to verify that we never drop hellos, due to a LSA 
	  storm

	So, even in the worst case in the in above delayed hello 	processing,
all the hello multiplier count of nbr hellos
	would have to be dropped for us to drop the adj..

	D) NEW: Congestion really has SCOPE and TIME.

	This draft still does not recognize that congestion
	and recommendations of Avoidance / Awareness/ and
	Mitigation..

	Nbr congestion (transient and prolonged)
	One nbr could be "congested" because of a extensive
	LSDB aging and chksum scan, requried flooding, and a
	multiple area SPF calc that takes X amount of time.

	Link Congestion : One of more nbrs on the same link
	This normally occurs when a set of routers are
	initially synchronizing their LSDBs..

	Area Congestion : Multiple events are occuring
	which effect all the links/routers in a area.

	Global Congestion : Multiple areas are experiencing
	an event that is effecting more than just an area
	scope.

	E) Use the Exponential backoff algoriithm

	First, see A for the min LSA ack time. Without a
	min value, you do not know really where you need
	to start with. This should give you a value that
	will scale based on the link-bandwidth.

	A exponential value assumes that inflight pkts
	are causing a lag, which we need to compensatre for.

	The problems with exponentials is that as they increase
	the courseness of their higher values can and will
	lead to excessive convergence timeframes.

	thank you,
			Mitchell Erblich