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

["Manral, Vishwas" <[e-mail]>]

Mitchell,

The idea we have is to actively and explicitly signal congestion, rather
than have an implicit control mechanism. The reason is that explicit
signalling of congestion is better in case of delay sensitive
applications(here a lot of rxmts would result in case we delayed), so if we
suddenly were getting congested, then using explicit notification, we could
actually signal such a thing soon enough. In case of implicit congestion
notification, it would take a longer time to reduce flooding rates by
neighbors.

Also as we are using two levels of congestion "Low" and "High" we could
signal low congestion well before we are heavily congested.

My comments inline prefixed with a "VM>".

-----Original Message-----
From: Erblichs [mailto:[e-mail]]
Sent: Thursday, May 09, 2002 9:48 PM
To: [e-mail]
Subject: Re: draft..-congest-control-01.txt : oob-resync++


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

VM> I guess we still can use the term ECN. That is exactly what we want, to
have all routers have a common mechanism for congestion notification. We
also reduce our own rate of flooding whenever we feel the network is
congested.

* 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 :-) ..

VM> As I told you we would rather have an explicit congestion mechanism than
an implicit one. Also I do not know how many people would agree to drop
hellos got from neighbors, after all we are trying to keep the adjacencies
up, and dropping could have an adverse effect. Check section Appendix A, it
talks about a very interesting proposal, which we had a lot of resistance to
and had to remove from the main body of the draft(although we had
experimental evidence to support the advantages).

* 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.
VM> Having implicit congestion control can always be done on the router,
even if we support an explicit mechanism. However I am not sure people would
be happy about explicit drop of packets. We could however use delays in
getting Acks and number of retransmits to reduce flooding rate, however a
lot of protocol factors like delayed ack etc would come into picture.
Dropping some packets so that we do not bring an adjacency up, would be
different from the case where we use drop to signal congestion.

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"?
VM> I guess we need to correct that. Initially we had thought of 3 levels of
congestion, we later thought of just going in for 2.

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

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?
VM> I guess that can be done too.

Thanks,
Vishwas

"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