Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1

From: "Choudhury, Gagan L, ALABS" <[email-masked]>
Date: Thu, 3 Apr 2003 10:12:10 -0600

Hi Mike and Acee,
  Let me make one more point beyond what Vishwas said.  Perhaps a point
made by Mike and Acee is that prioritizing Hello is a good thing to do
(ensures that an adjacency does not go down due to
congestion) but if we already do it then why do we also need resetting
inactivity timer on receiving any packet?  Note that in Section 2 
we say that "either all, or a subset of the proposals may be implemented
by a router".  So you do not have to reset inactivity timer on receiving
any packet if you are already prioritizing Hello.  Also, please keep
in mind that there may be
situations where specially identifying Hello and prioritizing it
(at the receiver) may not
be easy but it may be easier to reset inactivity timers on receiving
any packet. 

        Gagan 

-----Original Message-----
From: Manral, Vishwas [mailto:[email-masked]]
Sent: Thursday, April 03, 2003 10:50 AM
To: [email-masked]
Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF
Pack ets and Congestion Avoidance #1

Hi Mike,

Let me try to answer your question. I do not think the two suggestions are
exclusive.

We give priority to hellos and yet we reset the inactivity timer whenever we
get a packet from a neighbor including hellos(I dont know how they are
mutually exclusive). We do not stop sending hellos if we have sent a packet
in that hello interval already.

The point is that hello not only conveys the neighbor reachabiltiy
information but also fields like DR/BDR etc which can be of use(unlike in
BGP keepalives I guess).

Let me know if you agree?

Thanks,
Vishwas

-----Original Message-----
From: Mike Fox [mailto:[email-masked]]
Sent: Thursday, April 03, 2003 8:02 PM
To: [email-masked]
Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF
Packets and Congestion Avoidance #1

I know I am coming a little late to this conversation, having only recently
joined the mailing list.  But I did want to mention that we have had good
success with increasing the priority of hello packets.

I do think that two of the suggestions may be mutually exclusive:
increasing priority of hello packets and resetting inactivity timer on any
packet from a neighbor.  If hello packets are higher priority and the
neighbor actually did go down, do you really want to delay learning about
the neighbor outage while you work through a backlog of lower-priority
packets from that neighbor?

Mike

---

From: Dave Katz <[email-masked]>
Date: Thu, 3 Apr 2003 09:39:53 -0800

I think you're dancing around the bigger issue, which is that
optimizations are highly dependent on the implementation in which they
are applied (stop me if you've heard me rant on this before.)

Some of the optimizations will be more helpful than others in some
implementations.  Trying to prioritize them or otherwise be too
specific is akin to calculating angel density on pinheads.

--Dave

   Hi Mike and Acee,

           Gagan

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 3 Apr 2003 21:42:50 +0200

>specific is akin to calculating angel density on pinheads.
the issue was as far I remember Thomas of Acquine, the _number_ of
angels on a
pinhead which is a far more practical problem.

> Also, please keep
doing that (resetting timer on every packet instead of what the spec says)
may lead to very subtle interoperability problems
(and had in the past, a.k.a routers 'forgetting' to send hellos for one
or another
reason) and you may want to point that out. I don't disagree though that
it's
a good thing.

    --- tony

---

From: Dave Katz <[email-masked]>
Date: Thu, 3 Apr 2003 11:46:52 -0800

Perhaps, but the density is really the architectural constant, given
varying sizes of pinheads.  (Insert tasteless microcephalic joke here.)