Re: [Webtransport] Comment(s) on draft-vvv-webtransport-overview

[Victor Vasiliev <[e-mail]>]

Hello Bernard,

Thank you for the comments!

On Tue, Nov 19, 2019 at 7:11 PM Bernard Aboba <[e-mail]>
wrote:

> Reading the WebTransport Protocol Framework, a few questions came to mind.
>
> Section 3
>
> "Since this data can be replayed by attackers, it MUST NOT be used unless
> the client has explicitly requested 0-RTT"
>
> [BA] While draft-pauly-quic-interface has the concept of "Send Idempotent"
> which makes data eligible for sending under 0-RTT keys, the WebTransport
> API (https://wicg.github.io/web-transport/) has no equivalent.  Is
> support for 0-RTT a desired feature?
>

Indeed.  We could add it, but I am not sure it's worth it at this point in
time.


> Section 4
>
> "All transport protocols MUST provide datagrams, unidirectional and
> bidirectional streams i order to make the transport protocols
> easily interchangeable."
>
> [BA] Are there a set of requirements for "fallback transport" as well?
>

Those requirements do apply to fallback transport, however the datagrams
would obviously end up being reliable.

5.
>
> "buffers for them should be small and prioritized over stream data"
>
> [BA] Are you envisaging absolute priority here (e.g. datagrams can starve
> out stream data)?
>

That was roughly my initial thought.  I suspect that we would want a better
scheme; #33 and #62 on the API repo have more detailed discussion of this.


> "In general, the transport should not apply aggregation algorithms (e.g.,
> Nagle's algorithm [RFC0896]) to datagrams."
>
>  [BA] draft-pauly-quic-datagram Section 5 says "This frame SHOULD be sent
> as as soon as possible, and MAY be coalesced with other frames".  Are there
> situations in which coalescing/aggregation is envisaged to be desirable so
> that API support is needed?  Also was this intended to be SHOULD NOT?
>

I can imagine coalescing to be a part of the API.  I have some ideas on how
to do this; filed https://github.com/WICG/web-transport/issues/79.


> NITs
>
> 1. Introduction
>
> Where should comments be sent?  Presumably to [e-mail]
> and/or a github repo?
>

Added a link into the preamble for all documents.


> 1.1
>
> s/in practice, its user/in practice, its use/
>

Fixed.


> 2.
>
> "a mechanism such as ICE [RFC8445] can be used"
>
> [BA] You might want to refer to ICE consent [RFC7675] instead of ICE.  But
> since this is the WebTransport Protocol Framework (e.g. client/server) I'm
> not sure why ICE need be mentioned.
>
>
This was a clarifying example.  Changed wording.


> 7.
>
> "the client must not be able to distinguish"
>
> [BA] should this be MUST NOT?
>

There's already a MUST NOT above, this is just clarifying text.

  -- Victor.