Server-side data conversion and Internet bandwidth (was: Re: Multi column layout question.)

Philippe-Andre Prindeville (philipp@res.enst.fr)
Sun, 25 Jun 95 02:29:45 +0200


Date: Sun, 25 Jun 95 02:29:45 +0200
From: Philippe-Andre Prindeville <philipp@res.enst.fr>
Message-Id: <9506250229.ZM13773@jones.res.enst.fr>
In-Reply-To: lilley <lilley@afs.mcc.ac.uk>
To: www-html@www10.w3.org
Subject: Server-side data conversion and Internet bandwidth (was: Re: Multi column layout question.)

On Jun 23, 15:45, lilley wrote:

> > [ ... ]

> Heh. Never even occured to me that page was a problem. Then again on my 
> 1280x1024 screen my browser comes up 780 wide by 892 high.
> 
> You see that as a problem because your lower resolution screen uses less
> pixels to make the same point size of text.

> [ ... ]

> This problem is being adressed in the following areas:
> 
> - HTML 3.0 FIG which take width and height in real world units
> - stylesheets, which can magnify everything with a lens mapping

I was wondering when the discussion was going to take this
turn before I threw my monkey wrench (or "spanner", for you
on the civilized side of the Atlantic) into the works...

We've done some projections on TCP performance on the evolving
Internet, and while the results aren't ready to publish, they
are nonetheless startling:

	As the Internet grows and more dial-up users connect
	(currently the fastest growing community), we will
	see increasing congestion on inter-IXC (and inter-NAP)
	links on the "backbone" Internet.  Result: most low-
	bandwidth users (ie. less than 128kb/s) will never
	have a window size greater than *ONE PACKET*.

Surprise!  So, what's the conclusion?  Well, most Internet
providers won't want to increase the bandwidth of the links
that connect them to their regionals, because there's no profit
in this (at least until users wise up and start bitching about
poor network performance, ie. 12kb/s ftps on a 28.8kb/s line).
Congestion will only get worse, even with the advent of
bandwidth-on-demand, such as ATM, frame-relay, or SMDS.

Alright, so where am I taking all of this reasoning?  Most
of you people I suppose aren't interested in low-level
network tinkering...

Just here:  image scaling (ie. fitting an image into a
640x400 rectangle), depth reduction (taking a 24bit GIF file
and rendering it in 1bit deep B&W on a notebook), etc.  should
be done *SERVER-SIDE*.

Now before you flame me, I realize this is unclean and not
the logical place to do this:  the client should be
burdened by whatever presentational computation his
preferences entail.  Sure.  That's logical.

But should everyone be penalized by wasted network bandwidth
in transmitting images (or sound) in a format that exceeds
the possible capacities of the rendering hardware?

On the other hand, if I browse some images on the road with
my monochrome laptop, and these images are cached, then plug
my laptop into a colour monitor at work or at home at a higher
resolution and depth, the cache will be invalid, since the
images will have to be "refreshed" at a higher resolution.
Or at least, they should be.  Of course, this is an admittedly
rare event...

Am I the only one to lose sleep over these issues?

Should HTML 3.0 architects be concerned about the
economics of the Internet?  And what will happen if they
aren't?

HTML *is* after all the biggest consumer of bits on the
Internet today...

-Philip