httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: HTTP-NG
Date Wed, 11 Feb 1998 06:36:30 GMT
On Tue, 10 Feb 1998, Daniel Veillard wrote:

> > I don't support going off on our own, and I doubt many people here would
> > either.  Standards are good.  Vendors trying to force a standard by means
> > of market share is bad and often doesn't work well.  I fully support
> > standards.  Right now, that means the W3C.  I understand the desire to
>  And IETF,  don't forget it, especially for HTTP !

Right now, I'm not aware of any IETF working groups or anything else being
actively involved in development of major changes to the HTTP protocol.
The working group charter suggests October 96 as a date for submitting
HTTP/1.2 to the IESG, however I would suggest that is a bit optimistic.

> > keep the size of groups down.  We face the same problems, only difference
> > is we don't have a choice of saying these people must spend this much time
> > on it.
> > 
> > But I have to tell you, that if HTTP-NG gets bogged down defining a new
> > standard in object mumbo jumbo (not implying it isn't important) then a
> > whole lot of people, including me, may end up with no choice but to try
> > to do something that makes my network happy.  HTTP right now doesn't.
>  Hum, that's at least three times that you raised the point of you network
> geing unhappy. What are you looking for ? What are the axis you consider
> that HTTP is failing using the network ?
>    - connections
>    - packet number/size
>    - what else ...
>  Is this a global reproach to the Web (protocol + content) or just to HTTP.
> You ain't shy, expose yourself ;-)

While I have many global complaints about the web, most of them are easily
solvable by simply lopping users' heads off.  Ok, that isn't true since
their moronic "let's update this every 5 minutes so it can be nice and up
to date; I only look at my computer for 30 minutes a day though" auto
updating content is getting worse.

But that is another issue.  Users want to do what users want to do.

The main problem is that HTTP is a horrible protocol from the view of a
TCP stack.  

First, it uses many short flows which are murder to TCP's
congestion control, introduce needless overhead and latency, etc.  I have
more serious concerns about this scaling with mass market high bandwidth

Second, there are too many darn connections (both in terms of simultaneous
connections and opening/closing).  Even with HTTP/1.1, I doubt clients
will succeed with only one connection to a server at once.  This comes
down to a basic conflict between delivering all the data in the fastest
manner (which HTTP/1.1 does reasonably well, after the initial parsing by
the client to figure out what it needs) and delivering the portion of the
data that the client needs to format things so the user can start reading.
In most cases, users parse information from the top of a document down (or
the bottom up, or whatever order your language goes for).   Current
solution is multiple connections; obvious change is multiplexing over a
single TCP connection, but that still has flaws and I think it always will
without some radically new queueing methods and/or QoS and/or more metered
charges.  There is still a lot that can be done here, and the right
answer needs to be flexible for both HTTP in current "interactive client
with a bunch of requests to make up something resembling a page" and in
future directions and uses.

Packet size is something that is largely addressed in HTTP/1.1 with

Does MSIE4 do pipelining efficiently?
My comments above are HTML-centric, but the concepts aren't.  You can
argue that things will move away from a user sitting there waiting for
transfers, and that has some value, but only a limited amount.

Henrik is aware of my (and I am sure many others) feelings on this.  I am
far from alone in this view and a lot of people have done a lot more
research than I have.  These issues, along with other performance related
issues where the problems and solutions are less obvious, and if HTTP-NG
is not going to be something that solves it in a reasonable timeframe
without bringing baggage that will delay implementation I think some other
solution is needed. 

Right now, I have no idea what the goals of HTTP-NG are, where it is right
now, what is being done, who is involved (ie. are there any network people
involved), what timeframe is being seriously looked at.  None of this can
be really answered any more than it has been already (which has been
useful) with a couple of lines in a mail message.

View raw message