Re: Q: protocolls and fault tolerance

> From: Andreas Brusinsky <brusinsk@ibdr.inf.tu-dresden.de>
> 
> On Thu, 29 May 1997 touch@ISI.EDU wrote:
> > We did some analysis of HTTP on T/TCP, ARDP, and a few other 
> > base protocols. It was analysis-level only, though.
> 
> So is there up to now  only a HTTP based on TCP ?

Yes - the spec says exactly that.

> Is there a reference to a  paper or something discussing the mentionend
> analysis?

Yes - on the pubs list of the web pages:
	http://www.isi.edu/lsam/

"Modeling the Performance of HTTP Over Several Transport Protocols"

This is scheduled to appear in IEEE/ACM Transactions on Networking.

> > HTTP over ATM doesn't make much sense, per se, because:
> But aren't backbones rely on ATM to be fast enougth?
> Bandwith reservation could take place on na ATM network, which
> is - I believe - not possible with IP up to now. 
> 
> And as far as I know there are no really good IP on ATM realisations.

RFC1577 works just fine. It's just  that IP/ATM assumes every ATM
subnet is a LAN, since ATM doesn't have routing per se.

> > 	HTTP uses URLs, 
> > 	URLs use DNS, 
> > 	DNS is an name->IPnumber mapping
> But URLs or DNS names could be mapped to something else - another protocoll 
> would probably have also a kind of addressing framework. 

Sure - but the problem is how to get to those things when all 
you have is IP at the majority (nee, ALL) of the end stations. 
Everything has to get mapped back to IP anyway; what's the point
of 'yet another interoperability layer'?

We got where we are (pervasive, world-wide, interoperable) by
picking ONE interoperability layer. Anything that speaks IP can
join. Nothing else works (or at least I don't care how you get
me the IP).

> > PS - what's the win if straight on ATM? More expensive end equipment?
> Hopefully ATM hardware will become less expensive in future. It
> is probably overpriced nowdays anyway.

(warning - soapbox follows ;-)

Perhaps overpriced. But ATM makes the design choice:

	simple switching
	
	expensive host interfaces (to slice and dice, and reassemble)

However, since retransmission is done in chunks much larger than cells,
the "simple switching" needs some other components:

	early packet discard (dump the first cell of a packet, dump the rest)
	packet-sized output buffers
		(to prevent dumping all packets due to losing a few cells)
	packet-based ordering of multicast
		(to prevent interleaving cells of different packets,
		since AAL5 doesn't support interleaving packets
		to the same destination)

and the kicker
	routing support

Sounds like we just built a conventional router (or worse). And we
still have expensive host interfaces. Not a win.

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

Received on Friday, 30 May 1997 10:01:19 UTC