Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

From: Kireeti Kompella <[email-masked]>
Date: Mon, 3 Mar 2003 18:17:43 -0800

Hi Mitchell,

On Thu, 27 Feb 2003, Erblichs wrote:

>       I think I missed why certain items are obmitted from this draft which
>       is very interesting... Just a few items :)

This draft will be superceded by a new draft with similar goals
but quite a different implementation.  Unfortunately, we missed
the ID cutoff, but the essence remains -- fast (sub-second) hellos,
L2 independent, in principle L3 independent, and (the big change)
routing protocol independent.

We'll submit it after the IETF.

Kireeti.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 3 Mar 2003 23:44:22 -0800

Kireeti,

  Could you possibly put it on the web somewhere?
  It would be interesting to look at it.
  Thanks.

--
Alex

---

From: Erblichs <[email-masked]>
Date: Sun, 9 Mar 2003 15:03:01 -0800

Kiretti Kompella,

        Of all the items that I mentioned, I think one of the main
        items deals with a sub-second (microsec to millisec)
        interval values.

        A negotation like interval determination would probably
        be number one for me. Assuming that you would not find
        it beneficial for different intervals being set, I would
        think that if a router were recieving the said packet on
        a microsec timeframe and while under congestion or such,
        it should be able to inform the sender to bump up the
        interval to the highest value. Almost ala "BGP neighbor
        negotiation hold timer" but I am suggesting to a higher
        value.

        If after the "congestion event" has passed, the router
        sending the higher interval value, could adjust downwards
        to meet the first router's value, thus re-achieving the
        microsec earlier interval.

Mitchell Erblich
Sr. Network Software Engineer
=======================================

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Mar 2003 10:10:16 -0800

Hi Alex,

>   It would be interesting to look at it.

We only just finished polishing it up :-)

We'll submit it as soon as the IETF is over, but I will suggest
to the main authors to post it somewhere ...

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 12 Mar 2003 10:41:20 -0800

Hi,

>         items deals with a sub-second (microsec to millisec)

You're scaring me with "microsec"!

>         be number one for me.

The new draft is moving in this direction.  Each sender says how
fast it can send and receive; other senders adjust to this.

Kireeti.

---

From: Erblichs <[email-masked]>
Date: Wed, 12 Mar 2003 14:16:45 -0800

Kiretti,

        The protocol liveness doc states in section 2.2.1 the
        dead interval "is specified in microsecs".

        "Each sender says how fast it can send and receive".
        ohmmmm..

        My 2nd item was "Why not have a "interval and a multipler"
        fields. The interval and the multiplier values should
        both be negotiated. An invalid packet should be a combination
        that when the two values combined are greater than 1 sec.

        The interval would give you a time consistency of sending,
        seccessive packets, the sequence number would inform if one
        or more packets is droped or not sent, and the multiplier
        times the interval would generate your new event of "maybe
        dead".

        This is versus your doc that states if you don't hear from me
        in interval time frame then consider me dead. Your interval
        maybe 1 ms, but you may be sending packets per us, and I
        can't stop you. Thus, I think you need the three values.

        I haven't yet really discussed different xmit and rcv'd
        negotiations if this is what you meant as "send and recieve".

        Also 1-to-1 negotiations or a group consensus negotiation
        could be considered...

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