W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

#466 segment compression

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Tue, 29 Apr 2014 16:26:12 +1000
Message-ID: <CACweHNCdjo_LoizLqreayKb5tZB-LfDOay5HeCM8hyQvYWUg=w@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Cc: Martin Thomson <martin.thomson@gmail.com>
I just saw issue #466 and couldn't find a discussion on the list, so I'm
starting a new one.  The issue says:

> 2. Compression effectively creates a delineation similar to what
> segments allow; aligning the two would avoid issues with reframing,
> padding and other related concerns.

I don't understand this point, but that's probably because I don't
understand segments. AFAICT they were originally a way of ensuring that
certain headers are interleaved with data at specific boundaries, which can
be used as a sort of covert sub-resource scheme if the sender and receiver
both understand the significance of the segmentation.

I presume there's something in there that says that only the resource can
set END_SEGMENT bits -- but I can't find it on a quick skim. If not, that's
potentially a whole other issue.

Per-frame compression, as I envisioned it, doesn't create any delineation
at all; at least, no more than existing frame boundaries already do. A
reluctant intermediary might be more likely to retransmit compressed frames
than to unzip+reframe, I suppose...

In the simplest case, compression lets you reduce the size of your frames;
more optimally it can be used to reduce the number of frames (by reframing
after compression); taking it a step further, the optimally-packed
compressed frames can be padded out to mask the nature of their content.
All three operations (determining frame length, compressing frames, and
padding) are hop-by-hop operations, and any intermediary can second-guess
or obstinately undo the previous hop's choices if it wants.

If the original resource really wants to ensure that two chunks of data
don't ever share a compression context, it puts them in separate frames
with an END_SEGMENT in between. This delineates the compression contexts,
completely different from a delineation resulting from the compression.

Why add complexity and overhead (rules that govern how frames are marked,
machinery to ensure those rules are followed, long-lived compression
contexts, bookkeeping for those contexts, etc.) just to conflate two
concepts that were hitherto unrelated?

  Matthew Kerwin
Received on Tuesday, 29 April 2014 06:27:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC