Re: Second Implementation Draft Guidelines

[Kazuho Oku <[e-mail]>]

2017-07-09 1:45 GMT+09:00 Jana Iyengar <[e-mail]>:
> I've been thinking about this, and I'm starting to think that we should
> cover more ground in the second implementation draft.
>
> I'm hearing about increasing deployments of gQUIC, largely due to market
> pressures. The availability of the Chromium implementation makes it
> particularly easy for folks to deploy QUIC with that code. I think we need
> to move with some urgency, even if we don't change everything about QUIC to
> make it perfect, so that we can start getting IETF QUIC deployments out
> there. Specifically, I think we should:
> 1. work out the wire-visible invariants and finalize all of those for the
> second impl draft. We know that there are some middleboxes that already have
> classifiers for gQUIC, and we need to move quickly and push IETF-QUIC so we
> can test that IETF-QUIC is deployable. I fear that the longer we take, the
> more widespread gQUIC ossification will be.
> 2. allow impls to make serious progress towards a basic HTTP mapping over
> QUIC. We can punt on header compression (QPACK/QCRAM), but perhaps test a
> basic HTTP request-response over QUIC. We can still punt
> performance-oriented things such as full loss recovery and congestion
> control to later. This forces us to try and finalize the HTTP mapping
> details, which is a good thing, IMO.

I agree with Jana.

If we can have some basic HTTP mapping (it can be as basic as using
HTTP/1.0 over each stream), we can use that to test how the IETF
version of QUIC performs well in the field, by comparing its
performance to HTTP over TCP.

>
> On Thu, Jun 22, 2017 at 10:07 AM, Lucas Pardue <[e-mail]>
> wrote:
>>
>> I don’t feel I came away from the Paris Interim with a clear idea of the
>> approach to the second implementation draft. There was a lot of discussion
>> around whether bugfixes in new I-D drafts (that address issues identified in
>> the first implementation draft) would contribute to a first.1 implementation
>> draft (all the way up to first.N) or if they would be put into the second.
>>
>>
>>
>> Side note: Personally, I don’t particularly like the terminology of first,
>> second etc for the reason that it gets hard to rev/iterate on a particular
>> one. However, perhaps it was purposely chosen to disambiguate from the I-D
>> versions?
>>
>>
>>
>> The strawman suggests to me that the direction is to lump both fixes and
>> new features into the second implementation draft. I don’t necessarily have
>> an argument against that but think it would help to clearly identify where
>> things have been fixed, changed completely, been overtaken by other changes
>> etc. Understandably it is too early to do that at this stage.
>>
>>
>>
>> Finally, being super picky, the second implementation doesn’t seem to
>> cover non-critical shortcomings
>>
>>
>>
>> Regards
>>
>> Lucas
>>
>>
>>
>> From: QUIC [mailto:[e-mail]] On Behalf Of Jana Iyengar
>> Sent: 21 June 2017 22:23
>> To: Martin Duke <[e-mail]>
>> Cc: IETF QUIC WG <[e-mail]>
>> Subject: Re: Second Implementation Draft Guidelines
>>
>>
>>
>> This is a great start, thanks for getting it going.
>>
>> Just one thought: You may want to explicitly "include" fixed-time
>> RTO-recovery. It appears right now as a side note in what's not included.
>>
>>
>>
>> On Wed, Jun 21, 2017 at 2:11 PM, Martin Duke <[e-mail]>
>> wrote:
>>
>> All,
>>
>>
>>
>> As promised, I've created a set of guidelines for what should be in the
>> Second Implementation draft. If deadlines hold, I believe we will actually
>> start implementing this draft after Seattle in October.
>>
>>
>>
>> Once we've reached reasonable consensus, this should serve as a basis for
>> prioritizing issues to resolve through Seattle.
>>
>>
>>
>> The current version is very much a starting point for discussion. I've
>> presented some items I think are important to include, and others that we
>> could bring in depending on our appetite for work. The final version will
>> simply have "Must Include" and "should not include".
>>
>>
>> https://github.com/quicwg/base-drafts/wiki/Second-Implementation-Draft
>>
>>
>>
>> I look forward to your comments.
>>
>>
>>
>> Martin
>>
>>
>
>



-- 
Kazuho Oku