Re: [Wpack] Mirja Kühlewind's Block on charter-ietf-wpack-00-14: (with BLOCK and COMMENT)

[Jeffrey Yasskin <[e-mail]>]

On Thu, Feb 27, 2020 at 7:21 AM Alexey Melnikov <[e-mail]>
wrote:

> Hi Mirja,
>
> I am only replying below to your blocking comments:
>
> On Thu, Feb 27, 2020, at 3:07 PM, Mirja Kühlewind via Datatracker wrote:
> > Mirja Kühlewind has entered the following ballot position for
> > charter-ietf-wpack-00-14: Block
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/charter-ietf-wpack/
> >
> >
> >
> > ----------------------------------------------------------------------
> > BLOCK:
> > ----------------------------------------------------------------------
> >
> > Thanks for all the discussion that happen on the charter so far,
> unfortunately
> > there are still a few points that are not fully clear to me from a
> transport
> > perspective:
> >
> > 1) It not clear to me how you plan to address low latency. I assume you
> don't
> > want to optimise anything in the lower layers but it does sound a bit
> like it.
> > Can you clarify this point?
>
> WPACK is working on a bundle format, so there is no transport protocol
> here. Can you suggest how to clarify this?
>

We could split this into two requirements:

>>>>>
* When a bundle is streamed, the client must be able to start using a
subresource before the entire bundle is downloaded, and for large
subresources, before the entire subresource is downloaded.

* When a bundle is loaded from random-access storage, the client must be
able to use a subresource without necessarily reading the entire prefix of
the bundle before that subresource.
<<<<<

Those were roughly what I had in mind when I wrote "low latency".

The current format achieves the first by putting the index of subresources
at the start of the bundle (unlike ZIP) and by using
https://tools.ietf.org/html/draft-thomson-http-mice-03 to protect
subresource integrity.

It achieves the second by having an index (unlike multipart/*).

> 2) I think "Being extensible and crypto agile" is a requirement we have
> for any
> > protocol we design. Is there anything special here, or why is this
> listed?
>
> Nothing special in this case, but in order to avoid any doubts.
>
> > 3) I also don't really understand this point
> > "Specifying constraints on how clients load the formats without
> describing
> > specific loading algorithm to help achieve the above goals"
> > Can you further explain? I assume there are no transport implications
> here but
> > as I'm not sure what is meant, I'd like to double-check!
>
> No transport implications. By "load" this means from disk/web browser
> cache. Does this help?
>

See also the discussion on the IESG list under "WG Review: Web Packaging
(wpack)" and at
https://mailarchive.ietf.org/arch/msg/wpack/gokRbg6vSxHz3jC3eqcVhYkIF1s/.

> 4) Again here I'm not sure what is meant and I assume you don't plan for
> any
> > transport protocol changes or extension but double-checking! "Optimize
> > transport of large numbers of small same-origin resources." What does
> this
> > mean? What's the solution you have in mind?
>
> I might need Jeffrey's help to reply to this one. I am pretty sure there
> are no transport protocol implications.
>

This was about improving compression by letting the compression algorithm
keep state across many resources. There have also been a few attempts to
get the same benefits in HTTP directly, whose difficulties have led to
https://tools.ietf.org/html/draft-handte-httpbis-dict-sec-00.

Thanks for the transport-oriented review!

Jeffrey