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

[Chaoping Wu <[e-mail]>]

Hello Jerry,

Sorry for not providing any further information about this subject
recently, as I've been busy with another IETF draft. Let's focus on the
state of congestion in this mail. I'll send a separate email to you soon on
other topics when I have more time.

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.

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.

So much for now, hope this would help.

Regards,
Chaoping

==================================================================


On Tue, 20 Aug 2002 09:42:00 -0400, Ash, Gerald R (Jerry), ALASO
<[e-mail]> wrote:

>Dear Chaoping,
>
>Thank you very much again for your comments, see responses below.
>
>Regards,
>Jerry Ash
>
>> >> 1. Outbound Congestion Notification
>> >>    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 immediately once detected.
>
>> >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.
>
>> >> 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?
>
>> >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.
>
>> >> 3. Adding A Congestion Prediction Concept
>> >>   What about incorporating a congestion prediction concept into this
>> >>   I-D? Preventive congestion measures should be very used for network
>> >>   administrators to get alerted about when they should start consider
>> >>   optimize their networks. Potential congestion may be simply another
>> >>   congestion state.
>
>> >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.