Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

Please read my answer to Bernard's initial answer on my block as this is part of
the context for this response. 

So from my perspective, I think it is good to explicitly state that the WG will
use existing transport protocols. I think what Mirja was fishing after, is the
question, do you actually intended to use UDP/DTLS and build something on top of
that? I would strongly prefer that you do not. Becasue if you do the WG will
have to a have a congestion control solution baked into this. Which at a minimal
forces the WG to develop a protocol with a feedback solution over UDP to carry
information necessary for the congestion control loop. In that case I think this
WG slides sufficiently into transport land that I would request that this
becomes a TSV WG. So can we at least rule UDP/DTLS out of scope? 

Frankly I don't care if this is QUIC and/or HTTP/3 specific or also have a
TCP/TLS mapping also. However, this discussion do indicates that the WG would
need to start with forming some consensus on those questions. And I think it
also affects the timeline of the work. 

The other relevant aspect of this scope setting was my comment that the API does
not appear to be binding at all, rather it becomes a question of what the WG
have consensus on. The current charter text defines that the WG must at least do
three communciation methods:
 - Unreliable messages (if it can support fragemntation or not is undefined)
 - Reliable messages (based on wording likely with fragmentation, i.e. support
larger messages than one Path MTU)
 - Ordered streams of reliable messages (I assume supporting large message
sizes)

But, the above is not necessary an exhaustive list. Also the additiona details
are not defined. To me this indicates that the WG will have to either do an
initial effort to define the desired properties or take the proposals and then
document the actual properties. Does the charter needs any wording on how it
intends to work on that aspect. 

Cheers

Magnus Westerlund
TSV AD



On Mon, 2020-02-03 at 14:32 +0100, David Schinazi wrote:
> Hi Mirja,
> 
> We have not yet reached consensus on the exact details of a solution, which is
> what we'd like to do in the newly formed working group.
> In particular, we don't know if the new protocol will run over HTTP/3 or QUIC
> directly (or if we build both) for example.
> Therefore we wrote the charter in such a way that the working group will be
> able to make that decision.
> The latest PR attempts to clarify that this application protocol will run over
> QUIC or TLS (by TLS I mean TLS, not anything else like DTLS or eTLS) to
> address your concern that we might reinvent QUIC, which we explicitly do not
> want to do.
> 
> If you don't think the PR achieves this intent clearly, can you please propose
> text?
> 
> Thanks,
> David
> 
> 
> On Mon, Feb 3, 2020 at 1:27 PM Eric Rescorla <[e-mail]> wrote:
> > 
> > On Mon, Feb 3, 2020 at 3:42 AM Mirja Kuehlewind <[e-mail]> wrote:
> > > My understanding is that Victor proposed a (separate) binding for H3 or
> > > QUIC + you say there should also be a binding for TCP (or I guess TLS over
> > > TCP). If that are the three option why not writing in the charter that the
> > > group works on either separate binding for these cases or one binding that
> > > might cover multiple of these protocols?
> > 
> >  
> > I don't understand what this means. My point is I *don't* think we should do
> > an H3 binding.
> > 
> > -Ekr
> > 
> > > Mirja
> > > 
> > > 
> > > > On 3. Feb 2020, at 12:02, Eric Rescorla <[e-mail]> wrote:
> > > > 
> > > > 
> > > > 
> > > > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind <[e-mail]>
> > > wrote:
> > > > No I meant do you have another protocol proposal (given you said you
> > > might not want what is proposed by Victor)?
> > > > 
> > > > Well, what I'm actually saying is that it's not clear that we need *all*
> > > the ones proposed by Victor.
> > > > 
> > > > With that said, it's not clear to me if Victor has a TCP binding yet,
> > > but one is clearly needed.
> > > > 
> > > > -Ekr
> > > > 
> > > > 
> > > > > On 3. Feb 2020, at 11:55, Eric Rescorla <[e-mail]> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <[e-mail]>
> > > wrote:
> > > > > Yes, totally understood that you don’t want to put any specific
> > > protocol suggestions in the charter but right now it seem a bit too loose
> > > (from a transport point of view). So if you don’t want what is proposed
> > > currently, do you have another proposal? 
> > > > > 
> > > > > I'm fine with the current text. I'm arguing against the attempts to
> > > aggressively narrow it.
> > > > > 
> > > > > -Ekr
> > > > > 
> > > > > If you are working on a draft yourself, I think it would actually be
> > > nice to have a first version of this draft out before the groups is fully
> > > started to people discussion the charter right now, would actually better
> > > understand what the discussion is about.
> > > > > 
> > > > > Mirja
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 3. Feb 2020, at 11:44, Eric Rescorla <[e-mail]> wrote:
> > > > > > 
> > > > > > Well, I certainly don't think we should build a new version of QUIC,
> > > and it seems likely that QUIC will be involved somehow, but Victor had
> > > some quite specific protocol suggestions which might or might not be what
> > > we want. In addition we need to ensure that there's some parity via a TCP-
> > > based mechanism.
> > > > > > 
> > > > > > -Ekr
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <[e-mail]
> > > > wrote:
> > > > > > Hi Ekr, hi Martin,
> > > > > > 
> > > > > > I thought that building something on top of QUIC or H3 are
> > > preconditions for any solution. If that is the case I would also prefer to
> > > put this in the charter (to exclude it clearly from the scope of this
> > > group to rebuild a new QUIC or a new version of quic or something like
> > > that which should be done in the quic group; similar for http which should
> > > be done in the httpbis in future). If you think that is somehow too
> > > restrictive what are the option open, you would want to work on in this
> > > new group?
> > > > > > 
> > > > > > Mirja
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla <[e-mail]> wrote:
> > > > > > > 
> > > > > > > As MT says, I would not be comfortable if the charter defined the
> > > specific protocol starting points, given the uncertainty about exactly
> > > which pieces we will do.
> > > > > > > 
> > > > > > > -Ekr
> > > > > > > 
> > > > > > > 
> > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <[e-mail]>
> > > wrote:
> > > > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > > > > > > [BA] Would it be sufficient to add this clarification to the
> > > existing 
> > > > > > > > sentence? The result would look like this.
> > > > > > > > 
> > > > > > > > The WebTransport working group will define new client-server
> > > protocols 
> > > > > > > > or protocol extensions using QUIC or HTTP3 in order to support
> > > the 
> > > > > > > 
> > > > > > > I would instead say "building on existing protocol work" and then
> > > point out separately that this will definitely not define a new transport
> > > (or lower) layer protocol.
> > > > > > > 
> > > > > > > At Mozilla we are still uncertain about the set of protocols as
> > > currently proposed, and would feel uncomfortable limiting this to just
> > > those two *in the charter*.
> > > > > > > 
> > > > > > > -- 
> > > > > > > Webtransport mailing list
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/webtransport
> > > > > > > -- 
> > > > > > > Webtransport mailing list
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/webtransport
> > > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > Webtransport mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/webtransport
> > > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------