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

(Adding Yann and Felix, in case they have other thoughts)

Thank you, Watson and Martin!

That makes sense to me. RFC8878 was scoped to specify how the Zstandard
algorithm should work in general, but this draft is specifically about the
"zstd" token in HTTP Content Encoding contexts. That means that we probably
don't need to talk about other contexts (semi-private environments, etc.)
in this draft, and can just strongly define the token to mean we accept no
more than 8MB window sizes.

I filed an issue about this at
https://github.com/nidhijaju/draft-zstd-window-size/issues/2.

Best,
Nidhi

On Tue, Mar 5, 2024 at 2:30 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Tue, Mar 5, 2024, at 15:55, Nidhi Jaju wrote:
> > 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."
>
> My email was a veiled suggestion that you delete the paragraph.
>
> More generally, if you want to do something that is not the standard, then
> it is not the standard.  If you manage to make a private arrangement to do
> something other than the standard that's nice, but that doesn't need the
> blessing of the IETF.
>
> However, if you make a private arrangement to do something other than the
> standard, but use the standard codepoints, that carries a pretty serious
> risk of damaging interoperability.  Private stuff escapes confinement.  We
> should not encourage people to do that (even if they regularly do).


On Tue, Mar 5, 2024 at 3:25 PM Watson Ladd <watsonbladd@gmail.com> wrote:

>
>
> 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
>
>
>