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: Paul Leach <paulle@microsoft.com>
Date: Fri, 14 Jun 1996 10:23:12 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960614172312Z-3867@abash1.microsoft.com>
To: "'J.Crowcroft@cs.ucl.ac.uk'" <J.Crowcroft@cs.ucl.ac.uk>, "'touch@ISI.EDU'" <touch@isi.edu>
Cc: "'ses@tipper.oit.unc.edu'" <ses@tipper.oit.unc.edu>, "'masinter@parc.xerox.com'" <masinter@parc.xerox.com>, "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/926
Just FYI: HTTP/1.1 persistent connections do not support muxing. They do
support pipelining.

This doesn't affect the validity of your argument if/when a future
version of HTTP supported muxing.

Or perhaps you meant that the browser could use Range retrievals to
interleave the data from many resources so as to give good response time
to small objects?

In any case, some app level scheduling is still probably needed -- you
wouldn't just blindly send all the embedded objects in a page in
>From: 	touch@ISI.EDU[SMTP:touch@ISI.EDU]
>Sent: 	Friday, June 14, 1996 10:11 AM
>To: 	touch@ISI.EDU; J.Crowcroft@cs.ucl.ac.uk
>Cc: 	ses@tipper.oit.unc.edu; masinter@parc.xerox.com;
>Subject: 	Re: [touch@isi.edu: draft may be of interest]
>> From J.Crowcroft@cs.ucl.ac.uk Thu Jun 13 23:14:52 1996
>>  >P-HTTP is basically "IP over TCP" - given the necessary
>>  >chunking, muxing, etc. I don't know why that isn't as frightening
>>  >to anyone else...
>> um, no - not really - p-http gives you persistent VJCC - thus it is
>> safer than current http practice for the net, as well as kinder to the
>> kernel TCP state machine at browser and server ends....
>Perhaps I can clarify.
>HTTP/1.1 persistant connections needs to chunk and mux data at the
>application layer, in order to prevent a postscript file URL retreival
>from starving-out concurrent HTML URL retreivals, e.g. Which should get
>a higher priority? Currently, this isn't an issue, but in the future,
>we may need to do some scheduling and multilevel queuing and service 
>discipline at the mux.
>But we also need the multilevel queuing in the kernel.
>How do the two interact, except badly???
>Why do I want to do this at all at the application, if I have
>to do it in the kernel later too?
>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, 14 June 1996 10:31:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC