Re: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

[Kazuho Oku <[e-mail]>]

2018-05-24 9:05 GMT+09:00 Jana Iyengar <[e-mail]>:
> I agree that we must grapple with the question of what this proposal does to
> the timeline and that schedule needs to be a part of the discussion.
>
> That said, I think this needs to be done in context. Going into London, the
> editors spent three days whittling down and addressing open issues as best
> we could. This was presented during the wg meeting. Importantly, the list of
> issues that we had no clear ideas or direction on how to fix were all around
> the handshake (see slide 9 in this deck.)
>
> The set of handshake issues is probably the most difficult and glaring one
> at this point in the list of pending QUICv1 issues.
>
> Solving them with the DT's proposal moves us closer to our goals. Yes, it
> will take time, but how much time any other solution(s) take? We have only
> one other real proposal that fully solves all those issues: some form of the
> QUIC/DTLS proposal. The DT spent time with further generations of
> integrating QUIC and DTLS, but among others, there are concerns of available
> implementations and implementation maturity there. Additionally, that
> proposal ends up tying up QUIC and DTLS standardization processes in ways
> that may cause even more delay and limit future evolution. It may be worth
> documenting the alternative DTLS proposal and why the DT chose the proposal
> it did, for posterity.

FWIW, I have added Appendix C to the design doc that briefly explains
the DTLS-based approach as well as the reasons why we abandoned it.

The text is rough and is likely to have some aspects missing, I would
appreciate it if anybody in the Design Team could improve it.

Lastly, the comparison of the wire formats between the DTLS-based
approach and the proposed approach might give us a clue on what the
difference of security aspects are between DTLS and the proposed
approach. I think that it is more natural to compare the proposed
approach to DTLS than to TLS when discussing about security aspects.

>
> I agree that we should have a discussion on what this proposal does to our
> timeline. But I'll note that this is finally a timeline that would include
> real solutions to important open issues that need solving for QUICv1 to
> finish.
>
>
> On Wed, May 23, 2018 at 2:47 PM, Lucas Pardue <[e-mail]>
> wrote:
>>
>> Hi Ted,
>>
>> Thanks for your thoughts.
>>
>> > My back of the envelope calculation is that this means at least one more
>> > cycle of specification and interop will be required before we get back to
>> > where we are with draft -11, and that estimate is because I'm in a hopeful
>> > mood that Sean and Eric can move the required work in TLS along.  A more
>> > practical Ted would see this as adding at minimum 6 months to the schedule.
>> > The changes in TLS are also large enough that I expect that the deployment
>> > time to see significant penetration of the new libraries to be longer than
>> > it would be for the previous design.   Call it 9 months, with 3 months of
>> > error bar.
>>
>> I can't talk to the merit of this proposal in relation to QUIC transport.
>> As somebody greatly interested in application mapping (with a WIP HTTP/QUIC
>> implementation) I have concerns that progress in this area keeps being
>> pushed back. We have little interop experience in this area to feed back to
>> transport.
>>
>> A particular sore point is that the handshake-oriented changes have weak
>> relation to QUIC "steady state', upon which application mappings depend.
>> E.g. Draft 09 and 12 differ little in handling of STREAM frames.
>>
>> Regards
>> Lucas
>
>



-- 
Kazuho Oku