[28592] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Optical Crossconnects and IP

daemon@ATHENA.MIT.EDU (Craig Partridge)
Tue May 9 11:15:53 2000

Message-Id: <200005091513.LAA98936@aland.bbn.com>
To: Tony Mumm <tonym@netins.net>
Cc: nanog@merit.edu
In-reply-to: Your message of "Tue, 09 May 2000 09:44:31 CDT."
             <200005091444.JAA03955@worf.netins.net> 
Date: Tue, 09 May 2000 11:13:21 -0400
From: Craig Partridge <craig@aland.bbn.com>
Errors-To: owner-nanog-outgoing@merit.edu



In message <200005091444.JAA03955@worf.netins.net>, Tony Mumm writes:

>However, more end to end knowledge is required in a converged
>network.   I am for one looking to ease the load of general
>traffic engineering.   In the giant carrier backbone, it
>may be better to use your resources wisely, than to overbuild
>your network.   
>
>I hear a phrase quite often "Everything is going to IP".  Well,
>before my phone call is on IP, I want some guarantee that its
>getting from point A to point Z at the rate I'm paying for.

Tony:

I hope you won't get upset if I use your short comment here to get
on a high horse and rant for a moment.

Over the past several years, I've heard several people say we need
to embed more end-to-end knowledge into the network, as a solution
to quality of service, or reliability, or some other valuable function.
What I have not heard yet is:

    1. A cost-benefit tradeoff.  Embedding end-to-end cognizant information
    into the network has a cost, often in reduced flexibility (e.g., look at
    how hard it is to add new applications to the telephone network vs. the
    IP network).

    2. A reasoned technical justification that shows that we can't provide
    the same service with the current service model (which I define roughly
    as "route based on the contents of the IP header") and that we need
    to break or bend the current model to do new things.

Let me give a concrete example.  It is fairly clear that one of the
advantages of packet switching is that it allows us to build fairly
reliable networks out of much less reliable parts.  (Viz: the Internet
is getting closer and closer to the reliability of the telephone network,
yet no one claims that a Cisco router is as reliable as a #5ESS).
Yet, oddly enough, we don't know exactly how reliable each component in
an IP network has to be to achieve a given level of reliability (esp. in
the face of multiple possible transit paths).

If we knew this information we could more rationally budget our resources
to build our networks.  We could also potentially design IP networks that
are *more* reliable than the telephone network, and run telephony and other
more demanded services over them.

But we haven't asked these kinds of questions... so how can we be confident
that putting end2end solutions in the network is the right solution???

Craig


home help back first fref pref prev next nref lref last post