NOTE-HTTP-NG-testbed-19980710 18.7 KB

Raw Blame History Permalink

<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
  <META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (X11; I; Linux 2.0.34 i686) [Netscape]">
  <TITLE>Design of HTTP-NG Testbed</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" lang="en">
<DIV ALIGN=right>
  <H3>
    <A HREF="http://www.w3.org/"><IMG SRC="../../../../../Icons/WWW/w3c_home"
	ALT="W3C" BORDER=0 ALIGN=LEFT></A>NOTE-HTTP-NG-testbed-980710
  </H3>
</DIV>
<CENTER>
  <H1>
    Design of HTTP-NG Testbed
  </H1>
</CENTER>
<CENTER>
  <H3>
    W3C&nbsp;Note 10 July 1998
  </H3>
</CENTER>
<DL>
  <DT>
    This version:
  <DD>
    <A HREF="http://www.w3.org/TR/1998/NOTE-HTTP-NG-testbed-980710">http://www.w3.org/TR/1998/NOTE-HTTP-NG-testbed-980710</A>
  <DT>
    Latest Released Version:
  <DD>
    <A HREF="http://www.w3.org/TR/NOTE-HTTP-NG-testbed">http://www.w3.org/TR/NOTE-HTTP-NG-testbed</A>
  <DT>
    Author:
  <DD>
    <A HREF="mailto:veillard@w3.org">Daniel Veillard</A>,
    &lt;<A HREF="mailto:veillard@w3.org">veillard@w3.org</A>&gt;
</DL>
<p><small><A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright'>Copyright</A> &nbsp;&copy;&nbsp; 1998 <A href='http://www.w3.org'>W3C</A> (<A href='http://www.lcs.mit.edu'>MIT</A>, <A href='http://www.inria.fr/'>INRIA</A>, <A href='http://www.keio.ac.jp/'>Keio</A> ), All Rights Reserved. W3C <A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer'>liability,</A> <A href='http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks'>trademark</A>, <A href='http://www.w3.org/Consortium/Legal/copyright-documents.html'>document use </A>and <A href='http://www.w3.org/Consortium/Legal/copyright-software.html'>software licensing </A>rules apply.</small></p>
<H2>
  Status of this Document
</H2>
<P>
This is a note published by the
<A HREF="http://www.w3.org/Protocols/HTTP-NG/">HTTP-NG</A> Protocol Design
Working Group describing the goals, current state and future development
of the HTTP-NG testbed..
<P>
This document has been produced as part of the
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Activity">W3C HTTP-NG
Activity</A>. This is work in progress and does not imply endorsement by,
or the consensus of, either W3C or members of the
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/PDG/">HTTP-NG Protocol
Design</A> and <A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/WCG/">HTTP-NG
Web Characterization</A> Working Groups. This document is subject to change,
check the reference to the latest version.
<P>
The goal of the testbeds are to evaluate the feasibility of the
<A HREF="http://www.w3.org/Protocols/HTTP-NG/">HTTP-NG</A> model, its
performances, its extendibility, and the ability to integrate the HTTP-NG
model in he existing Web architecture. Building higher level demonstration
exhibiting the extra benefits of the HTTP-NG model is also planned. The suggested
experiments are of three kinds:
<OL>
  <LI>
    <A HREF="#Performanc">A base testbed infrastructure</A>
  <LI>
    <A HREF="#Extra">Higher level functionalities demonstrations</A>
  <LI>
    <A HREF="#Compatibil">Transition strategy evaluation</A>
  <LI>
    <A HREF="#software">Available tools and codebases</A>
  <LI>
    <A HREF="#Status">Current status</A>
</OL>
<P>
This document describes the expected architecture for each kind of testbed,
the main pieces of code used, the expected experiments and way to evaluate
the results.
<P>
This document is part of a suite of documents describing the HTTP-NG design
and prototype implementation:
<UL>
  <LI>
    <A HREF="http://www.w3.org/TR/1998/WD-HTTP-NG-goals">HTTP-NG Short- and Longterm Goals</A>, WD
  <LI>
    <A HREF="http://www.w3.org/TR/WD-HTTP-NG-architecture">HTTP-NG Architectural Model</A>, WD
  <LI>
    <A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">HTTP-NG Wire Protocol</A>, WD
  <LI>
    <A HREF="http://www.w3.org/TR/WD-HTTP-NG-wire">The Classic Web Interfaces in HTTP-NG</A>, WD
  <LI>
    <A HREF="http://www.w3.org/TR/WD-mux">The MUX Protocol</A>, WD
  <LI>
    <A HREF="http://www.w3.org/TR/NOTE-HTTP-NG-testbed">Description of the HTTP-NG Testbed</A>, Note
</UL>
<P>
Please send comments on this specification to
&lt;<A HREF="mailto:www-http-ng-comments@w3.org">www-http-ng-comments@w3.org</A>&gt;.
<H2>
  <A NAME="Performanc"></A>The base testbed infrastructure
</H2>
<P>
The purpose is to evaluate the suitability one can expect from HTTP-NG when
running basic HTTP interfaces using HTTP-NG protocol on both the client side
and the server. The architecture is a client issuing HTTP-NG requests, a
server answering these requests using a realistic set of Web pages. The requests
can either be generated by the SURGE URI generator tuned to reflect various
kind of common HTTP usage, or hand coded to reflect more specific uses. The
client may either run in "one shot" mode fetching a page and the related
inlined objects for the purpose of analyzing a complete trace of a session,
or in robot mode to produce a realistic load on the server. One goal is to
be able to run the exact same tests in a similar enviroment but using the
HTTP/1.1 protocol, in order to compare the characteristics of both stacks.
<P>
<IMG SRC="base.gif" ALT="image: base.gif" >
<P>
The first goal of this base testbed experiment is to verify that the HTTP-NG
specification can actually handle the functionalities used by HTTP 1.x users.
The output of the Web Characterization Working Group will be a set of scenarios
exhibiting common HTTP 1.x practices. The SURGE program will then be used
to generate a realistic set of URI and time stamps, which in turn will be
used by the HTTP-NG robot client as requests to the HTTP-NG server. One will
also need to verify that not so current practices - the top 10 kludge usage
of HTTP - can also be served and this will be handled in a more specific
fashion, either generating the URI by hand or modify the client/server software
(for example when running another protocol on top of HTTP).
<P>
The second goal of this series of experiments is to analyze the behavior
and performances of HTTP-NG under different qualities of services. One should
at least try to reproduce the following commonly found network conditions:
<UL>
  <LI>
    LAN: high bandwidth, low latencies.
  <LI>
    WAN: medium bandwidth, high latencies
  <LI>
    Dialup: low bandwidth, high latencies
  <LI>
    Satellite links (asymetric), wireless, etc.
</UL>
<P>
The following metrics are of interest:
<UL>
  <LI>
    latency: time between client start of the request, at the API level, and
    the availability of the beginning of the user level data
  <LI>
    throughput: this can be expressed using various different metrics, especially
    the size of the user data transferred by unit of time for one shot tests
    and the number of requests processed per second in robot mode.
  <LI>
    number of packets used
  <LI>
    average size of packets
  <LI>
    number of operating system calls needed
  <LI>
    load induced on the machines (system/user/io)
</UL>
<P>
This requires at least two machines and it may also be extremely useful to
get a dedicated piece of hardware sitting between the client and the server
which allows to simulate in a reproducible manner various network quality
of Services (bandwidth and latency tweaking). This may also be done using
an extra dedicated machine and a tunneling software.
<P>
Considering the software, one can be worried with the actual performances
of a Java, even if things may improve a lot in a not so distant future. Currently
is sound more reasonable to do the performance evaluation using a C code
base, and use ILU for both the client and server side. One should also try
to estimate the induced cost of genericity - ILU being a very generic system
supporting a lot of protocols and offering stubs for various languages.
<P>
Considering the server side, one need to implement some sample code sitting
behind the stubs generated from the interfaces by the ILU stubber. For this
purpose, ILU has been integrated into the Apache server.
<P>
The result of the tests should be compared with
<A HREF="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html">the
actual numbers obtained for the HTTP 1.1</A> . Getting half an order of magnitude
faster on latencies for LAN should not be too difficult, but we have to compare
with the full range of network Quality of Service all the metrics and check
that it's at least as good on each points before considering the results
a success.
<P>
The next goal of this testbed is to test the ability of HTTP-NG specification
to support proxies and caching. The base testbed will then be extended by
adding a proxy/cache for HTTP-NG between the client and the server.
<CENTER>
  <IMG SRC="proxy.gif" ALT="image: proxy.gif" >
</CENTER>
<P>
The analysis of the results on this configuration will probably a bit more
difficult to establish, here are a few points to look at:
<UL>
  <LI>
    performances in term of both throughput and CPU time usage.
  <LI>
    support for expiration time, content negotiation
  <LI>
    feasibility of differential updates and Push schemes for update of a set
    of caches
</UL>
<P>
One should keep in mind that caching in the Web is still in its infancy and
the HTTP-NG specification must be able to handle the big changes in Web caching
technology which are likely to occur within the next few years. Extendibility
is a key point of HTTP-NG design from the proxying and caching point of view.
<H2>
  <A NAME="Extra"></A>Higher level functionalities
</H2>
<P>
This testbed is really where we want to exhibit the extra capabilities of
HTTP-NG over HTTP 1.x . At this time it's somewhat difficult to predict how
extended this testbed will be, but a simple core experiment is definitely
needed to demonstrate the concepts behind HTTP-NG.
<P>
Here&nbsp; is an example based on existing W3C testbeds:
<OL>
  <LI>
    A <A HREF="http://www.w3.org/DOM/">DOM</A> (Document Object Model) demonstration,
    where the Web client exports via HTTP-NG it's internal documents structure
    and the associated interfaces as defined by the DOM WG document.
    <CENTER>
      <IMG SRC="DOM.gif" ALT="image: DOM.gif" >
    </CENTER>
    <P>
    This testbed will demonstrate how the general interface of the Web based
    on the "fetch then display" metaphor could shift onto a cooperative environment
    relying on distributed structured documents.
    <P>
    A DOM implementation on top of Amaya/Thot is likely to occur, and adding
    the support from HTTP-NG should be fairly trivial. This would provide a good
    framework for demonstration of extra capabilities made possible by HTTP-NG,
    here is a few suggestions:
    <UL>
      <LI>
	push like demo, where content is inserted using the DOM API from a server
	to the client.
      <LI>
	distributed authoring, based on WebDav semantics but achieved by the way
	of direct remote access
      <LI>
	shared HTML white board
      <LI>
	etc...
    </UL>
    <P>
    On such a framework, ideas to build demos come easily, the problem is mainly
    related to the manpower needed to achieve them, not the capabilities of the
    underlying platform.
  <LI>
    On the server side, adding WebDav APIs on top of and existing HTTP-NG server
    would be a good example of extensibility mechanism provided by HTTP-NG. Even
    without full support for the WebDav functionalities, a simple extension of
    Jigsaw providing access to
</OL>
<H2>
  <A NAME="Compatibil"></A>Transition strategy
</H2>
<P>
This testbed is needed to get a proof that the HTTP-NG can actually be deployed
on a large scale basis within the existing Web framework. We must show that
the HTTP-NG can actually be deployed even if a huge amount of software is
not currently able to support HTTP-NG protocol natively. The experience of
the migration from HTTP 1.0 to HTTP 1.1 showed that it's far easier to get
the server pool to implement new features (support for HTTP 1.1 is actually
available in most Web servers), than the client software, namely the browsers.
<P>
The goal of this testbed is to prove that it is actually possible to deploy
HTTP-NG on servers with an existing base of HTTP/1.* clients by implementing
translation proxies. It consist on designing and implementing an HTTP 1.*
to HTTP-NG proxy. We don't seek performances here and the cheapest implementation
will be the best one. This is purely a proof of concept with an actual
implementation:
<CENTER>
  <IMG SRC="compat.gif" ALT="image: compat.gif" >
</CENTER>
<P>
The test should be conducted using several, commercial grade, HTTP clients
accessing an HTTP-NG server. Successful experiment will not exhibit any loss
of usability from the client side. One should take care of testing all the
common HTTP services, at least GET, POST, PUT and HEAD.
<P>
Considering the software, on the client side the choice is wide open, one
should just tried the most popular browsers and editing tools, running a
1.1 robot may prove useful too to stress the proxy. Since performances is
not the goal of this testbed, one should go to the cheapest solution in term
of development costs and it seems that extending Jigsaw to get an HTTP-NG
client side is the way to go. Once done, one just need to tweak the existing
proxy code in Jigsaw to have client and server side using different stacks.
The HTTP -NG server could be the same as for the base testbed, or Jigsaw
if the HTTP-NG server side is implemented.
<H2>
  <A NAME="software"></A>Available tools and codebases
</H2>
<P>
One should probably have two different implementations of the HTTP-NG stack,
possibly using different languages. Most of the existing software we will
rely on is written in C or Java, and we will probably end up with a C/ILU
and a Java/Jigsaw implementations.
<P>
Here are the basic main pieces of software that will be used to to build
the HTTP-NG testbed::
<H3>
  <A HREF="ftp://ftp.parc.xerox.com/pub/ilu/ilu.html">ILU</A>:
</H3>
<P>
The Inter-Language Unification system (ILU) is a multi-language object interface
system. The object interfaces provided by ILU hide implementation distinctions
between different languages, between different address spaces, and between
operating system types.
<P>
ILU latest implementation contains HTTP-NG experimental code, a
<A HREF="http://www.w3.org/Protocols/HTTP-NG/Group/PDG/wire-protocol/WD-HTTP-NG-wire-971103.html">wire
format</A>, <A HREF="http://www.w3.org/Protocols/MUX/">MUX</A> channel
multiplexing implementation, and all the glue needed to link with stubs generated
from an Interface Definition Language (IDL). Since it is currently the most
advanced HTTP-NG framework, now it will serve to validate the first versions
of the drafts.
<H3>
  <A HREF="http://www.w3.org/Jigsaw/">Jigsaw</A>:
</H3>
<P>
Jigsaw is W3C's sample implementation of HTTP, the project constitutes an
ongoing W3C Activity . Jigsaw is a full blown HTTP server entirely written
in Java.
<P>
The HTTP-NG jigsaw code while not as advanced yet as ILU implementation will
provide a second piece of code, allowing to debug compatibility problems.
Being written in Java this also mean a different environment (virtual machine)
and hence a good test of operating system portability. Moreover the java
code gives access to two full featured testbed, Amaya and the Jigsaw server.
<H3>
  <A HREF="http://www.w3.org/Amaya">Amaya</A>:
</H3>
<P>
Amaya is a Web client that acts both as a browser and as an authoring tool.
It has been designed with the primary purpose of being a testbed for
experimenting and demonstrating new specifications and extensions of Web
protocols and standards.
<P>
An experimental version of Amaya embed Jigsaw Java HTTP stack, so it is possible
to get a browser and HTML editor using the Java HTTP-NG code. This will prove
useful for higher level functionalities demonstration, especially since
<A HREF="http://www.w3.org/PICS/">PICS</A> and
<A HREF="http://www.w3.org/DOM/">DOM</A> support are being added to Amaya.
<H3>
  <A HREF="http://www.apache.org/">Apache</A>:
</H3>
<P>
Apache is the most popular Web server, it is available freely with source
code.
<P>
A modified version of Apache embedding the ILU library has been produced
for the Testbed. It allows testing of the HTTP-NG stack within a full featured
Web server and provides a solid framework for tests, especially to compare
HTTP/1.1 and HTTP-NG respective performances.
<H3>
  Surge:
</H3>
<P>
SURGE (Scalable URI Reference Generator) is a WWW workload generator which
is based on analytical models of WWW use. The goal of SURGE is to provide
a scalable framework which, from the server's perspective, makes document
requests which mimics a set of real users.
<P>
The various common Web access pattern which result from the Web Characterization
Working Group will be described as SURGE analytical models, allowing to produce
realistic simulations of actual Web traffic for the base testbed infrastructure.
<H2>
  <A NAME="Status"></A>Current status
</H2>
<P>
The current status is that ILU library provides the core implementation of
HTTP-NG protocols, i.e. the MUX protocol, the wire encoding, the basic HTTP
interfaces stubs. Other pieces of software, namely Apache, Jigsaw, Surge,
Amaya have been modified to some extent to embed the ILU library. Currently
the base testbed is mostly functional, but more work is needed to test
performances, solve existing bottlenecks and cleanup the installation process
before a public release of the testbed. Advanced functionalities like proxy
testing and extensibility showcase are still waiting for more complete
specifications before upgrading the corresponding tools. <BR>
Here is a more detailed description of the current status of each piece of
software:
<OL>
  <LI>
    ILU : support for MUX, wire protocol, basic HTTP and HTTP-NG interfaces,
    test implementation for a robot and a server.
  <LI>
    Apache : ILU support integrated, the server serves a similar set of pages
    with Apache HTTP/1.1 implementation and a dynamically configurable ILU based
    protocol stack (can be HTTP or&nbsp; HTTP-NG experimental stacks) using the
    standard HTTP interfaces (GET, HEAD, POST).
  <LI>
    Amaya : versions embedding ILU and a Java interpreter are available. Currently
    the DOM API is not stable enough for testing but it already export the Thot
    APIs via ILU.
  <LI>
    Jigsaw : experiments with Jigsaw using ILU and the basic HTTP interface for
    serving pages has been conducted. The latest releases of Jigsaw provide specific
    extensions needed when exporting a resource using different protocol stacks,
    this should ease the design of HTTP-NG specific extensions. Jigsaw also provide
    an HTTP/1.1 proxy implementation, and seems the best candidate for test on
    an HTTP/1.1 &lt;-&gt; HTTP-NG proxy
  <LI>
    Surge : version 1.0 of Surge has been integrated with ILU.
  <LI>
    various other small software pieces are also available.
</OL>
<P>
Most of the software base is available in a CVS repository (except Amaya
and Jigsaw available independently) and we intend to make this publicly available
during the continuous design phase.&nbsp; <BR>
&nbsp;
</BODY></HTML>