Subject: I-D Action: draft-ietf-quic-transport-04.txt

From: [email-masked]
Date: Tue, 13 Jun 2017 06:43:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC of the IETF.

        Title           : QUIC: A UDP-Based Multiplexed and Secure Transport
        Authors         : Jana Iyengar
                          Martin Thomson
	Filename        : draft-ietf-quic-transport-04.txt
	Pages           : 76
	Date            : 2017-06-13

Abstract:
   This document defines the core of the QUIC transport protocol.  This
   document describes connection establishment, packet format,
   multiplexing and reliability.  Accompanying documents describe the
   cryptographic handshake and loss detection.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-transport-04
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 15:07:36 +0100

Folks, you should see new versions of drafts over the next 24 hours (I
can't approve the other drafts).

Expect our chairs to say something about how this relates to our
implementation targets.

In addition to what we agreed would change in this version, there are
some changes to streams.  The layout of STREAM and RST_STREAM have
changed, and there is a change to the closed state.  I want to explain
the last of these in more detail..

The previous draft was a little inconsistent about the transition of a
stream to the closed state.  Prior to the addition of MAX_STREAM_ID,
we landed a change that made the transition only occur after all data
was received and *acknowledged*.  That was considered necessary to
ensure that stream close was precise and consistent between both
endpoints.

At Jana's request, this version moves back to the state prior to that
change which says that data only needs to be *sent*.  As I understand
it, Google's implementation removes stream state once the last byte is
sent for the first time, and that retransmissions are managed at a
connection-level.  So this version gives implementations more
flexibility in how they manage the state of streams.  With
MAX_STREAM_ID, a crisp close for streams is not critical, so we can
afford that flexibility.  And it's not clear to me that requiring
acknowledgment would make the transition any more precise than what we
have now given the need to retransmit acknowledgments.

I opened https://github.com/quicwg/base-drafts/issues/628 to track this.