Subject: Re: Alternate MBONE connectivity request

From: [email-masked] (Kevin C. Almeroth)
Date: Sat, 10 May 1997 17:40:59 -0400 (EDT)

>>I'm looking for an alternate MBONE connection for New York University from
>>a site that has good IPv4 connectivity to our network (128.122.253.68 is a
>>good traceroute destination).  Our current ISP doesn't treat the MBONE as a
>>serious offering, and our tunnel is plagued with 40-50% packet loss and
>>random daily tunnel disconnections from their end, due to an
>>under-engineered and over-committed mrouter infrastructure.

They definitely need it.  During Interop session broadcasts, they were 
constantly at the top of my rtpmon list.  In fact, 40-50 might be a
bit low.

-Kevin Almeroth

---

From: Bill Fenner <[email-masked]>
Date: Mon, 12 May 1997 00:56:19 PDT

>constantly at the top of my rtpmon list.  In fact, 40-50 might be a

Just as a point of interest, I've been picking random "loss leaders"
out of rtpmon on various sessions, and much of the time, most of the
loss appears to be on the last hop (e.g. from the provider to the
customer).  Unless that loss is due to overloaded multicast routers
at the provider, then the customer's tail circuit is probably overloaded,
and getting another tunnel is not likely to help that.

Not to say that's definitely NYU's problem, just that you should make
sure what the evidence points to before you ask for a tunnel from somewhere
else, especially since doing that can cause more problems than it solves
if you become transit.

  Bill

---

From: Jimmy Kyriannis <[email-masked]>
Date: Mon, 12 May 1997 18:15:47 -0400

>else, especially since doing that can cause more problems than it solves

Bill,

Your point is very well taken and justified.  However, there's a long story
behind this problem that I'd rather not get into on an open mailing list.
We can discuss this in further detail offline, if you like, but I'd rather
not provide fuel to turn this discussion into an ISP-bashing thread.

Here's a short summary of what things look like here.

My tunnel endpoint is a Cisco 7000 router, runing IOS 11.1(11), with a FDDI
connection directly into a GIGAswitch FDDI port.  At this time, this 7000
is doing *nothing else* except for holding this tunnel and offering
multicast routing to the only two ethernets it is attached to.  The router
is not performing unicast routing for any subnets, nor any other protocol
routing.  In short, this is our testbed router running idle for a good
portion of its time.

Also directly attached to a GIGAswitch FDDI port is another 7000, which
holds NYU's T3 connection to the Internet via this ISP.  That 7000 has no
other active interfaces on it and typically runs at 20-25% CPU utilization.
The T3 and FDDI interfaces typically run at 5-10% utilization with
absolutely no link errors.  The GIGAswitch's utilization is typically
10-20% of an FDDI, in aggregate through its backplane - again, no
bottlenecks here.

Our border router, in turn, has T3-or-better connectivity to the subnet our
ISP's MBONE router is on.  We typically have no unicast IP packet loss to
the ISP's router that provides connectivity to that subnet, and
occassionally, a small amount of packet loss to the mrouter on that subnet.
The mrouter itself is a Sun system (of unknown type) that ran mrouted with
23 configured tunnels and 15 active ones on it, the last time I was able to
poll (learned via mstat, and that capability has since been taken away from
me and public view).  As an aside, I understand from our ISP that the
mrouter is on a network that holds 4 busy USENET news servers and the MBONE
router, but since I don't know what the network infrastructure there looks
like, I can't say how much worse (if any) this condition has made things.

At the times I've performed mtraces to various audio and video transmitters
and multicast groups, I've seen a consistent 40-50% packet loss.  In
addition, our tunnel falls away multiple times each day, often to the point
that the mrouter is briefly unreachable via ICMP echo requests, though
traceroutes reach its subnet's router.  I strongly believe this is an
indication of a UNIX system being used to shovel more packets through its
kernel and interfaces than it is capable of.

As I stated in my original message, our ISP has formally informed me that
they do not currently consider their MBONE services to be a
production-level service that warrants proper levels of engineering,
performance and reliability.  Rather, it is offered as an "as-is",
"take-it-or-leave-it" service with no guarantees and admitted under
engineering.

This is why I'm looking for a new tunnel; any session I've tried to join
has had absolutely unintelligible audio and terrible video performance.  I
couldn't understand a word spoken in the IETF conferences nor Interop, and
the STS-83 shuttle launch was jittery as hell (though I remember seeing
some packet loss at NASA as well).  In its current state, I cannot offer
this as a service to our users, since it's really unusable.

BTW, I often transmit on the "Places all over the world" session - you can
perform mtraces to that FDDI-attached SPARC (also plugged into the
GIGAswitch), if you like.

Jimmy