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

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 5 Aug 2002 00:51:18 -0400

Hi Chaoping,

I would like to add to what Jerry has already said.

> 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.
Though what you say is true, if I have understood you correctly, we have
tried to avoid signalling 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 abt it. This fact has been put forward in
Section 4.2.1, maybe we can clarify that further.

> 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.

> 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.
As the actual signalling 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.

What we have tried to define is a method by which a local router can signal
congestion(levels of them), and how the neighboring router SHOULD react on
getting such a congestion notification. Besides that we have put in minimal
changes required for any implementation to support such a functionality.

Thanks,
Vishwas

---

From: Chaoping Wu <[email-masked]>
Date: Wed, 7 Aug 2002 14:08:05 -0400

Hi Vishwas & Jerry,

Thanks for your replies. Please see my comments inside.

Chaoping

>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 benifits, 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.

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.

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

>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 othe ways.
More on this point in the near future.
=======================================================================
>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.

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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 8 Aug 2002 08:40:18 -0400

Reforwarding.

-Vishwas

-----Original Message-----
From: Manral, Vishwas
Sent: Thursday, August 08, 2002 10:17 AM
To: 'Mailing List'
Subject: RE: Congestion Avoidance & Control for OSPF Networks
<draft-ash-m anral-ospf-congestion-control-00.txt>

Hi Chaoping,

Jerry may reply in greater detail later, ;-) however my replies.

> promote the better way: immediate notification.
We have not put the fact explicitly in the draft, and the idea behind it(as
you rightly observed) was that we left it to the implementor. Yes we can
explicitly state the fact(the quicker the notification the better), however
I think the fact would be obvious to anyone reading the draft anyway.

The general idea we got when we floated the prepublished version of the
draft was that we should try and leave as much mileage to the implementor,
while also achieving our objectives.

> More on this point in the near future.
Sure we are open to ideas. If you can tell us any way we could actually
clasify such a congestion on all routers that would be fantastic !!

> door of useful capabilities.
There is nothing in the draft that prevents us from doing "congestion
prevention" ;-) as I said before. If we have congestion prediction
capabilities we can as well signal congestion even before we fall into that
state of congestion.

> make some suggestions later.
Sure we would be very happy to hear back from you on this.

Thanks,
Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 8 Aug 2002 00:46:36 -0400

Hi Chaoping,

Thanks,
Vishwas