Re: Chopan - Compressed HTTP Over PANs (draft-frank-6lowpan-chopan-00)

Go read the draft more closely.

The premise is, low power, low bandwidth personal area networks.

Bytes translate into power, latency and bandwidth used.

So 3 strikes, and conventional text based HTTP is out, in my mind.  HTTP 
is *way* more verbose than almost any binary encoding (by a very large 
factor).

Lots of uses of HTTP are for things other than transporting large 
compressed images, in which the image transport dominates.  Don't 
extrapolate general web traffic to the intended applications.

So I don't think that arguing something else may be needed is really 
questionable.  I was arguing, however, that: 1) first explore completely 
  compatible and extensible encoding; 2) if that isn't compact enough, 
then relax compatibility constraints and go to a statefull protocol. 
(like we explored over a decade ago, but which have other issues).

I suspect 1) will be sufficient for the stated goals, because when you 
are tethered by a low bandwidth net, you always have enough cycles 
around.  It's when both performance and compactness are key that 2) 
really becomes reasonable.  HTTP parsers are way slower than simpler, 
better engineered protocols can be without the legacy than the old 
email/mime/http framework carries.
                            - Jim




J Ross Nicoll wrote:
> Jim Gettys wrote:
> 
>> Those of you with memory of my role in HTTP may find the following
>> comments surprising, but bear with me.
>>
>> Doing something like this has to pass test, in my mind:
>>   o that it be shown to be significantly more compact than HTTP +
>> deflate style compression (probably with a pre-defined dictionary, and
>> canonicalization of cases of strings to minimize the size of the
>> dictionary).  Ad-hoc binary compression systems are often/commonly not
>> less efficient than what gzip style compressors can do.  (to remind the
>> audience, deflate is gzip without some preamble information; and IIRC,
>> it can be used with a predefined dictionary, so you don't have to
>> transmit said dictionary first when you know the material being
>> compressed).
> I'd also want it shown that it's a saving even worth having. It seems a
> tiny saving in terms of bandwidth used, even on a low speed network. The
> specification talks about memory footprint as well ("Binary compression:
> HTTP headers are compressed into a binary format to save bandwidth and
> buffer space"), but I still find it hard to believe anything for which
> 100-200 bytes (if that) will make a difference, will be able to do
> anything sensible with the content.
>

Received on Tuesday, 14 July 2009 11:19:47 UTC