Re: Virtual Circuit protocols => universal access

Ramin Firoozye (rpa@netcom.com)
Sun, 21 Aug 1994 18:57:37 -0700 (PDT)

>
> [ Much cool stuff about downloading over VC's edited for space... ]
>
> So the point, I guess, is that virtual circuits are well-understood,
> and can be optimized for various network topologies and technologies,
> and they're the only consumer technology networking available today.
> ...
> So while request-response protocols like ARDP and TTCP may be optimal
> for distibuted hypermedia applications, the success of WWW is rooted
> in its widespread accessability, not it's high-tech features. Mosaic
> and lynx are easy to use, and HTML and URL's are easy to understand;
> hence WWW has become nearly consumer technology. It has clearly
> advanced beyond research/engineering/hacker technology into the
> business communications arena. And it's only a matter of time before
> high bandwidth connection to the home becomes ubiquitous.
>
> In a few years, we'll want to upgrade to more optimal protocols, so
> we need to research them now, but virual circuits are not passe. Not
> as long as the modem-connected user base outnumbers the
> digital-connected userbase (be it ethernet, FDDI, ISDN, ATM, etc.)
> by, say, 1000 to 1.
>
Uh... I don't know if I see the relation between your good experiences
downloading to your PC and the VC/DG discussion. The issue is not a
matter of bandwidth, or even that of ease of programming (both VC's and
datagrams are media independent, and as long as you have something
like libwww, why should one care?)

I agree with your notion that supporting modem access is going to be
something of an ongoing concern. However, the most popular current scheme
is to setup SLIP/PPP and use everything as normal. The only big advantage
of this over a dedicated transfer protocol (like Kermit) is that SLIP
presumably takes care of multiplexing multiple connections. In practice,
once you start a single BIG transfer, since no-one takes care to implement
load-throttling, you might as well be directly connected through one
session, because everything else comes to a halt.

I have seen some incredibly cool asynchronous protocols implemented over
serial lines that allow you to continue working while a transfer is
in progress. SoftArc's First Class and certain versions of Blast immediately
come to mind. And through gateways, you can basically perform what you
would over SLIP.

The issue is not VC versus DG's. TCP is just one implementation of
VC's over a datagram layer. Those who don't like TCP's default overhead
for certain media and applications argue for doing a simpler DG-based
protocol. I personally think it's all irrelevant since the debate is
not about functionality but about performance. And since there
are a lot more areas where you can squeeze performance, the VC/DG
issue is something of an academic exercise best left to the readers (;-)

I say we go ahead and dispense with the VC<->DG debate. I prefer the RPC
vs. Messaging one. Should libwww just switch to RPC and do away with
this HTTP protocol business. Anyone? >;-)

Cheers,
R.

-- 
Ramin Firoozye' 
rp&A Inc. - San Francisco, California
Internet: rpa@netcom.COM - CIS: 70751,252

--