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

From: "Jeyanath Minto J - CTD, Chennai." <[email-masked]>
Date: Wed, 26 Feb 2003 10:43:43 +0530

hi Rohit,
      have a look on this draft.
        http://www.ietf.org/internet-drafts/draft-kompella-rag-plp-00.txt

Cheers
Minto

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Wednesday, February 26, 2003 7:50 AM
To: [email-masked]
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

Rohit,

        I am extremely familair with the tradeoffs.

        Simply said, I would like to remove even
        a few seconds loss of convergence dealing
        with 1Gb or faster links, if I am able to
        minimize the negative consequences.

        On systems with 5 or 6 '9s reliability
        requirements, even a 1 second hello and
        a 3 sec dead rtr interval doesn't cut it..

        The only way I can understand to really
        do this is to create a new sub-sec heartbeat
        packet type while keeping the standard
        hello packet. This newer packet could be
        effectively empty to minimze size and
        processing requirements.

        Legacy systems could just ignore this
        newer packet type.

        Then the systems that support this packet
        type could set an internal bit and track
        that they are repeatedly seen and use
        this as a true heart-beat.

        Mitchell Erblich
        Sr. Software Engineer

Rohit Gupta wrote:
>
> Erblichs,
> The reason that the existing timers have been kept in
> O(secs) is to avoid any instability which may be
> introduced due to transient perturbations inside the
> network. If you go and change these timers rightaway
> then obviously there will be a lot of problems
> introduced. How we can deal with them is an issue by
> itself though!
>
> BTW has there been any work done on changing these
> timers to milli-secs and studying OSPF's behaviour?
>
> I guess its time the OSPF WG charter did something
> about it !!!
>
> Rohit
> --- Erblichs <[email-masked]> wrote:
> > Hey guys,
> >
> >         I got a request for subsecond timer support
> > in OSPFv2 and V3, that
> >         hopefully follows the reasoning that was
> > suggested in the ISIS
> >         subsecond timer draft.
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/

---

From: Erblichs <[email-masked]>
Date: Thu, 27 Feb 2003 01:35:13 -0800

Group,

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

        And excuse me if I take them out of order:

        1) No Cisco proprietary routing protocols are mentioned in
           2.2.1 and thus have no bit positions assigned to them.

        2) If the sequence number is monotonically increasing, then why
           isn't the skippage of a value a secondary  use (sect, 2.2.1)
           to determine that either congestion or something is occuring?

        3) If a skipped value is somehow removing a protocol from being
           monitored, then we have lost that knowledge forever and it
           in effect will not be removed. Thus, in my opinion certain messages
           should be acked to verify that that they have been recieved. OR that
           if only two systems are undergoing a conversation, shouldn't they in
           turn be increasing this sequence number, which implies that the
           earlier one was seen. If the value isn't acked via one of the
earlier
           two methods, then it could be resent.

        4) Due to the fact that only monitoring is enabled or disabled (turn
off
           and turned on), wouldn't it make sense to be able to be able to
report
           a level of degraded status with a particular protocol? Also, if
           the above converstaion is done, timestamps could also be used to
           determine rtt (round trip times).

        5) bottom of 2.1.. "prepared to deal with fragmentation and
reassembly".
           Assuming that this occurs, wouldn't it make sense that out-of-order
           situation to occur that could delay IP from sending up a complete
           packet until the microsecond timeframe has expired? Assuming H == D.

        6) 2.2.1 : specified in microseconds.
           Wouldn't a third use of sending seccesive packets with say a 1 us
time
           frame with a specified size result in being able to test a links
bandwidth
           capacity, plus buffering capacity to determine the likelyhood of a
dropped
           packet in the future. This could be done on links before the routing
           protocols are actually brought up. Is this valid without specifying
even
           ONE protocol and without a UP or DOWN notfification?

        7) 3.2 3. PlPm then sets a timer T to expire in H microseconds ..
           Interesting... If the timer goes off and this packet is sent on a
           half-duplex Ethernet and a collsion occurs, wouldn't a jamm, then
           a backoff algorthm defer the transmit of the packet possibly beyond
           the time frame and thus the intended reciver(s) identify one or more
           protocols as falsely being down? This is assuming that hello
interval
           is approximately equal to dead interval. "caveat within the 3.2
           section where "H should be at most D". What is the timeframe for
           the 1st backoff on say a 1Gb eth link?

        7b) Which brings up a point that nowhere will the reciever be notified
            what the hello interval is being set at. Maybe I am just going
            blind. If the sender specifies a hello interval, then the reciever
            could time seccessive hello packets for jitter, etc..

        8) Isn't the amount of possible parsing overhead of this packet larger
           than intended with a possibly large size? If we push this to the
extreme
           with a 9k jumbo Ethernet frame, sent every microsecond, then the
amount
           of overhead bandwidth consumption becomes excessive. However, if
this
           packet were kept to a fixed size of say 64ytes, and the "Message" +
"Extensions"
           field were simplified to remove their unknown parsing overhead, then
           I could expect that a multiple protocol subsecond timer could be
effective.

        9) Just because you specify a "hello type interval", why wouldn't you
want to set
           the timer in "3.2 3. sets a timer T to expire in", to 1/2 or 1/3 of
the "dead"
           interval. Why not send a hello every 10 us with a dead interval of
say 100ms?
           Shouldn't the added knowledge that a link is undergoing some form or
problem
           be beneficial as long as their is a secondary route?

        10) Why would't you allow to have the hello interval negotiated? If a
sender
            was sending the above 9k every 1us on a 100Mb eth link, as a
reciver, I think
            I would want to be able to tell the sender to stop or don't even do
it in the first
            place.

        10b) What happens if say A the sender and B the reciever differ in
their use of
             H and D? Could 1-way adj be formed on one side while the other
side sees
             is as a 2-way until a full nbr listing in the regular hello packet
shows
             up (OSPF)?

        I think that this is probably more than enough of feedback. Hopefully,
it is taken
        and each item thought over and maybe some of these items can evolve the
draft.

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