W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: [touch@isi.edu: draft may be of interest]

From: <touch@isi.edu>
Date: Thu, 13 Jun 1996 14:01:44 -0700
Message-Id: <199606132101.AA09306@ash.isi.edu>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, J.Crowcroft@cs.ucl.ac.uk
Cc: touch@isi.edu
> From J.Crowcroft@cs.ucl.ac.uk Thu Jun 13 11:37:57 1996
> Date: Thu Jun 13 11:37:57 1996 PDT
> From: Jon Crowcroft  <J.Crowcroft@cs.ucl.ac.uk>
> To: http-wg <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> Subject: Re: [touch@isi.edu: draft may be of interest]
>  >I've completed and submitted an internet draft on
>  >TCP Control Block Interdependence, which has some 
>  >observations on how to augment TCP implementations
>  >to provide performance similar to persistant-TCP
>  >layerings, without the multiplexing hazards.
>  Joe/Larry,
> as with T/TCP, this seems orthogonal to persistent HTTP......
> (if only for deployment reasons), but a nice piece of work....
> and academically, a more satisfactory approach.....but just hard to
> see ms/sun/apple (after snapple, maybe 'sams' = sun, apple, microSoft) 
> putting it in for 6 years....
> cheers
>  jon

I addressed how this affects p-HTTP in the implications section.
The main problem is that muxing at the application layer has some
side-effects, and will be incompatible with kernel-based integrated
services scheduling mechanisms.

Granted, in-the-app is easier to deploy, but only because you're
moving the kernel functions into the app, which can cause
interferences later as kernel functions evolve. It also assumes
that you're running only a single Web browser.

Then again, if you consider the browser the OS...


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 Thursday, 13 June 1996 14:06:46 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:03 EDT