Subject: Re: ForCES transport requirements

From: Tal Anker <[email-masked]>
Date: Tue, 25 Nov 2003 08:55:13 +0200

Hi,
I aggree that the motivation described for having multicast in this case is a bit weak, but the example is excellent though... In the same example, I'd expect the time it takes to update the FE's would be more then the 0.4 sec that Steven's calculation suggest, as this was an "lower" bound... What I am concerned about in this scenario that during the time it would take the CE to process (prepare send and handle reliability) the 32K messages, the NE is suppose to participate in other duties... (supporting management sessions, participating in control protocol, etc). If we can minimize the amount of processing from 64*500 to someting on the order of 500 (plus MAYBE some retransmissions) then the CE would be more available to its other duties... IMHO, this does make multicast a very nice thing to have here...

- Tal 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Tuesday, November 25, 2003 5:56 AM
To: [email-masked]
Subject: Re: ForCES transport requirements

Actually, based on the responsiveness requirements for IP routing, the time
constraints for this are not very bad at all.
Taking even several seconds to adjust for BGP failure, and black holing
traffic in the mean time.  Is quite acceptable.  Taking even 10 seconds is
probably okay.  The routing system is actually designed to respond slightly
slowly.  (Responding too fast to events produces very interesting problems
of its own.)  For example, when using GigE thorugh a switch (hence not
having physical link down detection) the time to detect a neighbor failure
is itself several 10s of seconds.  Worrying about 1 second of response time
to an event that takes 30 seconds to detect does not seem necessary.

There are contexts where this is not desirable.  In those cases, one takes
a completely different approach.  Because if small number of seconds is too
slow, then one is trying for 50 msec, and one should think about the
problem completely differently.  (For example, one could create backup FIBs
with ones second choices already pre-loaded.  Yes, I know that this is a
limitted solution.  I am not trying to solve the problem, merely to suggest
that if it matters one approaches it differently.)

Yours,
Joel M. Halpern

At 09:49 PM 11/24/2003 -0500, you wrote:
>Here is a contrived, but representative example of the type of problem I
>think that ForCES needs to be able to solve to make it more useful for
>me than a home-grown solution.
>
>Imagine a NE with one (active) CE and 64 FEs, each forwarding global
>routes.  64K external prefixes are currently reachable via peer A.
>Suddenly the peering to A fails, and now half the prefixes are reachable
>via peer B and the other half via peer C.  No matter how cleverly you
>have designed your datastructures, in the general case you are going to
>have to update at least 32K table entries.
>
>Suppose you can pack 64 table updates/ForCES packet (~1500 byte packet
>with ~24 byte entries).  Then the CE will have to send 500 packets/FE *
>64 FEs = 32K packets if ForCES is restricted to unicast transport.  That
>works out to about 400 Mbits, which will take 400 msec to transmit at
>full blast assuming the CE is attached via gigabit Ethernet.  Meanwhile
>the NE might be forwarding several gigabits worth of traffic into a
>black hole.
>
>This solution simply doesn't meet my timeliness requirements.  So I can
>choose to hope that the number of FEs in my NE increases slower than
>Moore's Law, I can choose to try and come up with a proprietary
>mechanism for splitting this update load across several CEs, or I can
>choose to explore whether multicast can be utilized to minimize the
>update latency.
>
>For the moment I have chosen the latter, but I am willing to listen to
>arguments as to why that is the wrong choice.
>
>
>Regards,
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Steven L. Blake               <[email-masked]>
>Ericsson IP Infrastructure                +1 919-472-9913