Subject: Re: draft..-congest-control-01.txt : oob-resync++

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 9 May 2002 06:55:00 -0400

Hi Mitchell,

The general idea of the draft

http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control
-00.txt

is to reduce the rate of flooding in case of congestion, which has been the
cause of network collapses in the past(check draft for details). The draft
simply proposes a method to signal congestion and the minimum requirements
for putting in such a mechanism in place, to react to such a congestion and
to prevent such collapses in the future. The exact implementations have been
given as examples.

My comments are inline.

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 6:34 AM
To: [email-masked]
Subject: draft..-congest-control-01.txt : oob-resync++

Last 6 comments/suggestions...

A)
4.1.1:
There was an earlier draft Feb01 to Sept01 Out Of Band LSDB Resynch
by Cisco
Under the assumption that this functionality is
supported in two OSPF routers for the use of OOB LSDB Resync.

Due to the fact that most resynchronization work was already
done with this adj....
 I SUGGEST that this OOB adjacency should require
less work for re-synchonization, thus these ADJs should not be
considered as a single increment, as part of the MAX_ADJ_BUILD_CNT.
I believe that since they do require some work, a value of .5
(partial weight) could be considered per OOB ADJ re-sync work...

VM> I guess that can be done. However I guess we will have various other
scenarios where we could reduce or increase weight, say using different
values in case of P2P and broadcast(DR/BDR/DR-other). We have tried to not
get into this in detail and have assumed all adjacencies of equal values.

However I am sure an implementation can always do things the way you have
proposed.

B)
4.1.3
My assumption is that a CLI command should allow or disallow
this feature because it diverages from the OSPF Hello protocol.
My suggestion is that the default should follow the standard of
not allowing "OTHER CONTROL PACKETS" to detect Live-ness of the
adjacency.

This way if a router fails to send enough hellos or a router
is dropping a significant number of hellos,
        then at least the debugging of adj is eased,
        the system follows the OSPF spec,
        the administrator is aware of this variance,,
        etc.
VM> Well this does not create any problems. We are not proposing that in
case a control packet has been sent within the hello interval, do not send
the hello. The hellos are still sent as usual. This feature just improves
things and does not create any problems. Someone could always have this
feature as optional however(this is already done in existing implementations
already).

C)
4.2.2.2 MAX_LSA_FLOOD for each interface
This comment assumes a local (one interface) congestion setting
vs global cong(some subset of the interfaces) are contributing
towards congestion..

Would having a global value set that is NOT NECESSARILY the sum of
each of these per interface local values make sense? My assumption
is that if only 1 interface was having congestion, then its
value could be set to a "localized congestion value", where if a
number of its interfaces were having congestion then a "global
congestion value" could be used and split among the congested
interfaces.

The localized value SHOULD
be a higher value, since the router could devote temporaily
more of its resources to just one or a few of its interfaces...
Ex: If one interface has congestion then maybe its local
value could be say 100, where if say 5 interfaces have congestion,
then each should be set to 20.. This assumes a equal fair
interface value setting... Some implimentation may have some
interfaces be more important than others..

VM>The mechanism given in the draft is just an example. It has been clearly
stated that

"However, a mechanism is discussed here to illustrate how such a mechanism
might work."

A person could always implement it the way you have put it.

D)
4.2.2.4
nit.... "reduce the rate of the SPF computation"
Should the word "frequency' be used instead of 'rate'?
VM> Will do that.

E)
NEW Message Throttle Section...
Under the assumption that internal logging messages consume
resources, may overflow internal buffers, may obscure
important mesages, and that congestion may
generate a huge number of messages.

Messages could play a role in determining the
level of internal congestion. There COULD be a configurable
variable that can be set for "Message Throttling". This
assumes that messages will be placed in some form of FIFO
and lower priority messages be pruned when more than x
messages are awaiting transmission.
VM> I agree with you. I have observed that during simulations, that putting
the logging to minimum during congestion state helps. However I am not sure
we can add such a thing to the draft, which is not very OSPF specific.

F) Should their be a section on Random Early Discard
for incoming or outgoing packets?
VM> Random Early Discard(Detection) would be helpful in case, we were using
discard(retransmission) as a method to reduce the rate of flooding. We are
instead using explicit signalling as the method to do this, discard would
only cause retransmissions, which only means additional traffic. Does it
sound correct?

Thanks a lot,
Vishwas

---

From: Erblichs <[email-masked]>
Date: Thu, 9 May 2002 09:18:12 -0700

Just followup within section F, and three more nits..
Lets assume in some implimentations that RED (Random Early Discard)
drops protocol and data packets...

* Not all OSPF routers will initially support your new signaling / ECN
  (?Explicit Congestion Notification)

Internal nit...
Why don't you mention the term ECN in this draft? I think there
is a good paper by Sally Floyd in this area.. Alas, I think it
is directed towards TCP/IP...

* 4.1.3 Assumes that hellos are lost or significantly delayed. Assuming
the former they are then lost, then they are lost at transmission or
upon reception and are not retranmitted. Isn't this a form of RED?
And they are not re-xmit'ed based on missing acks :-) ..

* You implicitly specify the possibility of dropping of Database
Description LSPs, when you Throttle Link Adjs in 4.1.1..?
 Isn't this a form of RED?

So, my question should there be a section on what to do before
you start sending your low congestion notification? Like RED.

NIT...
In 4.2.1 you mention "medium congestion", where as your signaling
only speaks of heavy/high and low congestion signaling.. Did
you mean "avoid flapping of a router between high and low
congestion"?

NIT2...
4.2.1 : For consistency sake, should "heavy" be changed to "high"?

Statements:
Its very difficult to determine the exact
crossover point between high and low congestion.

Whether the sustaining of high congestion is eqivalent to TCPs
congestion avoidance code via the High_Congestion_Interval..

Should there be a Low_Congestion_Interval?
    If so,  whether this would be the eqivalent to TCPs slow start
    phase?

Mitchell Erblich
----------------------------------