Subject: draft ospf-scalability-04.txt

From: Erblichs <[email-masked]>
Date: Wed, 21 May 2003 13:14:31 -0700

Comments::

        Possible problems...

        2. Recommendations

        1) Classify "all" ...

                        Looking at a storm of Hello packets may starve
                        other OSPF packets from being processed. Try
                        simulating 400 nbrs sending a hello every 10 ms.

                        Queues tend to be finite and dropped low
                        priority packets may result due to queue
                        overflows.

                        Recieved packets arrive in FIFO order, so to
                        process after classification may require
                        time stamping packets. This would minimally
                        allow detection of illegally minimally spaced
                        rexmits.

        3) Use of Exponential Backoff algor..

                        Ethernet uses a Backoff algorithm... In this
                        type of environment, wouldn't local congestion
                        (congestion within a subnet) cause
                        the backoff to occur anyway due to increased
                        collisions?

        4) Implicit congestion ...

                        ... exceeds a certain "high water mark" then

                        Shouldn't we exponentially decrease (#3) the
                        LSA rexmit rate? We have to assume that we
                        are in a heterogeneous environment (some
                        routers don't support congestion control) and
                        that the internal router's queues could be
                        full AND take some time to process...

                        ... falls below a certain "low water mark" then
                        the normal rate of sending ...

                        Should a TCP like method of gradually increasing
                        the LSA retransmit rate be implimented? Wouldn't
                        this remove / significantly remove the chance of
                        "LSA rexmit thrashing".

        Mitchell Erblich
        Sr Software Engineer

---

From: "Choudhury, Gagan L, ALABS" <[email-masked]>
Date: Thu, 22 May 2003 09:14:16 -0500

Mitchell,
   Thanks for your comments.  The responses are in-line.  With regards,

                Gagan  

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 4:15 PM
To: [email-masked]
Subject: draft ospf-scalability-04.txt

Comments::

        Possible problems...

        2. Recommendations

        1) Classify "all" ...

        Response: In the example you have, the steady-state hello rate is
        so high that perhaps the processor cannot keep up with it.  Note
        that this is a steady state problem.  400 Hellos are coming every
        10 ms all the time.  In this example the Hello traffic would swamp
        themselves (even if they are at higher priorities) and many hellos
        can be dropped which is widely considered to be undesirable.  In addition
        of course the large steady-state load of hellos would slow down and
        cause to drop the incoming LSAs as well.   The only way to solve this problem 
        is perhaps to use a very fast processor or increase the Hello interval.

        Now two points to make.  Firstly, it is widely regarded that it is 
        undesirable to lose Hellos (since that could declare an adjacency
        down when it is actually up) and so under congestion (either caused
        by Hellos or LSAs) it is still preferable to give priority to Hellos.
        Secondly, by prioritization or any other congestion avoidance technique
        we can only hope to avoid a transient congestion problem (such as a
        sudden rush of change LSAs caused by a large failure event).  If there
        is a steady-state congestion problem such as you point out then no
        prioritization or congestion avoidance technique can solve it unless
        you get rid of the steady-state congestion with faster processor or
        by permanently slowing down the steady-state traffic. 

        Response:  Yes, some natural backoff will happen due to congestion
        itself but it is still desirable to have explicit backoff to avoid
        congestion.  Also, retransmissions usually result from an internally
        triggered timer and at least in some implementations retransmissions
        may be sent out soon after this internal timer triggers even though
        there is a large queue of incoming messages (includes perhaps an Ack
        that could disable this retransmission) that have not been
        processed yet.  In such a situation it is better to
        explicitly increase the retransmission timer to reduce retransmission
        traffic.

            Response:  We have a simple scheme with only two rates of sending
            LSAs to a neighbor, the higher rate during "no congestion" and the 
            lower rate during "congestion".  To avoid thrashing between the
            two rates we use a "high water mark" and a "low water mark".  Your
            suggestion is to further enhance the scheme with multiple rates.
            An implementor can certainly do that.  However, we would prefer to
            specify only the simple scheme (which we have seen to have benefits 
            through simulation studies) and would like to leave it up to the
            implementor to do further enhancements to the simple scheme.  Another
            point to note is that Recommendation 4 slows down all LSAs (both new
            and retransmissions) during congestion whereas Recommendation 3
            progressively slows down the successive retransmissions of the same
            LSA.  We noted this at the end of Recommendation 4.  

        Mitchell Erblich
        Sr Software Engineer

---

From: Vivek Dubey <[email-masked]>
Date: Thu, 22 May 2003 14:33:37 -0000

Mitchell,
Comments inlined...

Looking at a storm of Hello packets may starve other
OSPF packets from being processed. Try
simulating 400 nbrs sending a hello every 10 ms.

vivek>>
>"It might happen. But for sub second hellos (10ms) ,
>Rtr dead interval will be around 40ms.
>Issues involved here will not just be to
>prevent OSPF from causing LSA storm but .....
>CPU , buffer and queue lengths of the processor.
>Morever we need to process these sub-second hellos
>or else NBR will be dead."

vivek>
>"Are you referring RXMT LSUs ?? Since point 1
>processes the acks on higher priority(reducing
>the chances of RXMTs) wont it be overhead. Probably
>simulation will show the effect correctly."

vivek>>
>"But it will not prevent OSPF to contribute to
>LSA storm ???"

regards,
vivek

>                         this remove / significantly remove the

___________________________________________________
Get email that means BUSINESS! me @ mycompany.com.
Just Rs.1499/year.
To start, click http://www.rediffmailpro.com