Subject: [6lowpan] Compressed HTTP over 6LoWPANs

From: <[email-masked]>
Date: Tue, 16 Jun 2009 09:31:47 +0100

Brian,

We've been looking at similar use of HTTP for delay-disruption-tolerant
networks - which overlap with sensor networks in application quite a lot;
we're working on a DTN that is also a sensor network.

Details of this HTTP use in:

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf

RFC2616 is worded to allow HTTP not just over TCP, but over any bidirectional
stream; this could even be HDLC between connected nodes. For HTTP over
UDP, we propose streaming over the Saratoga protocol, which adds sequence numbers
retransmission in the face of errors, etc.

My take is that HTTP's strength is text, and that we'd want to be able
to compress any generic text well, perhaps starting with a common dictionary
of HTTP tokens (GET etc.) for the text compressor.

food for thought/discussion in Stockholm?

cheers,

L.

> I have posted an Internet-Draft with some of my ideas on what I've been
> calling "Chopan" for "Compressed HTTP Over PANs":
>
>  http://www.ietf.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt
>
> The ideas aren't fully flushed out, and I'm sure a broader group could
> probably do a lot to refine these ideas.  But hopefully this will be enough
> to get some ideas flowing.
>
> Brian

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Brian Frank <[email-masked]>
Date: Tue, 16 Jun 2009 09:07:12 -0400

> food for thought/discussion in Stockholm?

HTTP-DTN looks really interesting.  I especially like the store-forward
model and Content-Source and Content-Destination headers.

One troubling aspect of Chopan is how to handle PUT/POST to a sleeping
nodes.  Perhaps a store-forward model might be a better fit than trying make
it a caching model?

The idea of using a common dictionary for compressing any text (including
maybe even the body) might be really interesting.  The beauty of HTTP is
that provides a transport for any MIME typed data, so we can pass binary
data, text data, or new versions of compressed data.  For me, the open ended
nature of how a resource is represented on the wire is the most compelling
aspect of HTTP.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 16 Jun 2009 14:50:07 +0100

On the sleeping nodes, I imagine that there has to be a layer 2 wake  
mechanism in there?

Store and forward is easier to consider than proxying/intercepting; in  
many cases there's just two separate concatenated HTTP sessions and  
hops: sensor to IP gateway, then gateway (often post sensor data  
processing) across the terrestrial Internet. In other cases there are  
relay nodes in the sensor network adding more hops and more  
concatenated HTTP sessions.

Yes, the flexible text nature of HTTP makes it compelling over binary  
alternatives. Binary compression of MIME bodies is already carried out  
via e.g. gzip content encodings; that doesn't cover the headers. But  
there's also something in favour of not compressing headers for debug/ 
ease of use etc.

FYI, we'll be talking about HTTP (and HTP-DTN) and the various  
transports HTTP could be carried over other than TCP in the TSV-AREA  
meeting in Stockholm:

> Title: Turning HTTP into a full-fledged networking layer
> Presenter: Lloyd Wood
> Requested time: 10 mins.

On 16 Jun 2009, at 14:07, Brian Frank wrote:
> HTTP-DTN looks really interesting.  I especially like the store- 
> forward model and Content-Source and Content-Destination headers.
>
> One troubling aspect of Chopan is how to handle PUT/POST to a  
> sleeping nodes.  Perhaps a store-forward model might be a better fit  
> than trying make it a caching model?
>
> The idea of using a common dictionary for compressing any text  
> (including maybe even the body) might be really interesting.  The  
> beauty of HTTP is that provides a transport for any MIME typed data,  
> so we can pass binary data, text data, or new versions of compressed  
> data.  For me, the open ended nature of how a resource is  
> represented on the wire is the most compelling aspect of HTTP.
>

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Jun 2009 18:13:32 +0200

On Jun 16, 2009, at 10:31, <[email-masked]> wrote:

> common dictionary
> of HTTP tokens

As in RFC 3485 and 5112 (for SIP/SDP/presence)?

Gruesse, Carsten

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 18:15:52 +0100

Carsten Bormann [mailto:[email-masked]] wrote on Tue 2009-06-16 17:13
> As in RFC 3485 and 5112 (for SIP/SDP/presence)?

Similar to those, though the dictionary content and tokens would be somewhat different.