tom
-------
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by emigrant.cs.washington.edu (8.8.8+CS/7.2ws+) with ESMTP id SAA03886 for <tom@emigrant.cs.washington.edu>; Mon, 12 Oct 1998 18:57:17 -0700 (PDT)
Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id SAA04160 for <tom@cs.washington.edu>; Mon, 12 Oct 1998 18:57:15 -0700
Received: from maia.east.isi.edu by east.isi.edu (8.8.5/5.61+local-24)
id <VAA22054>; Mon, 12 Oct 1998 21:57:14 -0400 (EDT)
Message-Id: <199810130157.VAA22054@east.isi.edu>
To: tom@cs.washington.edu (Tom Anderson)
Reply-To: mankin@EAST.ISI.EDU
Subject: Very Long Re: Comments and talking together about the Access proposal?
In-reply-to: Your message of Thu, 08 Oct 1998 10:43:44 -0700.
<199810081743.KAA31021@emigrant.cs.washington.edu>
Date: Mon, 12 Oct 1998 22:01:58 EDT
From: Allison Mankin <mankin@ISI.EDU>
Status: RO
Tom,
Sorry for the delay in answering, but you're right, the questions
are not so quick to answer, though good ones.
>
> A couple quick questions. A while back I had surfed the CAIRN web
> pages, and had jumped to a perhaps mistaken conclusion about its model of
> use from the web page that implied researchers could reserve CAIRN
> for their own experiments, eg., for an entire day. To me that implied
> that other researchers were locked out for that period.
A researcher uses the CAIRN Web calendar to announce experiments,
at whatever level of protocol level, for two reasons: because the
experiments may affect other researchers, or because they may be
interesting to other researchers. The calendar is a reservation
in the sense that an announced experiment has some precedence -
the CAIRN TOC (Testbed Operations Center) will not do routine
maintenance during it, other experimenters should avoid risky
operations during it. But it's that loose.
When a researcher puts something on the Web calendar, there
is automatic mail to me and Terry Gibbons (we're the two leads for
CAIRN). We do the email announcement out to the researchers.
We enforce using the calendar only for notifying about experiments that
involve PC router reboots on the main backbone. (The CAIRN TOC
monitors the routers continuously, by the way, so it is evident when
sites are doing unannounced disruptive things).
It's possible to ask for a lock-out on CAIRN, but we have never
received such a request for all of CAIRN, but rather only twice
for single links. I recall only one lockout during Dartnet over
seven years, and that was before Dartnet was transitting multicast
traffic. For the two CAIRN link lockouts, we talked with the
experimenters and made sure it was needed (sometimes a new VC
is what you need, sometimes an added pair of PCs) and that it was for
the minimum time. CAIRN TOC enforced an end time on those two
occasions.
Going back to Dartnet, from 1991-1996, the reality was that it
was up carrying an important MBONE segment. CAIRN is similar
in its relation to both the 6BONE and an upcoming interdomain
multicast replacement for the MBONE.
A better motto than "a network we can break" might be
"a network we can touch all we like".
> Is that
> just the PC router portion of CAIRN that gets reserved? Or is
> that also the model of use for the higher level protocol CAIRN?
>
As I said, it's loose what level of experiment is on the calendar.
But the most other researchers are affected by changes in the
network, so those are the ones most important to manage and announce.
> To me, an important issue is how long experiments can run for;
> some things need to run continuously, to be useful and validated.
> Assuming that CAIRN supports long term experiments, what's the scope/size
> of experiments that can be run -- how many sites/machines are available,
> and how many simultaneous large scale experiments are you now supporting
> (e.g., are you resource constrained)?
>
CAIRN encourages the long experiments, because that's one of the things you
can't do well in a detailed simulator. So, for instance, Bill Fenner
has used CAIRN continuously to look for anomalous states of multicast
routing. He developed tools on CAIRN that can wait and trap the anomalies.
Scope/size of experiments that can be run:
all the routers - 33 today
all the hosts - we don't have a good count, but a couple
for each of the sites (29), plus 10 here
at ISI, so on the order of 100.
How many experiments at once:
Many not on calendar, but I count continuous experiments on DNSSEC,
IPsec, multicast routing, secure session, high resolution and FEC
audio, Network Time, IPv6 uni- and multicast routing, Java RSVP, and
wireless CAIRN sites, going on as I write. They range in site use
from a few (DNSSEC is only a few servers so far) to all (Network Time).
The conferencing experiments involve some fifteen or twenty users at
the peak times, distributed on twelve sites.
Some current experiments that run more intermittently are multi-layer
multicast video (McCanne), GLOBUS, and congestion-controlled reliable mcast.
I think they are intermittent because of the researchers' cycles more
than anything else.
Resource-constrained?:
Not by the network, with the exception of one experiment whose scope
is still limited, a high-bandwidth video and scoping protocol for it.
The PC routers can't handle unlimited multicast of this, and we have
T1 links we must avoid with it. It's a great experiment, but going
slowly.
Our constraint is always cycles of CAIRN TOC for handling problems
that arise - links fail, sites have broken fibers, PC disks break,
I'm sure you know. It's also been a lot of work for the TOC to get
the basic CAIRN network services really strong, to include good
multicast, SNMP, IPsec, and IPv6.
> Also, do you have routing flexibility for the higher level protocol CAIRN?
> One thing that is clear is that some experiments want to use a dedicated
> network, and some need to use plain old Internet.
>
We have some routing flexibility. Operationally, all the CAIRN sites
have a Plain-Old-Internet-reachable interface on at least one CAIRN
PC or they have a CAIRN interface on at least one Internet-
reachable machine. We prefer the first setup, which is also what
you want for the routing flexibility to be best. The second case
is a leftover from DARTnet's arrangements, and is characteristic of
the sites with firewalls, not the university sites.
Routing flexibility has been a research goal too: for instance,
we are partway to a network management capability that uses IPsec tunnels
to protect SNMP traffic IFF the next hop is outside of CAIRN.
> One last thing: the MBONE continued to grow in popularity after it moved
> beyond Dartnet. What is your model for how CAIRN fits into the technology
> development/tech transfer life cycle?
>
Dartnet launched MBONE after we used it for a year or so internally.
I was the person who pushed for us to start IETF broadcasts. The same
philosophy goes for CAIRN, to use it to allow new interesting Internet
work to incubate for just long enough for it to be very strong when
it goes public or goes to beta, in some cases. Another technology transfer
point is that we have quite a few IETF WG chairs and i-d authors on
CAIRN. [Chairs: mmusic, avt, malloc, idmr, ipng, lsam. Authoring only:
dnssec, ipsec, cat. These lists are incomplete because I just started
assembling them recently.]
> Ok, maybe not so quick.
>
That's OK.
Onward and upward,
Allison
> -----
> So, about CAIRN, the proposal says that because it is "a network we
> can break", it doesn't lend itself to the range of research topics you
> describe (a wonderful range of topics). Actually, about 90% of the
> use of CAIRN lately has been for research on multimedia conferencing,
> application multicast security, and secure DNS. This research gets
> developed on a net that stays up. We do have an alternative backbone
> path (separate ATM vcs and pc routers) but it is hardly used. As you
> observed in your proposal, there is extremely interesting research at
> the transport and above. In fact, CAIRN has found that, and had done
> so even before it was CAIRN (the MBONE started on Dartnet).