Subject: Re: draft..-congest-control-00.txt : New sect

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 27 Apr 2002 03:26:18 -0400

Hi Mitchell,

Comments inline.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Saturday, April 27, 2002 4:08 AM
To: [email-masked]
Subject: Re: draft..-congest-control-00.txt : New sect

        I guess it is, except...

        1) RFC3137 is specific to Stub Routers and my suggestion isn't.

VM> What do you mean by stub routers, routers in stub areas? The abstract of
RFC3137 says: -

   This memo describes a backward-compatible technique that may be used
   by OSPF (Open Shortest Path First) implementations to advertise
   unavailability to forward transit traffic or to lower the preference
   level for the paths through such a router.  In some cases, it is
   desirable not to route transit traffic via a specific OSPF router.
   However, OSPF does not specify a standard way to accomplish this.

Isnt this what you desire?

        2) If the local router is experiencing congestion, and
           delays SPF computation, then this router should not
           be used to forward data packets, if there is an
           alternate available that is not congested.

        3) If there are legacy routers that don't yet support
           one or more items that you suggested in your draft,
           then this would be better than nothing.
                A) *** Because of 5)
                B) *** Could be used as part of 4.1.3 "Use of
                    other Control Packets to Detect Live-ness" ...

        --- Ditto the B as it was implicitly suggested in your
            draft..(Not caring about legacy routers).
VM> I am sorry I did not understand. However some existing OSPF
implementations already use control packets as surrogate hellos. There is
never any talk of "legacy routers". ;-)

        4) If there are multiple routers in the area that are
           all experiencing local/internal congestion.
                4.1) An additional
           item that set the DNA (do not age bit) would decrease the
           amount of work being done by the lsdb scaning proc in
           the router that rcv's and processes the LSAs. This would
           also decrease the number of originated control LSAa over
           time..
VM> How LSDB refreshing(scanning) is done, is done differently by
implementatons. We can use DNA bit however with the other methods in place,
we can do without this(there would be other additonal issues which would
prop up)

           4.2) Yes, then if the congestion was being experienced by a
           number of routers, after the initial flood, and the congestion
           subsided. There could be a excessive amount of flooding
           to reset the cost metric if they all experienced the
           subsiding of congestion simultaneously. To resolve this
           they should probably by default do a random time for
           the reflood to happen. This should flatten our a storm
           of broadcasts...
           ( Or what you did in 4.2.2.2 MAY be ok). Yes, I have atleast
                1 sugestion here.. It has to do with the scalability
                of this value. As the number of routers supported
                on this interface increasses, the total number of
                LSAs that can be flooded increases.. Yuck... Shouldn't
                it be inversely scaled as the number of routers on the
                interface increases? (MAX_LSA_FLOOD) And limit each
                router on that interface to this other value. But
                what do you start with? What happens if you have
                a router sharing this interface that doesn't support
                this "flood limit". Should you decrease based on
                the neighbor's amount of flooding?
                This needs some thinking...
VM> As I told you we are trying to focus on reducing control plane traffic.
So this case does not arise.

        5) Depending on the architecture of the OSPF speaking router,
           the processing / forwarding may consume some resources
           that should be being used for the control packets. And thus
           take longer for the congestion to subside..
VM> Ok.

Thanks again.

"Manral, Vishwas" wrote:
>
> Mitchell,
>
> Thanks for the nice idea you have given. A thing similar to what you have
> said exists in OSPF, check RFC3137 - OSPF Stub Router Advertisement.
>
> The idea however does not help much in the case of congestion caused by
> control protocols traffic, as the flooding still takes place normally,
> though the data traffic may be reduced. We are trying to focus more on
> reducing control traffic here.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 10:29 PM
> To: [email-masked]
> Subject: Re: draft..-congest-control-00.txt : New sect
>
> Suggestion for a new section...
> Sorry, I have done alot of work with congestion and scaling...
>
> With the assumption of heterogeneous devices that support
> different levels of support for congestion, I would to
> add something like the following for the legacy devices.
>
> With the knowledge of sustained local congestion, some
> processes may have delayed processing of such items
> as the Link State database (See the 4.2.2.4 section).
>
> Thus, to support the legacy devices it is suggested that
> some flooding of originated LSAs with excessively high
> link cost metrics be done. This value should be set to
> LSInfinity or a close approximate value. This should minimize
> the use of this congested router as a transit router
> while under congestion...
>
> When congestion subsides the LSAs may be re-flooded with the
> appropriate costs of this non-congested link.
>
> Mitchell Erblich