Re: thoughts

Per Gregers Bilse (bilse@EU.net)
Sat, 22 Oct 1994 23:57:57 -0400


On Oct 22, 16:23, Tim_Dorcey@cornell.edu wrote:
> experiment that CU-SeeMe might be as polite as TCP. CU-SeeMe is surely
> going to use more of the bandwidth than an ftp (experiments could tell us
> by how much). I also regret suggesting that there might be a simple
> technological solution just around the corner. It is true that the
> situation will be improved tremendously when reflectors have the ability to
> send different rate video to different recipients, but that won't get us to
> the point where you can fire up CU-SeeMe on any network without concern for
> the resources it may consume. And, to put those resources into
> perspective, if you are transmitting video at the default rate of 80 kbps

IOW, half a dozen default streams on a moderately loaded T1 will kill
all TCP traffic on it -- TCP will (gracefully) give way. If you have
a TCP-filled pipe, T1 or bigger, one, just one, CU-SeeMe stream will
do serious damage. TCP will detect "network congestion" and
immediately back off.

> >Like anybody else doing what we do, we have a bag of network test
> >tools. Some of these are clearly labeled "Dangerous", like eg wping
> >from Matt Mathis:
> >
> >"
> >Due to windowed ping's potential danger to the Internet, we are taking
> >measures to limit its distribution. At this time we are only releasing the
> >code to people who support some aspect of the global Internet, including
> >network researchers, router vendors, and network service providers. We are
> >not releasing windowed ping to people who have no use for it except to harass
> >their network providers.
> >"
>
> If someone is interested in harassing their network provider, there is
> nothing difficult in writing an application that will transmit UDP packets
> at a far higher rate than CU-SeeMe.

Oh yes, but that's not the point. The fact that CU-SeeMe traffic has
a legitimate purpose, is completely bona-fide, and isn't _intended_
to do harm (ironically, the opposite) doesn't make it less harmful.

And note that if somebody deliberately went and blasted some other
site, their service contract would be cancelled (IOW, they would be
disconnected) if they were a commercial customer. If they did it
from a university student type account, the account would be
withdrawn. If they did it from a remote site, CERT and other service
providers would get involved.

> I don't believe Internet usage can be
> effectively regulated by limiting the distribution of software or of the
> knowlege to create it.

Neither do I, and I wish CU-SeeMe success; I do not particularly want
to see it restricted -- I want to see it work. Properly.

> It is our objective to make it easy for CU-SeeMe
> users to be responsible bandwidth consumers, but ultimate responsibility
> must lie with the user. There will soon be a number of improvements along

Seriously, you _cannot_ rely on that. A lot of careful thought went
into the design of TCP, so that it would be well-behaved at all
times. And that was even in the days when everybody on whatever net
knew just about everything there was to know about it. One could
have made something much simpler and fitted a "rate control" to eg
ftp. But one didn't.

Every day on this list I see questions which for all intents and
purposes go "Umm, I've installed CU-SeeMe. Which buttons do I push?
Are there any movies anywhere?"

I don't wish to offend anybody, I'm merely making an observation.

If you want to see CU-SeeMe spread to the masses, to people who don't
know the first thing about networking or protocols or bandwidths or,
for that matter, the computer they're using, you have to make sure it
works. You cannot rely on end users, with no knowledge about
infrastructure etc, to be able to "dial" the correct transmission
rate. Not even their service provider would be able to tell them.

A couple of days ago we had one of the more absurd incidents -- from
Japan to Russia. To satisfy people's curiosity, this is the route
from Japan to Amsterdam:

[...]
11 izumi.gw.tohoku.ac.jp (130.34.10.3) 332 ms 332 ms 349 ms
12 kahoku.topic.ad.jp (130.34.10.2) 334 ms 364 ms 322 ms
13 tohoku.bb.sinet.ad.jp (150.99.2.1) 375 ms 375 ms 345 ms
14 new-tohoku-S1/1.bb.sinet.ad.jp (150.99.168.1) 355 ms 348 ms 368 ms
15 new-nacsis.bb.sinet.ad.jp (150.99.100.1) 325 ms 317 ms 340 ms
16 nacsis-gate-E1.sinet.ad.jp (150.99.99.12) 656 ms * 442 ms
17 Boone1.VA.ALTER.NET (192.157.65.227) 422 ms 322 ms 378 ms
18 Falls-Church4.VA.ALTER.NET (137.39.43.97) 329 ms 445 ms 334 ms
19 Falls-Church1.VA.ALTER.NET (137.39.8.2) 445 ms 366 ms 343 ms
20 Amsterdam2.NL.EU.net (134.222.5.1) 333 ms Amsterdam2.NL.EU.net (134.222.35.1) 334 ms 335 ms

And this is the route from Amsterdam to the receiving side (we have
a source-route block in Finland, so I have to do it in two turns):

1 Amsterdam1.NL.EU.net (192.16.202.32) 2 ms 4 ms 3 ms
2 Amsterdam2.NL.EU.net (193.242.84.2) 5 ms 3 ms 3 ms
3 Helsinki1.FI.EU.net (134.222.27.2) 45 ms 121 ms 43 ms
4 StPetersburg.RU.EU.net (134.222.23.2) 69 ms 107 ms 109 ms
5 Moscow-M9-3.Relcom.EU.net (193.124.254.34) 89 ms 117 ms 68 ms
6 Moscow-KIAE-2.Relcom.EU.net (193.124.254.38) 127 ms 75 ms 69 ms
7 pczz-gw.pczz.msk.su (193.124.254.22) 283 ms 87 ms 87 ms
8 pool-1.pczz.msk.su (193.124.25.193) 91 ms 91 ms 95 ms
9 irkutsk-gw.irkutsk.su (193.124.118.65) 442 ms 401 ms 388 ms
10 ccsoan.irkutsk.su (193.124.118.67) 622 ms 591 ms 549 ms

The traffic was way, way above the default you mention of 80kbit. It
did real, serious damage to both Finnish and Russian traffic. After
15 minutes the rate hadn't been adjusted even the slightest, and we
blocked it. The receiving side is behind a 19.2k SLIP link, BTW.

> those lines, and we always welcome additional suggestions. Also, we need

What you should do, IM(NS)HO, is to put a fair amount of effort into
low-level protocol development. I think that's the only way to make
CU-SeeMe work in a real-world environment. As you have explained,
you cannot use TCP, and that's fine. But using uncontrolled UDP,
apparently with some rate adaption based on packet loss (excuse me?),
is not a working solution. What Cu-SeeMe needs is some kind of "real
time TCP" without retransmission. Ie slow start, very sensitive
congestion control, RTT estimation and sliding window, and what not.
There is actually a lot of work going on with that in connection
with multicast. Is the Cu-SeeMe team on the mbone list? Here's
a very old note on just one aspect:

--- Forwarded mail from avg@titan.sprintlink.net (Vadim Antonov)

Date: Mon, 24 Jan 1994 19:15:06 -0500
From: avg@titan.sprintlink.net (Vadim Antonov)
To: avg@titan.sprintlink.net, deering@parc.xerox.com
Subject: Re: bounding *variance*
Cc: mbone@ISI.EDU

>Could you please explain a bit more how your proposed RTTL field is
>intended to work. Your comment that "routers can adjust RTTLs" leads
>me to believe that I do not understand what you are proposing. Is
>it a hop-by-hop time limit that you are advocating?

I see multicasting channel as a logical tree-like structure layered
over physical network. A marginal case of multicast "tree" is a
unicast point-to-point channel. The nodes and leaves of multicast
trees are connected by unicast channels (aka tunnels) and RTTLs
should be negotianted for such channels by peers or by physical
broadcasting mediums (Ethernet, radio etc).

The very nature of physical broadcasting mediums makes all delay
variance caused *solely* by the transmitter.

Of course, this is a bit restrictive (i.e. assumes that every
box between physically multicasting network and unicasting network
can do multicast routing).

Every multicasting router maintains the list of initial RTTLs for
unicast peers (obtained with some kind of dynamic roundtrip time
measurement like one used in TCP). When incoming packet comes
in the router adds expected RTTL for the uplink to the RTTL field
of the packet (it can yield negative value!) and then emits packets
to the peers with their initial RTTLs _plus_ the RTTL defect from
the uplink.

Non-multicasting routers forming the physical network should simply
decrement the RTTL field and throw away expired packets.

So, for multicasting routers RTTL is hop-to-hop; for non-multicasting
routers its a plain RTTL counter. A router can act like multicasting
and non-multicasting simultaneously for different channels.

>Yes, routers must take action to prevent long-lived lengthy queues,
>preferably discarding the packets from those sources that are "guilty"
>of causing the congestion. A couple of algorithms that have been
>proposed for that purpose are Jacobson & Floyd's RED algorithm, and
>McKenney's Stochastic Fair Queueing. Neither of them require fine-grain
>time-to-live fields in packet headers.

RTTL is easy to implement in hardware...

How initial RTTLs are obtained is an interesting question; there can
be some kind of adaptive feedback algorithm (like ST-IIs) so recipients
can pass upstream their tolerance boundaries and let routers aggregate
them (also, routers can *restrict* tolerance levels as a matter of
routing policy to protect the network from congestion).

--vadim

--- End of forwarded message from avg@titan.sprintlink.net (Vadim Antonov)

--
bilse <bilse@EU.net> +31 20 592 5109 (dir: 5110);  fax +31 20 592 5163
                ``We used to ! but now we @'' (jensen)