Subject: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1

From: Erblichs <[email-masked]>
Date: Wed, 2 Apr 2003 15:28:10 -0800

Group,

        Lets keep it simple..

        A) 2) The Proposal

        (1b) Separate the hello packets into its own FIFO queue
             for later processing. Periodicly process hellos
             based on the hello interval and the number of
             nbrs on the interface.

             Upon recieving the event that informs that a adj may
             be down due to hellos, mark the number of hellos
             currently in the queue.

             Process all the hellos up to the mark and identify
             whether the event is cleared. If not, do normal
             processing that takes down the nbr, adj.

             This way hellos can be processed as "lower priority".

        (1c) Packet Pacing
             Due to the fact that packet congestion on a interface is
             based on packet spacing with interpacket gaps (ala Ethernet),
             dynamicly adjust the rate of outgoing packets based on
             multicast or unicast destination, the number of nbrs/adjs
             on the interface, and the bandwidth of the interface.

             The algorithm that determines spacing should have a defined
             rampup speed, and have a exponential slowdown if congestion
             is determined (tcp Van Jacobson's algorithm is a good start)

        (1c) Router capability and Congestion determination should
             be based on past round-trip
             times of known events with the nbr; ie, Initial Database
             Synchronization packets.

        These are just 3 of dozens of items that can be used to
        determine and adjust for increased load/scalability.

        Done.. :)

        Mitchell Erblich
        Sr Software Engineer

---

From: Acee Lindem <[email-masked]>
Date: Wed, 2 Apr 2003 19:08:04 -0500

Mitchell,

This draft has been in progress for some time. There is some
concensus that many of the techniques are the right things to
do to improve scalability (though possibly not all of them).
Much of what you're proposing below is either new or dictates
a specific implementation of the techniques in the draft.
I don't think we want to add any of this to the BCP at
this time.

Thanks,
Acee

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 2 Apr 2003 16:32:22 -0800

Acee Lindem,

        That is interesting due to the fact that some
        of the items I am suggesting also have FCS
        related implimentations.

        Mitchell Erblich
        Sr Software Engineer
        ========================

---

From: Erblichs <[email-masked]>
Date: Thu, 3 Apr 2003 11:26:03 -0800

Acee,

        What I am proposing is not really new...
        Some large companies even document what
        they do with OSPF outside of the RFC process.

        Second, if it has been in progress over
        so much time, why doesn't the group just
        make it a RFC and eliminate it as a draft!

        I will just re-cover (1a). I will assume that
        over 99.99% of the time, whatever people do is
        acceptable with handing the hello packets.

        Tbe draft specifies high priority hello packets
        and to do that already requires a separate queue
        for the hello packets. My exception basely
        generates a priority boost for the hellos and
        process them!

        I suggest routers to process these two queues
        in a weighted round-robin fashion based on
        my earlier criteria without prioritization.

        Mitchell Erblich
        Sr. Software Engineers
        ------------------

---

From: Acee Lindem <[email-masked]>
Date: Thu, 3 Apr 2003 14:37:07 -0500

Mitchell,

In your original E-mail, I took more of an issue with your 1c)
comments. I don't believe using TCP like congestion and backoff
mechanisms to adjust OSPF flooding and retransmissions rates is
the right thing to do. IMHO, it makes no sense to measure rtt over
a single link.

As for your packets queuing comments 1b), I don't believe that
the specific queuing implementation should be specified.

Thanks,
Acee

P.S. How do your comments 1b) and 1c) map to the proposals
in section 2 of the draft? In the future can you use the
same numbering as the draft you are commenting on?

--
Acee