Re: thoughts

Per Gregers Bilse (bilse@EU.net)
Fri, 21 Oct 1994 06:59:44 -0400


On Oct 17, 21:38, Tim_Dorcey@cornell.edu wrote:
> >> anybody have time to help us out with some quick experiments? Try running
> >> CU-SeeMe point-to-point along with some big ftp's over some low capacity
> >> link and measure the throughputs. Does CU-SeeMe's rate cap stabilize? How
> >> does it compare to the ftp throughput?].
> >
> > We have done close to this. With a limited bandwidth serial line to a
> >remote office, we added one cu-seeme point-to-point connection, limited
> >to a fairly low rate maximum transmission. The effect was to destroy the
> >performance for users of TCP terminal sessions.
>
> This is much different than what I had in mind with an ftp, where TCP would
> be trying to move the data as fast as it could (rather than as fast as a
> user could type). CU-SeeMe tries to gauge the capacity of it's connection
> by the amount of packet loss it experiences. If it lost a few packets
> while a person was typing quickly or a screen was being rapidly updated, it
> would slow down, but would probably speed right back up during the next
> lull in terminal traffic. I'm not saying that CU-SeeMe would be a lot more
> yielding against an ftp; I just don't think competition with terminal
> traffic provides much evidence either way.

I'm a little surprised that nobody has taken exception with this.

In networking terms one has the concept of "well-behaved" protocols
and applications. TCP is a well-behaved protocol. Early versions
of networked "Doom" was a very ill-behaved application.

If a severely limited ...

> >remote office, we added one cu-seeme point-to-point connection, limited
> >to a fairly low rate maximum transmission. The effect was to destroy the
> >performance for users of TCP terminal sessions.

.. CU-SeeMe session prevents low bandwidth, well-behaved traffic
like terminal sessions from getting through, how will higher-volume,
well-behaved traffic fare? Why don't you stage the experiment
yourself, if you believe an experiment is necessary? You do know how
TCP works and deals with network congestion, don't you? A non-TCP
application doesn't need particularly pointed elbows to cause TCP,
which is very polite, to slow down to a crawl.

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.
"

And yet, we have to roll out all the hazarduous settings in wping
before the traffic it generates shows up in our traffic monitors.

But with CU-SeeMe, it's warp 9 at the click of a mouse button. It's
child's play. With a machine gun.

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