Subject: Re: Congestion Avoidance & Control for OSPF Networks <draft-ash-manral-ospf-congestion-control-00.txt>

From: Chaoping Wu <[email-masked]>
Date: Sat, 3 Aug 2002 19:00:03 -0400

Hi all,

I'm not sure of the status of this I-D after the recent IETF meeting.
Hopefully it is stil on track. I do have some specific and general comments
that I'd like to share with you and have some discussions if not done
before.

General Comments
================
1. Outbound Congestion Notificatoin
   This I-D suggests this notification not required in some way
   (section 4.2.1). But I think this notification is important and may
   complement the whole mechanism in the following way:
   A. Identifying source of congestion.
         In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF
         packets may go through some kind of transit networks which may
         be congested for some reason. In this scenario, the receiving
         OSPF router can tell if the originating router experiences
         congestion or not.

   B. Faster notification is possible if outbound congestion notification
      is performed. It should be sent immediatly once detected.

2. State of Congestion
   This I-D specifies 3 states MUST be defined (section 4.2.1) but it
   has not specified a consistent way of defining the states.

   In networks mixed with different vendor routers, if a "high congestion
   state" in one router is equivalent to "low congestion state" of its
   neighboring router that is made by a different vendor using different
   definitions of congestion state, the resulted congestion measures in
   this network may not be as desired, isn't it?

3. Adding A Congestion Prediction Concept
   What about incorparating a congestion prediction concept into this
   I-D? Preventive congestion measures should be very used for netwrok
   administrators to get alerted about when they should start consider
   optimize their networks. Potential congestion may be simply another
   congestion state.

All comments on the above are appreciated. I may post some specific
comments about the I-D when I have more time.

Regards,
Chaoping Wu

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Sun, 4 Aug 2002 19:53:38 -0400

Dear Chaoping Wu,

Thank you very much for your comments, please see responses below.

Regards,
Jerry Ash

> Hopefully it is still on track. I do have some specific and general comments

The draft wasn't discussed at Yokohama, however, we hope to advance the draft on the list, and discuss it further at IETF-55 in Atlanta.
 
> General Comments
> ================
> 1. Outbound Congestion Notification
>       is performed. It should be sent immediately once detected.

I agree with your observations, the draft does call for immediate notification of congestion, once detected.
 
>    this network may not be as desired, isn't it?

You point is well taken, and some consistency in the definition of congestion state is needed, further work on this is warranted.
 
>    What about incorporating a congestion prediction concept into this
>    I-D? Preventive congestion measures should be very used for network

Sounds like a good capability, if feasible, but how does one do (reliable) congestion prediction?

Thanks again for your comments.

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Tue, 20 Aug 2002 09:42:00 -0400

Dear Chaoping,

Thank you very much again for your comments, see responses below.

Regards,
Jerry Ash

> >Though what you say is true, if I have understood you correctly, we have
> >tried to avoid signaling both for our own congestion as well as congestion
> >at the other end(which is also harder to predict). We have gone with the
> >assumption that if the congestion occurs at the other end, then the
> >congested router will notify about it. This fact has been put forward in
> >Section 4.2.1, maybe we can clarify that further.

> This particular comment was about outband congestion at a local router
> only, rather than any congestion at a remote side as you implied in the
> reply (I agree with you that remote end congestion is harder to predict,
> but this is not the point I was trying to make above).
> 
> The question is what should the local OSPF router do if it detects
> outband congestion?
> 
> In section 4.2.1, the ID says
> "Detecting outbound congestion in some way
> does not require notification, since we should assume the adjacent
> router will detect this congestion on its own."
> 
> While this is true, but it loses the some benefits, such as the points
> in 1.A & 1.B as I mentioned above. So, instead, I think we should
> promote the usage of explicit outband congestion notification in
> this ID.

I agree that we should only be dealing with detecting 'outbound' congestion at a router, and not trying to detect congestion at some neighbor router.  I think the quote above from Section 4.2.1 is misleading, and needs to be clarified in the next revision to say something like:
"Detecting outbound congestion requires immediate notification to all neighboring routers".

> Also another related note is the triggering time of Hello messages
> that contain LLS congestion signaling. It was not clear from the ID if
> this signaling should be sent immediately once congestion is detected,
> or wait until the traditional Hello timer expire. Although this may be
> somewhat implementation dependent, but I think we should probably
> promote the better way: immediate notification.

Agreed, and it should be made explicit in the next revision.

> >Though what you say would be desired, however, there can be no perfect way
> >to exactly classify it, on different routers/vendors/etc. We have however
> >given some suggestions in the beginning of the section, we can try to make
> >the classifications more precise.

> Agreed on "no perfect way to exactly classify it". But if we have a
> desire to explore ideas to make it better, we may find other ways.
> More on this point in the near future.

I think you raised a good point, that is, to be more precise in defining congestion state.  I think it would be important for interoperability, and that we should go further in defining congestion states in the next revision.  Your further suggestions would be appreciated.

> >As the actual signaling of congestion and measure of levels of congestion
> >has been left to the implementation, an implementation could always signal
> >low congestion, when it can predict it is going into congestion. The exact
> >prediction methods are left to the local router itself, and as Jerry pointed
> >out it may be hard to predict it.

> This ID does provide a good mechanism on congestion prevention.
> But if you go one step further to introduce the concept of congestion
> prevention in the ID, I believe it would open another
> door of useful capabilities.
> 
> Congestion prediction has been implemented in networking equipment.
> It may be easier than you think. If there's enough interest, I'll
> make some suggestions later.

Is there any reference to where 'congestion prediction has been implemented in networking equipment'?  Again, your further suggestions are appreciated.

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Fri, 23 Aug 2002 15:40:18 -0400

Hi Chaoping,
 
> If we take a deep look at the congestion state in the draft, we can find
> that it is consisted of two parts actually:
> 1. Entering (or detection of) congestion state
> 2. severity of the congestion
> 
> The draft does state several possible ways to detect congestion, which is
> related to part 1. But it is just a little short in standardizing the
> detection methods. The draft also states low/high congestion states, which
> is related to part 2. But the draft does not provide any specification on
> what conditions make a low or high congestion. Interoperability would be a
> concern here.

Agreed.

> I'd like to propose the following suggestions to improve the above two
> parts for better interoperability and I believe they are not difficult to
> implement.
> 1. Congestion Detection
> Assign standard values to congestion detection methods and signaling the
> value in the choke LSA/LLS signaling mentioned in the draft.
> For Example, the detection value could be
>  1= method based percentage of consumed, internal work queues exceeding a
> thresh-hold percentage
>  2= Missing some percentage of hellos;
>  3= Frequent retransmissions are required.
>  15= other method
> 
> This is analogous to some other protocols that signals some algorithms
> selected for current use and provides a cause code when certain events
> occur.
> 
> 2. Severity of Congestion
> Measure severity of congestion with time, since all equipment has timers
> implemented inside. Something similar to chronic or acute congestion.
> Prolonged congestion requires serious measures to overcome.
> For example,
> Prolonged congestion = high state
> Short congestion = low state
> The time-based congestion severity measurement can be used along with the
> internal congestion interval timer that is stated in the draft. With some
> modification, they should complement each other pretty well.

Your ideas are very good here.  Both the degree and duration of congestion should be considered in defining congestion state.  We'll plan to incorporate along these lines in the next rev. of the draft.

Thanks,
Regards,
Jerry