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

[Erblichs <[e-mail]>]

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
----------------------------------



"Manral, Vishwas" wrote:
>
> 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:[e-mail]]
> Sent: Thursday, May 09, 2002 6:34 AM
> To: [e-mail]
> 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