RE: #445: Transfer-Codings

On Thursday,24 April 2014 23:59, Martin Thomson wrote:
> On 24 April 2014 14:12,  <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>> wrote:

>>

>> If you're going to impose a requirement on the receiver to track [the state of the COMPRESSED flag] for all streams, then you might

>> as well change from per frame compression to per segment compression. Per segment compression would

>> improve the compression factor. It would also be more compatible with T-E from 1.1 (eg at 1.1 <-> 2 gateways).

>

> Sorry, I should have made that clearer.  That is what I intended to imply.  It means that you get C-E equivalent

> performance if you don't mix security contexts in the same entity body (and don't segment). However, it does

> increase state overheads significantly because it's not just the single bit, it's an entire compression context that

> you carry over between frames.



Ok.  We had a big disconnect.  I didn’t realized you were implying a single compression context per segment.

That's NOT what Johnny said when he suggested the idea of using END_SEGMENT (hence my confusion).

He said (emphasis added)...

"...compression is per-frame, but intermediaries may re-frame and re-compress within a segment iff the origin also compressed that segment."



A few thoughts follow, but most importantly, what are we supposed to implement for the -12 implementation draft?  (It quite clearly states that compression is per frame.)



Benefits of one compression context per segment:

- Per segment compression is closer in concept to Transfer-Encoding in 1.1.

- As you pointed out, it also has better compression performance (comparable to C-E gzip).



Drawbacks of one compression context per segment:

- As you pointed out, doing per segment compression “increases state overhead significantly” (and implementation complexity).

- It makes the COMPRESSED flag redundant and somewhat ambiguous.

  + It would make more sense to have a mechanism for signalling BEGIN_SEGMENT and the COMPRESSED flag is only valid when BEGIN_SEGMENT is set.



Since we already hashed all of this out once, I would prefer to stick with per frame compression, but loosen the security restrictions to include Johnny’s idea of re-frame and re-compress within a segment.  To accomplish that I would use Johnny’s statement with the following change…



"...compression is per-frame, but intermediaries may re-frame and re-compress within a segment iff the origin also compressed at least one frame within that segment."



Although it might be odd to mix uncompressed frames with compressed frames within a segment, I don’t see a security concern that makes it necessary to enforce that all frames within a segment are either compressed or not compressed.



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.