- From: <touch@isi.edu>
- Date: Fri, 30 May 1997 09:59:14 -0700
- To: touch@isi.edu, brusinsk@ibdr.inf.tu-dresden.de
- Cc: http-wg@cuckoo.hpl.hp.com
> 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