Re: Fwd: New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txt

On Mon, Mar 4, 2024 at 8:57 PM Nidhi Jaju <nidhijaju@google.com> wrote:
>
> Hi Martin,
>
> Thanks for taking a look and the comments!
>
> I agree that `Content-Encoding: zstd` should mean that encoders use <=
8MB and decoders support >= 8MB. This is key, and if there's a better way
to word that, I'd love suggestions.
>
> The part that you mentioned about decoders being able to support a
different limit was added as an attempt to explain that deployments of zstd
operating in a private environment that don't care about interoperability
should negotiate it out-of-band. Maybe I could change that text to
something along the lines of:
>   "Decoders that wish to support a lower limit and encoders that wish to
emit
>   frames requiring a larger window size MUST negotiate the limit
out-of-band."
>
> What do you think? Also, do we need to address this case at all? It
specifically only applies in situations where endpoints aren't trying to
interoperate beyond a short list of peers.

The sad fact is that every file will go across the Internet, or some
suitably Internety segment of a network at least once and usually many
times. Containment is not likely.

>
> Best,
> Nidhi
>
> On Tue, Mar 5, 2024 at 1:12 PM Martin Thomson <mt@lowentropy.net> wrote:
>>
>> This seems fine.  And 8M is a fine choice of limit.
>>
>> However, I don't think that ㄟ( ▔, ▔ )ㄏ is a good interoperability
strategy:
>>
>> > Decoders are free to support higher or lower limits, depending on
local limitations, if negotiated out-of-band. Many deployments of Zstandard
operate in controlled, private environments and can directly communicate
with their encoder and decoder to negotiate a higher or lower limit.
>>
>> I think that it is obvious that decoders could support more.  But
supporting less would not be following the standard.  The same goes for an
encoder that wants a larger window.
>>
>> We should encourage people to choose a different way of identifying that
content-coding.  In other words, encoding > 8M or decoding < 8M is not
Content-Encoding: zstd.
>>
>> On Tue, Mar 5, 2024, at 14:16, Nidhi Jaju wrote:
>> > Hi all,
>> >
>> > I wrote a draft regarding window sizes in Zstandard Content Encoding
>> > that aims to update RFC8878
>> > <https://datatracker.ietf.org/doc/html/rfc8878> to require a specific
>> > limit for improved interoperability.
>> >
>> > For context, we recently shipped zstd Content Encoding support in
>> > Chrome 123 and came across incompatibilities in the field where
>> > developers were confused when their compressed content was not able to
>> > be decoded by Chrome, but was correctly decoded by curl and the zstd
>> > CLI. Having an explicit agreed-upon limit would help deployers of zstd
>> > to align their implementations and cause less user friction.
>> >
>> > I believe this topic was also previously discussed at
>> > https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0137.html
>> > and
>> > https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0178.html.
>> > This was also discussed at the W3C WebPerf WG meeting
>> > <
https://docs.google.com/document/d/1ijP7yc6UXZVgzpXDVmBa7h70gxLpFcqdlOZzL3DRT_0/edit#heading=h.xn2d3li0b8op
>
>> > at TPAC 2023.
>> >
>> > Please let us know what you think.
>> >
>> > Best regards,
>> > Nidhi
>> >
>> > ---------- Forwarded message ---------
>> > From: <internet-drafts@ietf..org <mailto:internet-drafts@ietf.org>>
>> > Date: Tue, Mar 5, 2024 at 7:26 AM
>> > Subject: New Version Notification for
draft-jaju-httpbis-zstd-window-size-00.txt
>> > To: W. Felix P. Handte <felixh@meta.com>, Nidhi Jaju <
nidhijaju@google.com>
>> >
>> >
>> > A new version of Internet-Draft
draft-jaju-httpbis-zstd-window-size-00.txt has
>> > been successfully submitted by Nidhi Jaju and posted to the
>> > IETF repository.
>> >
>> > Name:     draft-jaju-httpbis-zstd-window-size
>> > Revision: 00
>> > Title:    Window Sizing for Zstandard Content Encoding
>> > Date:     2024-03-04
>> > Group:    Individual Submission
>> > Pages:    5
>> > URL:
>> >
https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.txt
>> > Status:
>> > https://datatracker.ietf.org/doc/draft-jaju-httpbis-zstd-window-size/
>> > HTML:
>> >
https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.html
>> > HTMLized:
>> >
https://datatracker.ietf.org/doc/html/draft-jaju-httpbis-zstd-window-size
>> >
>> >
>> > Abstract:
>> >
>> >    Deployments of Zstandard, or "zstd", can use different window sizes
>> >    to limit memory usage during compression and decompression.  Some
>> >    browsers and user agents limit window sizes to mitigate memory usage
>> >    concerns, causing interoperability issues.  This document updates
the
>> >    window size limit in RFC8878 from a recommendation to a requirement
>> >    in HTTP contexts.
>> >
>> >
>> >
>> > The IETF Secretariat