From nobody Mon Oct 3 00:05:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C4812B023; Mon, 3 Oct 2016 00:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD0pPo9zcoPm; Mon, 3 Oct 2016 00:05:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E6712B01D; Mon, 3 Oct 2016 00:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11413; q=dns/txt; s=iport; t=1475478327; x=1476687927; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=E4VPWRGZQQuqZnm/vtm41ehgUMudAMaf+WiPM5J3uiI=; b=Vx+YE6ZTf4tNj2wvCWMWA3moAwSNZ+JiRskCcjWUaJNL4T25vVa/OxXS GHHaM6RgrCbD9gn8yqCH+5krIo7UmYFQ7ePKcsJCTTKM+9/e3wi9PI8QN QznwfHmyIe3S9MSyySfP7+xYb3QSYG5CLpAQsrF3jLyCmBHzJ+UMYgxdl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgB7AvJX/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz0BAQEBAXUqUo0yln6HWIc5gwOCD4IGJIV6AoIUFAECAQEBAQEBAV4?= =?us-ascii?q?nhGIBAQQjVhALGCcDAgIhJREGAQwGAgEBiC8DFw6ufohvDYNOAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWGOIF9gliCR4FPEQGDIIJaBYg3i2mFIzWGJ4ZKgwCBboR?= =?us-ascii?q?mgxSGCohdQYNQg34eNoUOPDSGDIIgAQEB?= X-IronPort-AV: E=Sophos;i="5.31,288,1473120000"; d="scan'208,217";a="648941050" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 07:05:24 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9375NAS018906; Mon, 3 Oct 2016 07:05:23 GMT To: Spencer Dawkins at IETF , Alexey Melnikov References: <147511356498.16656.1267049373241696647.idtracker@ietfa.amsl.com> <2097D6C6-E7C4-4E6E-A5CB-4DD612198011@fastmail.fm> From: Benoit Claise Message-ID: <916b677e-28ff-7d47-09ea-9aa5049f4fc8@cisco.com> Date: Mon, 3 Oct 2016 09:05:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------047B323692FBFD9C1F56B237" Archived-At: Cc: quic@ietf.org, Alissa Cooper , The IESG Subject: Re: [QUIC] Alissa Cooper's Yes on charter-ietf-quic-00-08: (with COMMENT) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 07:05:29 -0000 This is a multi-part message in MIME format. --------------047B323692FBFD9C1F56B237 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/29/2016 2:59 PM, Spencer Dawkins at IETF wrote: > Dear IESG, > > On Wed, Sep 28, 2016 at 11:21 PM, Alexey Melnikov > > wrote: > > > On 29 Sep 2016, at 03:54, Spencer Dawkins at IETF > > wrote: > >> Hi, Alissa, >> >> On Wed, Sep 28, 2016 at 8:46 PM, Alissa Cooper > > wrote: >> >> Alissa Cooper has entered the following ballot position for >> charter-ietf-quic-00-08: Yes >> >> When responding, please keep the subject line intact and >> reply to all >> email addresses included in the To and CC lines. (Feel free >> to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/charter-ietf-quic/ >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> "The QUIC >> protocol need not be defined to enable each of these >> abilities, or >> enable them in the same way as they are enabled by TCP when used >> with TLS 1.3, but the working group must consider the impact >> of the >> protocol on network management practices, in line with RFC 7258." >> >> The way this is phrased makes it sound like RFC 7258 is about >> protocol >> impact on network management, which isn't the case. I would >> suggest >> dropping "in line with RFC 7258." Alternatively, you could >> say something >> like: >> >> "The QUIC >> protocol need not be defined to enable each of these >> abilities, or >> enable them in the same way as they are enabled by TCP when used >> with TLS 1.3, but the working group must consider the impact >> of the >> protocol on network management practices, reflecting the tensions >> described in RFC 7258." >> >> >> I like your second alternative better. > > Having slept on this, I like your second alternative even better this > morning. I made the change, resulting in version 00-09. > > Thanks for the text suggestion, Alissa. *I* knew what I meant, but the > new text makes that clearer. Fine with me, from the "network management practices" point of view. Regards, Benoit > > Spencer > > +1. >> I'll see if anyone else has thoughts about this, before we >> approve and announce. >> >> Thank you for the suggestion. >> >> Spencer > > --------------047B323692FBFD9C1F56B237 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/29/2016 2:59 PM, Spencer Dawkins at IETF wrote:
Dear IESG,

On Wed, Sep 28, 2016 at 11:21 PM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On 29 Sep 2016, at 03:54, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Alissa,

On Wed, Sep 28, 2016 at 8:46 PM, Alissa Cooper <alissa@cooperw.in> wrote:
Alissa Cooper has entered the following ballot position for
charter-ietf-quic-00-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-quic/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, in line with RFC 7258."

The way this is phrased makes it sound like RFC 7258 is about protocol
impact on network management, which isn't the case. I would suggest
dropping "in line with RFC 7258." Alternatively, you could say something
like:

"The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions
described in RFC 7258."

I like your second alternative better.
Having slept on this, I like your second alternative even better this morning. I made the change, resulting in version 00-09.

Thanks for the text suggestion, Alissa. *I* knew what I meant, but the new text makes that clearer.
Fine with me, from the "network management practices" point of view.

Regards, Benoit

Spencer
 
+1.
I'll see if anyone else has thoughts about this, before we approve and announce.

Thank you for the suggestion.

Spencer 


--------------047B323692FBFD9C1F56B237-- From nobody Tue Oct 4 09:39:06 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3072129624; Tue, 4 Oct 2016 09:35:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147559890992.12943.15443915895845797074.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2016 09:35:09 -0700 Archived-At: X-Mailman-Approved-At: Tue, 04 Oct 2016 09:38:50 -0700 Cc: quic@ietf.org, The IESG , quic-chairs@ietf.org Subject: [QUIC] WG Action: Formed QUIC (quic) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:35:10 -0000 A new IETF WG has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. QUIC (quic) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Lars Eggert Mark Nottingham Assigned Area Director: Spencer Dawkins Transport Area Directors: Spencer Dawkins Mirja Kühlewind Mailing list: Address: quic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience, and generalizing the design described in draft-hamilton-quic-transport-protocol, draft-iyengar-quic-loss-recovery, draft-shade-quic-http2-mapping, and draft-thomson-quic-tls. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, version negotiation, and options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area will describe mappings between specific application protocols and the transport facilities of QUIC. The first mapping will be a description of HTTP/2 semantics using QUIC, specifically with the goal of minimizing web latency using QUIC. This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification. Upon completion of that mapping, additional protocols may be added by updating this charter to include them. The fourth focus area will extend core protocol facilities to enable multipath capabilities for connection migration between paths and load sharing across multiple paths. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. Extensions that will support partial reliability, and negotiation and use of Forward Error Correction schemes, are out of scope in this version of the working group charter. Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP/2. In order to achieve the milestones set out below, the group expects to make extensive use of interim meetings, especially in its first year. Milestones: Feb 2017 - Working group adoption of Core Protocol document Feb 2017 - Working group adoption of Loss detection and Congestion Control document Feb 2017 - Working group adoption of TLS 1.3 mapping document Feb 2017 - Working group adoption of HTTP/2 mapping document Feb 2017 - Working group adoption of QUIC Applicability and Manageability Statement Nov 2017 - Working group adoption of Multipath extension document Mar 2018 - Core Protocol document to IESG Mar 2018 - Loss detection and Congestion Control document to IESG Mar 2018 - TLS 1.3 Mapping document to IESG Nov 2018 - HTTP/2 mapping document to IESG Nov 2018 - QUIC Applicability and Manageability Statement to IESG May 2019 - Multipath extension document to IESG From nobody Wed Oct 5 06:34:51 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9E1296F7; Wed, 5 Oct 2016 06:34:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147567449046.21468.8653289097308354432.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 06:34:50 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - New Meeting Session Request for IETF 97 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:34:50 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: TSVAREA, SAAG, TLS, HTTPBIS, WEBPUSH, RTCWEB, ACME, DISPATCH, MAPRG, TSVWG, ICCRG, TCPM, TCPINC, MPTCP, TAPS, T2TRG, IANAPLAN, ARTAREA Special Requests: If the schedule is tight, this could go in a 2-hour slot. --------------------------------------------------------- From nobody Thu Oct 6 02:37:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3032D12993B for ; Thu, 6 Oct 2016 02:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZZ1vwdGaIRV for ; Thu, 6 Oct 2016 02:37:24 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FE9129832 for ; Thu, 6 Oct 2016 02:37:24 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f193so278794356wmg.0 for ; Thu, 06 Oct 2016 02:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=zmcOX5FJg2/dpD7DZ5UyNfhjEPFvSQM7ZMIgkpeA5uA=; b=CH0ThsA40fQ4VN7Uwvr1LhnkPBM9O1AFvgMwP3DInSIric4jfmbKCFvCqsFI0Zn3Bk 1YI/2Eqlauc4gIrHoOiTP1ejfm3ojeQIQ9BOGjty7JUhcFMfAZMXdRqS4q1VT8PfMD4I 9DZb+5DvhXpEJgtaNbv/E7zOQ8CPQtyazy9ijgwrVJt+H+LWSSjQLoO25jKc1IR+qivw geVcJm+2o1/Qy6DDpzI+5lo2jF/OTj9DyNmo2WlWA4THkJaYsoeyb24Zlhy/YpXWRuyG 7pnwbmyZM6MmjJa35bE+R5jxf4n8gREBEK8ZmLfx04wWqQnP9rxIWXZwFjTaPFAHCeSw eQhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=zmcOX5FJg2/dpD7DZ5UyNfhjEPFvSQM7ZMIgkpeA5uA=; b=fljOdK5Ph4zydE83RciazZlipM0Ke3g82+hJj0N7i3IUPkFvG50IS1MQhd6Rr0cfG/ eVIsIL4q1PQ7Rg6Afn18zE9eWf6fXQskSe4D03eNGK2v6qDgoaF2wc2i/AhYmSmhWQsR 3NSIhX0ZtfXPH73S3+jtrW2gyf9Swmf+Fmf93x2XPoEss/gwgBYBLBvFhc9oSi9rkW1k Yogb7my6DyZG+HaSxCWhCHROB+kdwVhQ9pFmrxiPcbUe7abcBmW3HkbLeDWoVwRlZzG+ OZwXF/7l+Ety/PXpLs51UTXaSXTSeQhS+0hmjGsJYiBrIZtoCBvW6Fpbr+KINKfa+LiR CzuQ== X-Gm-Message-State: AA6/9RmW/lINq5wlHsdslN0zImX5WSRSUH5z0CzO2gtBQD3XkF62drqJPeveNPWTXYbT/84O X-Received: by 10.194.87.7 with SMTP id t7mr4233308wjz.196.1475746642835; Thu, 06 Oct 2016 02:37:22 -0700 (PDT) Received: from Macintosh-6.local ([163.117.139.247]) by smtp.gmail.com with ESMTPSA id vs7sm13469807wjb.10.2016.10.06.02.37.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Oct 2016 02:37:21 -0700 (PDT) From: marcelo bagnulo braun To: quic@ietf.org, draft-hamilton-quic-transport-protocol@ietf.org Message-ID: Date: Thu, 6 Oct 2016 11:37:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [QUIC] about draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 09:37:28 -0000 Hi, Thanks for the document. I have been reading draft-hamilton-quic-transport-protocol-00 and I find it not easy to read, probably because it is an early version and mostly because of my own limitations. I attach a few comments and questions regarding the draft. Hope you find them useful. Section 3.5 on Stream and Connection Flow control. Is the offset announced for the connection the sum of the offsets announced for each of the stream of that connection? If so, it seems redundant to announce both of them, no? If it is not, I am uncertain how this would work. If the connection one is larger than the sum of the streams one, I am not sure how can the sender use the remaining buffer, since it cannot allocate it any existing stream. Is this meant to the be used for new streams? If the sum of the streams one is higher than the connection buffer, then i guess the sender needs to to a double check, first for available rcv window in the stream and then available rcv window in the connection. Not sure what is the gain of having both. Maybe it is worthwhile making explicit in this section why this is useful? Section 3.7 on Resilience to NAT Rebinding. I assume that the same mechanisms that allow the connection to survive a nat rebinding would be also useful to support some simple forms of mobility? I mean, probably these mechanisms are enough to support the client changing IP address (for instance when doing a handover from cellular to wifi)? I guess they are not enough to support more complex mobility scenarios, such as simultaneous movement of both endpoints, but in any case, it may be worthwhile mentioning this mobility support in this section? Section 4.1 on Version Negotiation I understand that during version negotiation, the following information is exchanged: version, version flag, connection ID, and in some cases the server's supported versions. I understand that all this information is exchanged before the crypto handshake, so it is exchange in clear text and without authentication. Since in section 3.6 it is claimed that packets are always authenticated, I guess we have a (mild) contradiction here (i understand you verify this later on once the crypto has been exchanged). In any case, maybe it is worthwhile to explicitly state in this section that this information is exchanged in plain text and non authenticated. Also, the last paragraph of this section states that there are other transport parameters exchanged in the connection establishment. I assume that those are exchanged after the crypto, so they are encrypted and authenticated? Is there any other transport parameter exchanged in clear text? Probably it would be useful to make this explicit? In section 4.2.1.2 on Required Transport Parameters. One thing I am missing here (probably because suffering a TCP bias) is the initial packet sequence number to be used in the connection. Do you always use 0 as initial PSN? If so, this is because you assume that the crypto mechanisms established during the crypto handshake will prevent packet form previous connections to re-emerge later on and be confused for packets in the new connection? If this is the case, maybe you should state it explicitly in section 4.2.3? However, from reading section 4.2.2 it seems that multiple connections between two endpoints can reuse the same crypto material, is that the case? In this case, does each connection uses 0 as initial PSN? How can you guarantee in this case that old packets with same PSN will no re surface and appear as packet of a new connection, since they can be using the same PSN? Section 4.2.2 on Proof of Source Address Ownership. I understand that the STK provides less protection than a reachability check at the beginning of each connection, correct? I mean, the STK proves that the client was once in that location and it can later leave the location and because it still has the STK, it can, by spoofing the source address, pretend to still be there, since only the STK is enough to pass this test. This means that for instance, an attacker can download a large file by simply sending paced ACKs to any location it once was (given that the PSN initial number is always 0, it doesnt even needs to guess the PSNs), correct? Maybe this is acceptable, but maybe it is worthwhile stating it in the security considerations section? Section 4.2.3 on Crypto Handshake Protocol features In the bullet about Connection establishment in 0-RTT, it requires 0-RTT connection establishment for subsequent connections between the same two endpoints, in the subsequent connections, the client and server roles must be preserved or they can be changed? I mean, suppose that host A initiates a quic connection to host b. Does this condition requires that a future connection (with the same ports) initiated from host b to host A should be established in 0-RTT? I think this should be made explicitly because mixed with the STK, I believe it changes the threat model significantly. Nit: the paragraph on the bullet on Server Config Update is truncated. Section 5.1 on Life of a stream. It states that quic accommodates the possibility of out-of-order delivery. Do you mean out of order delivery within the same stream or across streams? clarify? I understand that the creation of a stream is very lightweight and a new stream is established by simply data with a new stream id, correct? I also understand that the initial stream sequence number is always 0, correct? (I mean, the offset of the current data to the beginning of the streams is included, and the initial packet has offset 0). So, similar to the question i posed about the initial PSN, how does quic prevent old packets to reappear and be confused as being part of the new stream while they were part of an older stream? It cannot be done using the offset, since for all connection it starts in 0. I guess it could be done using the PSN, but then the receiver needs to check that all PSN of packets for a new stream are higher than the PSN of the packet that terminated the older stream, is this the proposed approach? Probably it is worthwhile clarifying what are the means that quic deals with old packets re emerging after the connection/stream has ended, given that it does not relies on the sequence number to do so, afaict. In particular, in section 5.1.1 it states that a stream is open by sending or receiving a data packet with that particular stream ID. I assume that the data packet MUST contain a 0 offset to create the new stream? is this correct? Section 5.2 on Stream Identifiers. I guess you should reserve a range of identifiers for future use, in case other "special" streams are needed in the future? Section 5.4 on Sending and Receiving data. Is the initial offset for the data packet sent on a stream set to zero? If this is the case, would be good to state it. Section 6. on Packetization and reliability. What is the initial PSN in a given connection? State it explicitly. It is stated that a sender MAY wait for a short period of time to bundle multiple frames. I guess it would be useful to provide guidance on what you consider a short period of time. Is that 500ms as in the delayed acks or are you thinking much less? Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not be retransmitted, but all other frames must be retransmitted. This implies than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i am not sure if this makes sense. I mean, maybe there were other WINDOW_UPDATE frames than were sent after this one so retransmitting this one probably doesnt make sense, since the information it contains may be stalled, no? I still dont understand why having both connection and stream flow control is useful. I would assume that only stream flow control would be useful. Or having one or the other in a given connection, but i fail to understand why is useful to have both of them simultaneously in the same connection. Section 6 states Regular QUIC Packets are "containers" of frames; a packet is never retransmitted whole, but frames in a lost packet may be rebundled and transmitted in a subsequent packet as necessary. So, let me see if i understand this. This means that if the sender sends packet with PSN 5, and if the packet is lost (i.e. there is a timeout for that packet), the packet with PSN 5 NOT retransmitted. the frames in the packet with PSN 5 are then retransmitted in other packets with other PSN (other than 5). If this correct? This means that there will be holes in the sequence of packets received by the receiver i.e. any packet that get's lost, is simply lost and will never be received by the receiver. Am i understanding this correctly? A receiver acknowledges receipt of a received packet by sending one or more ACK frames containing the PSN of the received packet. To avoid perpetual acking between endpoints, a receiver MUST NOT generate an ack in response to every packet containing only ACK frames. Does this means that ACKs transmission is unreliable, correct? Since packets are never retransmitted with the same PSN, this basically means that if an ACK is lost, then the sender gives up on this packet and eventually will retransmit the data in other packets with a different PSN, correct? Section 7.1.1 on Mid-stream RST_STREAM After a RST, when the stream identifier can be reused? probably some guidance about this would be useful. Section 7.1.4. Is the BLOCKED frame reliably transmitted? I assume it is, but, does it make sense? I mean, if a sender sends a blocked frame and it get's lost, but after that the receiver open the window, then retransmitting the BLOCKED frame is not useful (doesnt harm neither i guess) OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly window syndrome? I guess we could do what TCP does i.e. periodically transmit the BLOCKED msg when there is no window (which is different from reliably transmitting the BLOCKED message, since it is periodically sent only when the window is 0) Section 8 on connection termination After a connection close, does the same stream identifier can be reused for a new connection? shouldnt also be a hold time to avoid delayed packets of the old connection? How much time would be safe? Section 10.4 I understand ACK frames are unreliably transmitted. Also, I understand that packets are never retransmitted with the same PSN. So, if a packet is lost, there will be a hole in the receiver for that PSN and the data will be sent in other packets with othew PSN. Hence, you cannot have cummulative acks. So, this means that it is possible for a packet to be received by the receiver but that all the ACKs for that packet to be lost on the way back and then the sender will timeout and retransmit, right? (I guess that is ok, since data will be retransmitted in other packets) Let me verify that I understand when a stop waiting frames should be sent by the sender. I guess that a sender should send a given PSN X in a stop waiting frame if all the packet with PSN lower than X have been received or have timed out, correct? Regards, marcelo From nobody Thu Oct 6 10:58:16 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DDA129743; Thu, 6 Oct 2016 10:58:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147577669478.23836.17400234431999044552.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 10:58:14 -0700 Archived-At: Cc: cmorgan@amsl.com, spencerdawkins.ietf@gmail.com, quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] quic - Update to a Meeting Session Request for IETF 97 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 17:58:15 -0000 An update to a meeting session request has just been submitted by Cindy Morgan, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: tsvarea saag tls httpbis dispatch maprg tsvwg iccrg tcpm tcpinc mptcp taps t2trg ianaplan artarea irtfopen Second Priority: webpush rtcweb acme Special Requests: If the schedule is tight, this could go in a 2-hour slot. --------------------------------------------------------- From nobody Thu Oct 6 12:42:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5532129416 for ; Thu, 6 Oct 2016 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3O4g6KTBqEU for ; Thu, 6 Oct 2016 12:42:01 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EACC12940F for ; Thu, 6 Oct 2016 12:42:01 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id p25so27352487uaa.1 for ; Thu, 06 Oct 2016 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RHlKPlVMa1ycV8acW9wpDCSkNo9IYjfANOhFuZLvBUQ=; b=P/19ZKuzdlQaBzzgiDInVJnz1Gu0hippsIz5QPyrUrQ6nf5imwAheugPWFcbT/bbZR OYUu4+u/01MoX6b00Tj+9saLCiS492KKYqyDCJLYbIJIzeAtqAHnBIeYOZbF1H+5THqB /htxKjfHCRpoPq4WuUEc8iDqsISE2Jx7fJm6L/Ec0DhJdWqO4q/HovFfCWBFRxLjXTKt Rfyv/uxQwIuSfH8IORoTOJOyaXDFy9zZ/uqGIFqmF4qZWPSahlOqfudH7v1LbGwkHaEg T5gOb8GA28Tj8bFhtvkzd+zoCBgnFLQidjqt8c6Hvj5V90S0EB6S+ubQDbqZpdQGD+j6 4PJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RHlKPlVMa1ycV8acW9wpDCSkNo9IYjfANOhFuZLvBUQ=; b=LvEdhNNXPdeyJOJqb5DSwq4njY8jstuxagqq/sHgJkoiXmK1YoBxzx83ahxc5XF0pw vjt+DrYnOHMPMg8T5152Lty8Xp0DX8OWIe0zsr11/NEWLxSlv8lY4/ZFPMiDmmkUGV+Q FyL0fSyor3e5F24gwFVjcpMHPi3PsrEOGDhGqhMd55fg2bMt1+fFmQL2cimS0bUybQMh X0VprqJHLiXiFW/7oGgABJPjaISZCfex137oGZgtV4VFrb/T7Zzjvct8kKt1/vs7NOPv smw4ap6oNTTuuGU4AY8U6AO45txBmOwh+l/YQmQj5N+7aR0jdwkMZ2PK1tVtFZ3eTyL5 WmPw== X-Gm-Message-State: AA6/9Rlwwm6sLx8N7E2tU5tDwkdzVd2QHti6ZEucvtmrl7FUtXCHSCwK1czZ7wnuL8q8iOefAH6x3WLs0fWBTV39 X-Received: by 10.176.66.6 with SMTP id i6mr10227730uai.149.1475782920494; Thu, 06 Oct 2016 12:42:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.76.85 with HTTP; Thu, 6 Oct 2016 12:41:59 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 6 Oct 2016 12:41:59 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a114ba8a0be2f7a053e377cc6 Archived-At: Cc: draft-hamilton-quic-transport-protocol@ietf.org, quic@ietf.org Subject: Re: [QUIC] about draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:42:05 -0000 --001a114ba8a0be2f7a053e377cc6 Content-Type: text/plain; charset=UTF-8 Thanks much, Marcelo! There's definitely work to be done on the draft, so comments are very appreciated! I'll be revising the draft soon, so will respond to your detailed comments soon. On Thu, Oct 6, 2016 at 2:37 AM, marcelo bagnulo braun wrote: > Hi, > > > Thanks for the document. I have been reading draft-hamilton-quic-transport-protocol-00 > and I find it not easy to read, probably because it is an early version and > mostly because of my own limitations. > > I attach a few comments and questions regarding the draft. Hope you find > them useful. > > > Section 3.5 on Stream and Connection Flow control. > > Is the offset announced for the connection the sum of the offsets > announced for each of the stream of that connection? > > If so, it seems redundant to announce both of them, no? > > If it is not, I am uncertain how this would work. If the connection one is > larger than the sum of the streams one, I am not sure how can the sender > use the remaining buffer, since it cannot allocate it any existing stream. > Is this meant to the be used for new streams? If the sum of the streams one > is higher than the connection buffer, then i guess the sender needs to to a > double check, first for available rcv window in the stream and then > available rcv window in the connection. Not sure what is the gain of having > both. Maybe it is worthwhile making explicit in this section why this is > useful? > > > Section 3.7 on Resilience to NAT Rebinding. > > I assume that the same mechanisms that allow the connection to survive a > nat rebinding would be also useful to support some simple forms of mobility? > > I mean, probably these mechanisms are enough to support the client > changing IP address (for instance when doing a handover from cellular to > wifi)? > > I guess they are not enough to support more complex mobility scenarios, > such as simultaneous movement of both endpoints, but in any case, it may be > worthwhile mentioning this mobility support in this section? > > > Section 4.1 on Version Negotiation > > I understand that during version negotiation, the following information is > exchanged: version, version flag, connection ID, and in some cases the > server's supported versions. I understand that all this information is > exchanged before the crypto handshake, so it is exchange in clear text and > without authentication. Since in section 3.6 it is claimed that packets are > always authenticated, I guess we have a (mild) contradiction here (i > understand you verify this later on once the crypto has been exchanged). In > any case, maybe it is worthwhile to explicitly state in this section that > this information is exchanged in plain text and non authenticated. Also, > the last paragraph of this section states that there are other transport > parameters exchanged in the connection establishment. I assume that those > are exchanged after the crypto, so they are encrypted and authenticated? Is > there any other transport parameter exchanged in clear text? Probably it > would be useful to make this explicit? > > > In section 4.2.1.2 on Required Transport Parameters. > > One thing I am missing here (probably because suffering a TCP bias) is the > initial packet sequence number to be used in the connection. > > Do you always use 0 as initial PSN? If so, this is because you assume that > the crypto mechanisms established during the crypto handshake will prevent > packet form previous connections to re-emerge later on and be confused for > packets in the new connection? If this is the case, maybe you should state > it explicitly in section 4.2.3? > > However, from reading section 4.2.2 it seems that multiple connections > between two endpoints can reuse the same crypto material, is that the case? > > In this case, does each connection uses 0 as initial PSN? How can you > guarantee in this case that old packets with same PSN will no re surface > and appear as packet of a new connection, since they can be using the same > PSN? > > > Section 4.2.2 on Proof of Source Address Ownership. > > I understand that the STK provides less protection than a reachability > check at the beginning of each connection, correct? > > I mean, the STK proves that the client was once in that location and it > can later leave the location and because it still has the STK, it can, by > spoofing the source address, pretend to still be there, since only the STK > is enough to pass this test. > > This means that for instance, an attacker can download a large file by > simply sending paced ACKs to any location it once was (given that the PSN > initial number is always 0, it doesnt even needs to guess the PSNs), > correct? > > Maybe this is acceptable, but maybe it is worthwhile stating it in the > security considerations section? > > > Section 4.2.3 on Crypto Handshake Protocol features > > In the bullet about Connection establishment in 0-RTT, it requires 0-RTT > connection establishment for subsequent connections between the same two > endpoints, in the subsequent connections, the client and server roles must > be preserved or they can be changed? > > I mean, suppose that host A initiates a quic connection to host b. Does > this condition requires that a future connection (with the same ports) > initiated from host b to host A should be established in 0-RTT? > > I think this should be made explicitly because mixed with the STK, I > believe it changes the threat model significantly. > > Nit: the paragraph on the bullet on Server Config Update is truncated. > > > Section 5.1 on Life of a stream. > > It states that quic accommodates the possibility of out-of-order delivery. > Do you mean out of order delivery within the same stream or across streams? > clarify? > > I understand that the creation of a stream is very lightweight and a new > stream is established by simply data with a new stream id, correct? > > I also understand that the initial stream sequence number is always 0, > correct? (I mean, the offset of the current data to the beginning of the > streams is included, and the initial packet has offset 0). > > So, similar to the question i posed about the initial PSN, how does quic > prevent old packets to reappear and be confused as being part of the new > stream while they were part of an older stream? It cannot be done using the > offset, since for all connection it starts in 0. I guess it could be done > using the PSN, but then the receiver needs to check that all PSN of packets > for a new stream are higher than the PSN of the packet that terminated the > older stream, is this the proposed approach? > > Probably it is worthwhile clarifying what are the means that quic deals > with old packets re emerging after the connection/stream has ended, given > that it does not relies on the sequence number to do so, afaict. > > In particular, in section 5.1.1 it states that a stream is open by sending > or receiving a data packet with that particular stream ID. I assume that > the data packet MUST contain a 0 offset to create the new stream? is this > correct? > > > Section 5.2 on Stream Identifiers. > > I guess you should reserve a range of identifiers for future use, in case > other "special" streams are needed in the future? > > > Section 5.4 on Sending and Receiving data. > > Is the initial offset for the data packet sent on a stream set to zero? If > this is the case, would be good to state it. > > > Section 6. on Packetization and reliability. What is the initial PSN in a > given connection? State it explicitly. > > It is stated that a sender MAY wait for a short period of time to bundle > multiple frames. I guess it would be useful to provide guidance on what you > consider a short period of time. Is that 500ms as in the delayed acks or > are you thinking much less? > > Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST > not be retransmitted, but all other frames must be retransmitted. This > implies than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, > but i am not sure if this makes sense. I mean, maybe there were other > WINDOW_UPDATE frames than were sent after this one so retransmitting this > one probably doesnt make sense, since the information it contains may be > stalled, no? > > I still dont understand why having both connection and stream flow control > is useful. I would assume that only stream flow control would be useful. Or > having one or the other in a given connection, but i fail to understand why > is useful to have both of them simultaneously in the same connection. > > > Section 6 states > > Regular QUIC Packets are "containers" of frames; a packet is never > retransmitted whole, but frames in a lost packet may be rebundled and > transmitted in a subsequent packet as necessary. > > So, let me see if i understand this. > > This means that if the sender sends packet with PSN 5, and if the packet > is lost (i.e. there is a timeout for that packet), the packet with PSN 5 > NOT retransmitted. the frames in the packet with PSN 5 are then > retransmitted in other packets with other PSN (other than 5). If this > correct? > > This means that there will be holes in the sequence of packets received by > the receiver i.e. any packet that get's lost, is simply lost and will never > be received by the receiver. Am i understanding this correctly? > > A receiver acknowledges receipt of a received packet by sending one > or more ACK frames containing the PSN of the received packet. To > avoid perpetual acking between endpoints, a receiver MUST NOT > generate an ack in response to every packet containing only ACK > frames. > > Does this means that ACKs transmission is unreliable, correct? > > Since packets are never retransmitted with the same PSN, this basically > means that if an ACK is lost, then the sender gives up on this packet and > eventually will retransmit the data in other packets with a different PSN, > correct? > > > Section 7.1.1 on Mid-stream RST_STREAM > > After a RST, when the stream identifier can be reused? probably some > guidance about this would be useful. > > > Section 7.1.4. > > Is the BLOCKED frame reliably transmitted? I assume it is, but, does it > make sense? > > I mean, if a sender sends a blocked frame and it get's lost, but after > that the receiver open the window, then retransmitting the BLOCKED frame is > not useful (doesnt harm neither i guess) > > OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly > window syndrome? > > I guess we could do what TCP does i.e. periodically transmit the BLOCKED > msg when there is no window (which is different from reliably transmitting > the BLOCKED message, since it is periodically sent only when the window is > 0) > > > Section 8 on connection termination > > After a connection close, does the same stream identifier can be reused > for a new connection? shouldnt also be a hold time to avoid delayed packets > of the old connection? How much time would be safe? > > Section 10.4 > > I understand ACK frames are unreliably transmitted. > > Also, I understand that packets are never retransmitted with the same PSN. > So, if a packet is lost, there will be a hole in the receiver for that PSN > and the data will be sent in other packets with othew PSN. Hence, you > cannot have cummulative acks. > > So, this means that it is possible for a packet to be received by the > receiver but that all the ACKs for that packet to be lost on the way back > and then the sender will timeout and retransmit, right? (I guess that is > ok, since data will be retransmitted in other packets) > > Let me verify that I understand when a stop waiting frames should be sent > by the sender. I guess that a sender should send a given PSN X in a stop > waiting frame if all the packet with PSN lower than X have been received or > have timed out, correct? > > Regards, marcelo > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114ba8a0be2f7a053e377cc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks much, Marcelo! There's definitely work to be do= ne on the draft, so comments are very appreciated!
I'll be revising= the draft soon, so will respond to your detailed comments soon.

On Thu, Oct 6, 2= 016 at 2:37 AM, marcelo bagnulo braun <marcelo@it.uc3m.es> = wrote:
Hi,


Thanks for the document. I have been reading draft-hamilton-quic-transport-= protocol-00 and I find it not easy to read, probably because it is an = early version and mostly because of my own limitations.

I attach a few comments and questions regarding the draft. Hope you find th= em useful.


Section 3.5 on Stream and Connection Flow control.

Is the offset announced for the connection the sum of the offsets announced= for each of the stream of that connection?

If so, it seems redundant to announce both of them, no?

If it is not, I am uncertain how this would work. If the connection one is = larger than the sum of the streams one, I am not sure how can the sender us= e the remaining buffer, since it cannot allocate it any existing stream. Is= this meant to the be used for new streams? If the sum of the streams one i= s higher than the connection buffer, then i guess the sender needs to to a = double check, first for available rcv window in the stream and then availab= le rcv window in the connection. Not sure what is the gain of having both. = Maybe it is worthwhile making explicit in this section why this is useful?<= br>

Section 3.7 on Resilience to NAT Rebinding.

I assume that the same mechanisms that allow the connection to survive a na= t rebinding would be also useful to support some simple forms of mobility?<= br>
I mean, probably these mechanisms are enough to support the client changing= IP address (for instance when doing a handover from cellular to wifi)?

I guess they are not enough to support more complex mobility scenarios, suc= h as simultaneous movement of both endpoints, but in any case, it may be wo= rthwhile mentioning this mobility support in this section?


Section 4.1 on Version Negotiation

I understand that during version negotiation, the following information is = exchanged: version, version flag, connection ID, and in some cases the serv= er's supported versions. I understand that all this information is exch= anged before the crypto handshake, so it is exchange in clear text and with= out authentication. Since in section 3.6 it is claimed that packets are alw= ays authenticated, I guess we have a (mild) contradiction here (i understan= d you verify this later on once the crypto has been exchanged). In any case= , maybe it is worthwhile to explicitly state in this section that this info= rmation is exchanged in plain text and non authenticated. Also, the last pa= ragraph of this section states that there are other transport parameters ex= changed in the connection establishment. I assume that those are exchanged = after the crypto, so they are encrypted and authenticated? Is there any oth= er transport parameter exchanged in clear text? Probably it would be useful= to make this explicit?


In section 4.2.1.2 on Required Transport Parameters.

One thing I am missing here (probably because suffering a TCP bias) is the = initial packet sequence number to be used in the connection.

Do you always use 0 as initial PSN? If so, this is because you assume that = the crypto mechanisms established during the crypto handshake will prevent = packet form previous connections to re-emerge later on and be confused for = packets in the new connection? If this is the case, maybe you should state = it explicitly in section 4.2.3?

However, from reading section 4.2.2 it seems that multiple connections betw= een two endpoints can reuse the same crypto material, is that the case?

In this case, does each connection uses 0 as initial PSN? How can you guara= ntee in this case that old packets with same PSN will no re surface and app= ear as packet of a new connection, since they can be using the same PSN?

Section 4.2.2 on Proof of Source Address Ownership.

I understand that the STK provides less protection than a reachability chec= k at the beginning of each connection, correct?

I mean, the STK proves that the client was once in that location and it can= later leave the location and because it still has the STK, it can, by spoo= fing the source address, pretend to still be there, since only the STK is e= nough to pass this test.

This means that for instance, an attacker can download a large file by simp= ly sending paced ACKs to any location it once was (given that the PSN initi= al number is always 0, it doesnt even needs to guess the PSNs), correct?
Maybe this is acceptable, but maybe it is worthwhile stating it in the secu= rity considerations section?


Section 4.2.3 on Crypto Handshake Protocol features

In the bullet about Connection establishment in 0-RTT, it requires 0-RTT co= nnection establishment for subsequent connections between the same two endp= oints, in the subsequent connections, the client and server roles must be p= reserved or they can be changed?

I mean, suppose that host A initiates a quic connection to host b. Does thi= s condition requires that a future connection (with the same ports) initiat= ed from host b to host A should be established in 0-RTT?

I think this should be made explicitly because mixed with the STK, I believ= e it changes the threat model significantly.

Nit: the paragraph on the bullet on Server Config Update is truncated.


Section 5.1 on Life of a stream.

It states that quic accommodates the possibility of out-of-order delivery. = Do you mean out of order delivery within the same stream or across streams?= clarify?

I understand that the creation of a stream is very lightweight and a new st= ream is established by simply data with a new stream id, correct?

I also understand that the initial stream sequence number is always 0, corr= ect? (I mean, the offset of the current data to the beginning of the stream= s is included, and the initial packet has offset 0).

So, similar to the question i posed about the initial PSN, how does quic pr= event old packets to reappear and be confused as being part of the new stre= am while they were part of an older stream? It cannot be done using the off= set, since for all connection it starts in 0. I guess it could be done usin= g the PSN, but then the receiver needs to check that all PSN of packets for= a new stream are higher than the PSN of the packet that terminated the old= er stream, is this the proposed approach?

Probably it is worthwhile clarifying what are the means that quic deals wit= h old packets re emerging after the connection/stream has ended, given that= it does not relies on the sequence number to do so, afaict.

In particular, in section 5.1.1 it states that a stream is open by sending = or receiving a data packet with that particular stream ID. I assume that th= e data packet MUST contain a 0 offset to create the new stream? is this cor= rect?


Section 5.2 on Stream Identifiers.

I guess you should reserve a range of identifiers for future use, in case o= ther "special" streams are needed in the future?


Section 5.4 on Sending and Receiving data.

Is the initial offset for the data packet sent on a stream set to zero? If = this is the case, would be good to state it.


Section 6. on Packetization and reliability. What is the initial PSN in a g= iven connection? State it explicitly.

It is stated that a sender MAY wait for a short period of time to bundle mu= ltiple frames. I guess it would be useful to provide guidance on what you c= onsider a short period of time. Is that 500ms as in the delayed acks or are= you thinking much less?

Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not= be retransmitted, but all other frames must be retransmitted. This implies= than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i am= not sure if this makes sense. I mean, maybe there were other WINDOW_UPDATE= frames than were sent after this one so retransmitting this one probably d= oesnt make sense, since the information it contains may be stalled, no?

I still dont understand why having both connection and stream flow control = is useful. I would assume that only stream flow control would be useful. Or= having one or the other in a given connection, but i fail to understand wh= y is useful to have both of them simultaneously in the same connection.


Section 6 states

=C2=A0 =C2=A0Regular QUIC Packets are "containers" of frames; a p= acket is never
=C2=A0 =C2=A0retransmitted whole, but frames in a lost packet may be rebund= led and
=C2=A0 =C2=A0transmitted in a subsequent packet as necessary.

So, let me see if i understand this.

This means that if the sender sends packet with PSN 5, and if the packet is= lost (i.e. there is a timeout for that packet), the packet with PSN 5 NOT = retransmitted. the frames in the packet with PSN 5 are then retransmitted i= n other packets with other PSN (other than 5). If this correct?

This means that there will be holes in the sequence of packets received by = the receiver i.e. any packet that get's lost, is simply lost and will n= ever be received by the receiver. Am i understanding this correctly?

=C2=A0 =C2=A0A receiver acknowledges receipt of a received packet by sendin= g one
=C2=A0 =C2=A0or more ACK frames containing the PSN of the received packet.= =C2=A0 To
=C2=A0 =C2=A0avoid perpetual acking between endpoints, a receiver MUST NOT<= br> =C2=A0 =C2=A0generate an ack in response to every packet containing only AC= K
=C2=A0 =C2=A0frames.

Does this means that ACKs transmission is unreliable, correct?

Since packets are never retransmitted with the same PSN, this basically mea= ns that if an ACK is lost, then the sender gives up on this packet and even= tually will retransmit the data in other packets with a different PSN, corr= ect?


Section 7.1.1 on Mid-stream RST_STREAM

After a RST, when the stream identifier can be reused? probably some guidan= ce about this would be useful.


Section 7.1.4.

Is the BLOCKED frame reliably transmitted? I assume it is, but, does it mak= e sense?

I mean, if a sender sends a blocked frame and it get's lost, but after = that the receiver open the window, then retransmitting the BLOCKED frame is= not useful (doesnt harm neither i guess)

OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly= window syndrome?

I guess we could do what TCP does i.e. periodically transmit the BLOCKED ms= g when there is no window (which is different from reliably transmitting th= e BLOCKED message, since it is periodically sent only when the window is 0)=


Section 8 on connection termination

After a connection close, does the same stream identifier can be reused for= a new connection? shouldnt also be a hold time to avoid delayed packets of= the old connection? How much time would be safe?

Section 10.4

I understand ACK frames are unreliably transmitted.

Also, I understand that packets are never retransmitted with the same PSN. = So, if a packet is lost, there will be a hole in the receiver for that PSN = and the data will be sent in other packets with othew PSN. Hence, you canno= t have cummulative acks.

So, this means that it is possible for a packet to be received by the recei= ver but that all the ACKs for that packet to be lost on the way back and th= en the sender will timeout and retransmit, right? (I guess that is ok, sinc= e data will be retransmitted in other packets)

Let me verify that I understand when a stop waiting frames should be sent b= y the sender. I guess that a sender should send a given PSN X in a stop wai= ting frame if all the packet with PSN lower than X have been received or ha= ve timed out, correct?

Regards, marcelo

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a114ba8a0be2f7a053e377cc6-- From nobody Thu Oct 6 23:05:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CEF1294A0 for ; Thu, 6 Oct 2016 23:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VTGzaXO4l_c for ; Thu, 6 Oct 2016 23:05:23 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D1E1293F5 for ; Thu, 6 Oct 2016 23:05:22 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f193so12334478wmg.0 for ; Thu, 06 Oct 2016 23:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=GSOTrlBMQc16GlGE04WoIfdDShgjZDQsz2dAKriGvRQ=; b=C5W4Gc46RS34x09JStbMxXkpvvmtEwDeHOyzdMaC/tuO6CmMXiXqrycyjVQLOqxxdS kpkJRcwOROq4vdtWcosJy9fjjkfqwS0DmVQpzajZKgCPtMWU9o8ThThZb0J8d5GVVKes z5my6Zl5Jd06xAOAEPNa9c0DWMd2Oyv3k+i031gIWlHGQjfaEbA43A+qYb6mzzor3txd nCaUiKF5QZfqF22mnuIXiGcrNXS/Tq0Qe6rc3LA5OrK6H2yqScjr2GFT8N6+M4vSQOE7 4brPSHGGQ54M9mKqEpgHHw5K0Afw+AEWXyX/IzJ/8ScprXJHIGTw1hx4Wa5JWOffAuKf LIYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=GSOTrlBMQc16GlGE04WoIfdDShgjZDQsz2dAKriGvRQ=; b=lQ/f9pIIIGsU3CSvaCvGDHz9lnMkTFlhph+sJOd60eTwy2AGcjedzDuFTA1PtJ+wOv KNdR8ZImrvyPfVkEFCpsZBtIG1U23CqknyDVkgN3ajYDZJb4dJs+2Cgpt6q/SE7fKNFw PYRsaBqTS7bJPqbrEVLNd3spklr8Vx7PT3ArXmQXPGTb0fWqEuzTI5kPoQq/LTW+cVgS k0stBRnESJT01r8k6SzpT0Uqm//vYGUi6xws9+ZaeNtdXeilg7K1y+Hs3h8QAzjQefOK n0zozUQ0tzgE42qOuvu05uIpxY4PXNPEhkZLNRHgjtY5xwClq7w8KGDCitS+OdSo3tpl /dSA== X-Gm-Message-State: AA6/9Rln+M77ZSGAAASAfDy+p1pxHjdC63xziwAOPcTRsGamGdK7pqWOGFJTeeZkYYPdUqio X-Received: by 10.28.32.198 with SMTP id g189mr25462912wmg.130.1475820320999; Thu, 06 Oct 2016 23:05:20 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:c44f:9ab0:fa07:8c91]) by smtp.gmail.com with ESMTPSA id e187sm1280832wma.21.2016.10.06.23.05.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Oct 2016 23:05:20 -0700 (PDT) From: marcelo bagnulo braun To: quic@ietf.org, draft-iyengar-quic-loss-recovery@ietf.org Message-ID: <73a98c3a-aaad-e2d2-3932-1f1eed60ae16@it.uc3m.es> Date: Fri, 7 Oct 2016 08:05:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [QUIC] About loss detection and recovery in draft-iyengar-quic-loss-recovery-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 06:05:25 -0000 Hi, So, i have been trying to understand the packet loss detection and retransmission schemes for quic, described in draft-iyengar-quic-loss-recovery-00. I had a few difficulties to understand how this works, based on the description in the draft. I include below what i think i understood, let me know if i got this right. Section 2 and 3 mention the retransmission of lost packets, but if i understood it correctly, i think the draft would benefit from dropping the concept of retransmitted packet. I mean, I dont think there is such a thing as a retransmitted packet. What quic retransmits is the data within packets that were detected as lost, but the packet is not retransmitted. For starters, the packet containing the retransmitted data has a different PSN. But also, the content of the packet may be different as some frames are not to be retransmitted. Moreover, if eventually some form of priority is implemented, i would guess that data with higher priority would be retransmitted earlier than data with lower priority. I think such flexibility would be useful. Let me see if I understand the overall framework for loss detection and retransmission for quic. I think that quic detect packet loss, but retransmits data (that was sent in packets) so it probably possible to decouple the loss detection from the retransmission. I understand that all data (control and application data) that is reliably transmitted is transmitted within a stream. Other data that is not transmitted within a given stream (like ACKs) is not reliably transmitted. Is this correct? If so, it may be worth stating it as a design principle, so people know that if they want to include control information such as other options to be reliably transmitted, they should do it within a stream. So, if a sender has M ongoing streams, then it has M+1 sliding windows, i.e. one for each stream plus one for the packets at the connection level. Let's call the packet one, the packet window and the other the stream n window. The packet window is in packets, while the stream windows are in bytes. The packet window has the following types of packets: packets acked, non-acked packets and lost packets. The left side of the window moves to packet number n when all packets with packet number lower than n are marked as acked or as lost. In other words, the left side of the window is the non-acked packet with lowest packet number. This corresponds to the "least unacked" packet mentioned in the draft. Each stream window has the following types of bytes. bytes acked, bytes non-acked, bytes awaiting for transmission. Bytes non-acked are bytes that are contained in packets on flight. Bytes awaiting for transmission are bytes that either have not been sent yet or bytes that have been sent in packets that have been determined as lost. Whenever a packet is acked, the bytes in each stream window corresponding to the data of each stream included in the acked packet are marked as acked. Whenever a packet is determined as lost, the bytes in each stream window corresponding to the data of that stream included in the packet are marked as bytes awaiting for transmission. Whenever a new packet is transmitted, the bytes in each stream window included in the packet are marked as non-acked. Packet loss detection only operates using the packet window. So, each non-acked packet has an associated timer that when it times out, the packet is marked as lost. You can define any other mechanisms to detect packet loss only operating in this window, i believe. Packet transmission otoh, needs to get data from the different stream windows, probably using the bytes awaiting for transmission with the lowest offset. This would include both the transmission of new data as well as retransmission of old data. Do you think this properly describes the framework of operation for loss detection and retransmission of quic? Regards, marcelo From nobody Fri Oct 7 12:14:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E1120726 for ; Fri, 7 Oct 2016 12:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3INOx85l3zal for ; Fri, 7 Oct 2016 12:14:01 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E640C127735 for ; Fri, 7 Oct 2016 12:14:00 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t192so18103940ywf.0 for ; Fri, 07 Oct 2016 12:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZUXK0om4OzaYbHMqjhJcBNxDjwnRLUy63S4Curwlhbc=; b=d/cBfXdq94Asr6Yzqvk13mWUOIwA2F+orp3Dxs/bVgra3WI7WPaA0nUTrzc8jpVeWS IFN2aXV3Z6jl1TVdgexPCxlcilSPT7uny8Jkq+Qf1PiAxxF3kPoyIA3MGnYkYHha9NoE NDJtk0ZciHlcet4qSZk2FfN6uMQYO56NdXaQVMhVOHhx5n3QFPnm1MJjUm9HwacEMEVQ vpSwQUCoE6ZtvZgAlA0bvVBFpJXSRvQpLWb4LqJZv9K4mVPduqk+GEbsA4W9NqkNuyem uZp3vKNLkXYmrL4xKojHqUNwgXVwETYfTSwWEw/CEAJWwfJiZtVASYZ/o8kenVpQmLs2 P1Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZUXK0om4OzaYbHMqjhJcBNxDjwnRLUy63S4Curwlhbc=; b=L2GlvyT6qMm7Rb3ecyTYPwpvui+if7DZdNSQVVQhN4JNuzNQZAzWxVJcIRsW2HveeV WhM9U1+z10X0mKF/PqNnx3Mvzml8whl+lSzakRT2gLGfg9eimgfaXe8syllq9EXptKwp wxiK6ANF75NEY0HJbwVOwz/TQU9zWXXtU2fedN7vXk6nQG0I2WRKtSXBkNnaiiGWo4H7 z3eHe+BxMDcd9UnUja8od1v6j2yIXLlJfn0C1vATAe/sUext9VmjvmneQ/D4DG/eb1OV E/4NkjHPlONvjTxwwU9MrM2mK+RtmwiuuSAsZlWDfkmJ84s9zilRZCNHLNcDuv3j4+Pc snFA== X-Gm-Message-State: AA6/9RkWlCWhlla8G2UFnwfFUnhuTKX4RN6i56e4SM8qlAt8iCw9lVm6/o0QP4gH++UwvUqS1ilnsIXn0L+UCHb9 X-Received: by 10.129.78.7 with SMTP id c7mr17264164ywb.63.1475867640121; Fri, 07 Oct 2016 12:14:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.5.19 with HTTP; Fri, 7 Oct 2016 12:13:39 -0700 (PDT) In-Reply-To: <73a98c3a-aaad-e2d2-3932-1f1eed60ae16@it.uc3m.es> References: <73a98c3a-aaad-e2d2-3932-1f1eed60ae16@it.uc3m.es> From: Ian Swett Date: Fri, 7 Oct 2016 15:13:39 -0400 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a114dacbc6d25ba053e4b36d4 Archived-At: Cc: draft-iyengar-quic-loss-recovery@ietf.org, quic@ietf.org Subject: Re: [QUIC] About loss detection and recovery in draft-iyengar-quic-loss-recovery-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:14:04 -0000 --001a114dacbc6d25ba053e4b36d4 Content-Type: text/plain; charset=UTF-8 Thanks for taking such a close look Marcelo, comments inline. On Fri, Oct 7, 2016 at 2:05 AM, marcelo bagnulo braun wrote: > Hi, > > So, i have been trying to understand the packet loss detection and > retransmission schemes for quic, described in draft-iyengar-quic-loss-recove > ry-00. > > I had a few difficulties to understand how this works, based on the > description in the draft. I include below what i think i understood, let me > know if i got this right. > > Section 2 and 3 mention the retransmission of lost packets, but if i > understood it correctly, i think the draft would benefit from dropping the > concept of retransmitted packet. I mean, I dont think there is such a thing > as a retransmitted packet. What quic retransmits is the data within packets > that were detected as lost, but the packet is not retransmitted. For > starters, the packet containing the retransmitted data has a different PSN. > But also, the content of the packet may be different as some frames are not > to be retransmitted. > > Completely true that QUIC never retransmits packets, only data. It would be better to drop that wording. > Moreover, if eventually some form of priority is implemented, i would > guess that data with higher priority would be retransmitted earlier than > data with lower priority. I think such flexibility would be useful. > > Completely agreed, though I'm not sure that needs to be specified in this doc or left up to implementations? > Let me see if I understand the overall framework for loss detection and > retransmission for quic. I think that quic detect packet loss, but > retransmits data (that was sent in packets) so it probably possible to > decouple the loss detection from the retransmission. > > Yes, very much so. > I understand that all data (control and application data) that is reliably > transmitted is transmitted within a stream. Other data that is not > transmitted within a given stream (like ACKs) is not reliably transmitted. > Is this correct? If so, it may be worth stating it as a design principle, > so people know that if they want to include control information such as > other options to be reliably transmitted, they should do it within a stream. > > It's correct that acks and stop waiting frames are not reliable frames and hence are not retransmitted, but other frame types are retransmittable and not be part of a stream(ie: PING frames). So, if a sender has M ongoing streams, then it has M+1 sliding windows, > i.e. one for each stream plus one for the packets at the connection level. > Let's call the packet one, the packet window and the other the stream n > window. The packet window is in packets, while the stream windows are in > bytes. > > Yes. > The packet window has the following types of packets: packets acked, > non-acked packets and lost packets. The left side of the window moves to > packet number n when all packets with packet number lower than n are marked > as acked or as lost. In other words, the left side of the window is the > non-acked packet with lowest packet number. This corresponds to the "least > unacked" packet mentioned in the draft. > > Each stream window has the following types of bytes. bytes acked, bytes > non-acked, bytes awaiting for transmission. Bytes non-acked are bytes that > are contained in packets on flight. Bytes awaiting for transmission are > bytes that either have not been sent yet or bytes that have been sent in > packets that have been determined as lost. > > Whenever a packet is acked, the bytes in each stream window corresponding > to the data of each stream included in the acked packet are marked as acked. > > Whenever a packet is determined as lost, the bytes in each stream window > corresponding to the data of that stream included in the packet are marked > as bytes awaiting for transmission. > > Whenever a new packet is transmitted, the bytes in each stream window > included in the packet are marked as non-acked. > > Packet loss detection only operates using the packet window. So, each > non-acked packet has an associated timer that when it times out, the packet > is marked as lost. You can define any other mechanisms to detect packet > loss only operating in this window, i believe. > Yes, the default mechanism actually uses FACK style packet number gaps, but time is an option and the important thing is loss detection operates on this connection-level packet window. > > Packet transmission otoh, needs to get data from the different stream > windows, probably using the bytes awaiting for transmission with the lowest > offset. This would include both the transmission of new data as well as > retransmission of old data. > > Do you think this properly describes the framework of operation for loss > detection and retransmission of quic? > > I think that captures the core ideas, yes. > Regards, marcelo --001a114dacbc6d25ba053e4b36d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for taking such a close look Marcelo, comments inline.

On Fri, Oct 7, 20= 16 at 2:05 AM, marcelo bagnulo braun=C2=A0<marcelo@it.uc3m.es>=C2=A0wrote:
Hi,
So, i have been trying to understand the packet loss detection and ret= ransmission schemes for quic, described in draft-iyengar-quic-loss-recovery-00.

I had a few difficulties to understand how this works, bas= ed on the description in the draft. I include below what i think i understo= od, let me know if i got this right.

Section 2 and 3 mention the ret= ransmission of lost packets, but if i understood it correctly, i think the = draft would benefit from dropping the concept of retransmitted packet. I me= an, I dont think there is such a thing as a retransmitted packet. What quic= retransmits is the data within packets that were detected as lost, but the= packet is not retransmitted. For starters, the packet containing the retra= nsmitted data has a different PSN. But also, the content of the packet may = be different as some frames are not to be retransmitted.


Completely true that QUIC never retransmits pa= ckets, only data.=C2=A0 It would be better to drop that wording.
=C2=A0
Moreover, if eventually some form of priority is implemented, i= would guess that data with higher priority would be retransmitted earlier = than data with lower priority. I think such flexibility would be useful.

Completely agreed, though I= 9;m not sure that needs to be specified in this doc or left up to implement= ations?
=C2=A0
Let me see if I understand the overall framew= ork for loss detection and retransmission for quic. I think that quic detec= t packet loss, but retransmits data (that was sent in packets) so it probab= ly possible to decouple the loss detection from the retransmission.

=

Yes, very much so.
=C2=A0
I und= erstand that all data (control and application data) that is reliably trans= mitted is transmitted within a stream. Other data that is not transmitted w= ithin a given stream (like ACKs) is not reliably transmitted. Is this corre= ct? If so, it may be worth stating it as a design principle, so people know= that if they want to include control information such as other options to = be reliably transmitted, they should do it within a stream.


It's correct that acks and stop waiting= frames are not reliable frames and hence are not retransmitted, but other = frame types are retransmittable and not be part of a stream(ie: PING frames= ). =C2=A0

So, if a sender has M ongoing streams, then i= t has M+1 sliding windows, i.e. one for each stream plus one for the packet= s at the connection level. Let's call the packet one, the packet window= and the other the stream n window. The packet window is in packets, while = the stream windows are in bytes.


=
Yes.
=C2=A0
The packet window has the following types = of packets: packets acked, non-acked packets and lost packets. The left sid= e of the window moves to packet number n when all packets with packet numbe= r lower than n are marked as acked or as lost. In other words, the left sid= e of the window is the non-acked packet with lowest packet number. This cor= responds to the "least unacked" packet mentioned in the draft.
Each stream window has the following types of bytes. bytes acked, byte= s non-acked, bytes awaiting for transmission. Bytes non-acked are bytes tha= t are contained in packets on flight. Bytes awaiting for transmission are b= ytes that either have not been sent yet or bytes that have been sent in pac= kets that have been determined as lost.

Whenever a packet is acked, = the bytes in each stream window corresponding to the data of each stream in= cluded in the acked packet are marked as acked.

Whenever a packet is= determined as lost, the bytes in each stream window corresponding to the d= ata of that stream included in the packet are marked as bytes awaiting for = transmission.

Whenever a new packet is transmitted, the bytes in eac= h stream window included in the packet are marked as non-acked.

Pack= et loss detection only operates using the packet window. So, each non-acked= packet has an associated timer that when it times out, the packet is marke= d as lost. You can define any other mechanisms to detect packet loss only o= perating in this window, i believe.

<= div>Yes, the default mechanism actually uses FACK style packet number gaps,= but time is an option and the important thing is loss detection operates o= n this connection-level packet window.
= =C2=A0

Packet tr= ansmission otoh, needs to get data from the different stream windows, proba= bly using the bytes awaiting for transmission with the lowest offset. This = would include both the transmission of new data as well as retransmission o= f old data.

Do you think this properly describes the framework of op= eration for loss detection and retransmission of quic?

=

I think that captures the core ideas, yes.=C2=A0=
=C2=A0
packet mentioned in the draft. > > Each stream window has the following types of bytes. bytes acked, > bytes non-acked, bytes awaiting for transmission. Bytes non-acked > are bytes that are contained in packets on flight. Bytes awaiting > for transmission are bytes that either have not been sent yet or > bytes that have been sent in packets that have been determined as > lost. > > Whenever a packet is acked, the bytes in each stream window > corresponding to the data of each stream included in the acked > packet are marked as acked. > > Whenever a packet is determined as lost, the bytes in each stream > window corresponding to the data of that stream included in the > packet are marked as bytes awaiting for transmission. > > Whenever a new packet is transmitted, the bytes in each stream > window included in the packet are marked as non-acked. > > Packet loss detection only operates using the packet window. So, > each non-acked packet has an associated timer that when it times > out, the packet is marked as lost. You can define any other > mechanisms to detect packet loss only operating in this window, i > believe. > > > Yes, the default mechanism actually uses FACK style packet number > gaps, but time is an option and the important thing is loss detection > operates on this connection-level packet window. Talking about default mechanisms, have you consider using RACK as the default mechanism for quic? It seems to me a very clean fit, since you already have per packet timers, no? Regards, marcelo > > Packet transmission otoh, needs to get data from the different > stream windows, probably using the bytes awaiting for transmission > with the lowest offset. This would include both the transmission > of new data as well as retransmission of old data. > > Do you think this properly describes the framework of operation > for loss detection and retransmission of quic? > > > I think that captures the core ideas, yes. > > Regards, marcelo > From nobody Fri Oct 7 13:24:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4312967A for ; Fri, 7 Oct 2016 13:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKIxHpRg1ll9 for ; Fri, 7 Oct 2016 13:24:07 -0700 (PDT) Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9566A129410 for ; Fri, 7 Oct 2016 13:24:07 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bsbgb-0004De-FT for quic@ietf.org; Fri, 07 Oct 2016 22:24:06 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bsbgZ-00008O-Sx for quic@ietf.org; Fri, 07 Oct 2016 16:24:04 -0400 Received: (qmail 8138 invoked from network); 7 Oct 2016 20:24:03 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Oct 2016 20:24:03 -0000 From: "Christian Huitema" To: "'marcelo bagnulo braun'" , "'Ian Swett'" References: <73a98c3a-aaad-e2d2-3932-1f1eed60ae16@it.uc3m.es> <047a0e75-95d0-3ca6-0c9d-6fc52de7f0aa@it.uc3m.es> In-Reply-To: <047a0e75-95d0-3ca6-0c9d-6fc52de7f0aa@it.uc3m.es> Date: Fri, 7 Oct 2016 13:23:59 -0700 Message-ID: <012501d220d8$bdc959c0$395c0d40$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHg8/KjyX4IIAvmMvzCQurR25uPEgIuFe0vAZwrL3SgYXPmEA== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDweQ HOPl5JIz/bPLogilZhCpovFMqoX7lR7RH8LpFF+0dcmtTcWSOKD5RASVzg27inXh5noZfH+Ue/bn p6ZbxyV5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdItI+H292vaf+flnjcpZKBvi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suok3DPIWrP5+rmqhQ+VmxXJXgZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept Archived-At: Cc: draft-iyengar-quic-loss-recovery@ietf.org, quic@ietf.org Subject: Re: [QUIC] About loss detection and recovery in draft-iyengar-quic-loss-recovery-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:24:09 -0000 On Friday, October 7, 2016 12:27 PM, Marcelo Bagnulo Braun wrote: > > I fail to see the point of reliably transmitting pings. I mean, a ping = > is a test packet, if it fails, i guess this is the test output, no? > you may want to send anohter ping, is basically you want to do anohter = > test. There is no point in retransmitting the old one (conceptually, i = mean) The way I see it, the ACK mechanism of QUIC performs loss detection. = Conceptually, upon detecting a loss, the protocol engine examines the = content of the lost packet. (There are multiple ways to do that in = practice.) Then, based on what was lost, the protocol engine decides = further actions. For example, stream data will be retransmitted most of = the time, but not always -- e.g., not retransmitted if the stream was = aborted. If a control packet is missing, the equivalent control may be = transmitted again, but this time with updated value. An example would be = a stream flow control packet, for which it is preferable to send the = up-to-date information rather than resend the old value. The case of the ping is particular. The engine sends a ping to check = that the other end is alive. Arguably, it knows that if it receives an = acknowledgement for the packet containing the ping frame, or for any = later packet. Pings will thus only need to be retransmitted in some kind = of "tail loss probe" scenario resulting in a timeout. The ping frame is = actually a great way to implement the tail loss probe algorithm. By the way, we are bound to see implementations that don't bother with = these subtleties and just retransmit the entire contents of the lost = packets. We should verify that this suboptimal behavior does not cause a = protocol error, e.g. if two consecutive flow control frames slightly = differ... -- Christian Huitema From nobody Mon Oct 10 01:47:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8C1295F9 for ; Mon, 10 Oct 2016 01:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJBDIS9oqSUR for ; Mon, 10 Oct 2016 01:47:17 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993D81294B5 for ; Mon, 10 Oct 2016 01:47:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,471,1473145200"; d="scan'208";a="148435949" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 10 Oct 2016 01:46:09 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Oct 2016 01:46:15 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::4ca2:22d:a2f1:881b%21]) with mapi id 15.00.1210.000; Mon, 10 Oct 2016 01:46:15 -0700 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: Welcome to QUIC Thread-Index: AQHSItLCc2mhOlHQr0SuFdK1umEUbQ== Date: Mon, 10 Oct 2016 08:46:14 +0000 Message-ID: <7EA41308-80E6-4040-A366-FB01E0E99FB1@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3226) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <96B5B5F28E8D494EB2B5CA927DB5639E@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [QUIC] Welcome to QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 08:47:19 -0000 As some of you have no doubt seen, QUIC is now chartered as am IETF Working= Group: https://datatracker.ietf.org/wg/quic/charter/ Welcome! As a reminder, as an IETF list, activity here is covered by the NOTE WELL t= erms; for more information, see: https://www.ietf.org/about/note-well.html This WG *will* be meeting at the Seoul IETF; we'll have a draft agenda out = for comments soon, but we expect to go over the charter and the input docum= ents there. If you have not already, please familiarise yourself with all o= f them beforehand. Our milestones are on an aggressive schedule, so we will be having a number= of Interim meetings (as highlighted in the charter). Details will be forth= coming soon, but at this point we anticipate having at least three standalo= ne Interims in 2017, roughly half-way between the IETF meetings (with the f= irst in the mid-January to mid-Feburary timeframe), with the potential for = Interims held adjacent to the three IETF meetings as well (in addition to m= eeting during the Plenary weeks, of course). As many other WGs have, we plan on using Github as th= e repository for our documents and issues list(s). Best practices for using= Github in IETF work are still evolving, but we will take appropriate steps= to assure that a) no information is "locked" into Github, and b) it is pos= sible to participate without disadvantage if you choose not to create a Git= hub account. If this causes you concern, please contact the chairs. We'll be in touch soon with more information, but in the meantime, please c= ontinue to discuss the documents and implementation of them on the list. We= look forward to working with all of you. Regards, Lars Eggert and Mark Nottingham, QUIC Working Group Chairs= From nobody Fri Oct 14 11:44:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C721297FE for ; Fri, 14 Oct 2016 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_6Pb3d3n-Vp for ; Fri, 14 Oct 2016 11:43:58 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128B312943D for ; Fri, 14 Oct 2016 11:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1476470638; x=1508006638; h=from:to:cc:date:subject:message-id:mime-version; bh=7sRTQtgsUv0DZeQPQ3BCSYH+tJndv8ZU2Hv3gIRucV4=; b=G19MIB7z0JkzA3QajcZir1h/3THNY7nNHUVCtr3NBpje8UtDMQ8x2xa2 d9OQp2J7KMIOqRxapZU2Ca1VzqLfc7Ou6JDRNzXKikZqJzWBO5YsyrQR/ 1BubdZjgiTWhQ9uW4WtsAB+K3UpagREd8RSpdxV3Z0GQsdMKJ2d5Y/+u0 o=; X-IronPort-Anti-Spam-Filtered: false Received: from omzsmtpi01.vzbi.com ([165.122.46.171]) by omzsmtpe03.verizonbusiness.com with ESMTP; 14 Oct 2016 18:43:56 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="5.31,346,1473120000"; d="scan'208,217";a="788539719" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by omzsmtpi01.vzbi.com with ESMTP/TLS/AES128-SHA; 14 Oct 2016 18:43:55 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 14 Oct 2016 14:43:54 -0400 To: "Eggert, Lars" Date: Fri, 14 Oct 2016 14:43:54 -0400 Thread-Topic: RE: [QUIC] Welcome to QUIC Thread-Index: AdImJkXMaf5ac/+YT6OLDUR7kMFl+A== Message-ID: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_900A1E2059ADB149B905E3C8FA0046A62D30CDBE1EFHDP1LUMXC7V2_" MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Welcome to QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 18:44:00 -0000 --_000_900A1E2059ADB149B905E3C8FA0046A62D30CDBE1EFHDP1LUMXC7V2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question on the clarity of text around network management practice= s as stated in the charter: Text from the QUIC charter: Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. The efficacy of WG's consideration on striving to achieve a balance consis= tent with tension described in RFC 7258 may find that its hands are tied gi= ven the charter text "The QUIC protocol need not be defined to enable each = of these abilities...". I may be missing, but what other mechanisms in the = charter help ensure working group can guide to an outcome consistent RFC 72= 58? Specifically, the statement from RFC 7258 that says "Making networks u= nmanageable to mitigate PM is not an acceptable outcome, but ignoring PM w= ould go against the consensus documented here." Thanks Sanjay -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Monday, October 10, 2016 4:46 AM To: quic@ietf.org Subject: [E] [QUIC] Welcome to QUIC As some of you have no doubt seen, QUIC is now chartered as am IETF Working= Group: https://datatracker.ietf.org/wg/quic/charter/ Welcome! As a reminder, as an IETF list, activity here is covered by the NOTE WELL t= erms; for more information, see: https://www.ietf.org/about/note-well.html This WG *will* be meeting at the Seoul IETF; we'll have a draft agenda out = for comments soon, but we expect to go over the charter and the input docum= ents there. If you have not already, please familiarise yourself with all o= f them beforehand. Our milestones are on an aggressive schedule, so we will be having a number= of Interim meetings (as highlighted in the charter). Details will be forth= coming soon, but at this point we anticipate having at least three standalo= ne Interims in 2017, roughly half-way between the IETF meetings (with the f= irst in the mid-January to mid-Feburary timeframe), with the potential for = Interims held adjacent to the three IETF meetings as well (in addition to m= eeting during the Plenary weeks, of course). As many other WGs have, we plan on using Github as th= e repository for our documents and issues list(s). Best practices for using= Github in IETF work are still evolving, but we will take appropriate steps= to assure that a) no information is "locked" into Github, and b) it is pos= sible to participate without disadvantage if you choose not to create a Git= hub account. If this causes you concern, please contact the chairs. We'll be in touch soon with more information, but in the meantime, please c= ontinue to discuss the documents and implementation of them on the list. We= look forward to working with all of you. Regards, Lars Eggert and Mark Nottingham, QUIC Working Group Chairs _______________________________________________ QUIC mailing list QUIC@ietf.org https://www.ietf.org/mailman/listinfo/quic --_000_900A1E2059ADB149B905E3C8FA0046A62D30CDBE1EFHDP1LUMXC7V2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a questio= n on the clarity of text around network management practices as stated in t= he charter:

 

Text from the QUIC= charter:

 

Current practices for= network management of transport protocols
include the ability to apply= access control lists (ACLs), hashing of
flows for equal-cost multipath= routing (ECMP), directional signaling
of flows, signaling of flow setu= p and teardown, and the ability to
export information about flows for a= ccounting purposes. The QUIC
protocol need not be defined to enable each of these ab= ilities, or
enable them in the same way as they are enabled by TCP when= used
with TLS 1.3, but the working group must consider the impact of the
protocol on ne= twork management practices, reflecting the tensions
described in = RFC 7258.

&n= bsp;

The efficacy of W= G’s consideration on  striving to achieve a balance consistent w= ith tension described in RFC 7258 may find that its hands are tied given th= e charter text “The QUIC protocol need not be defined to enable each = of these abilities…”. I may be missing, but what other mechanis= ms in the charter help ensure working group can guide to an outcome consist= ent RFC 7258? Specifically, the statement from RFC 7258 that says “Ma= king  networks unmanageable to mitigate PM is not an acceptable outcom= e,  but ignoring PM would go against the consensus documented here.= 221;

 <= /o:p>

Thanks

Sanjay

 

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eggert,= Lars
Sent: Monday, October 10, 2016 4:46 AM
To: quic@ietf.org
Subject: [E] [QUIC] Welcome to QUIC<= /o:p>

 

As = some of you have no doubt seen, QUIC is now chartered as am IETF Working Gr= oup:

 

https://da= tatracker.ietf.org/wg/quic/charter/

=  

Welcome!

 

As a reminder, as an= IETF list, activity here is covered by the NOTE WELL terms; for more infor= mation, see:

 

https:= //www.ietf.org/about/note-well.html

=  

This WG *will* be meeting at the = Seoul IETF; we'll have a draft agenda out for comments soon, but we expect = to go over the charter and the input documents there. If you have not alrea= dy, please familiarise yourself with all of them beforehand.

=

 

Our mileston= es are on an aggressive schedule, so we will be having a number of Interim = meetings (as highlighted in the charter). Details will be forthcoming soon,= but at this point we anticipate having at least three standalone Interims = in 2017, roughly half-way between the IETF meetings (with the first in the = mid-January to mid-Feburary timeframe), with the potential for Interims hel= d adjacent to the three IETF meetings as well (in addition to meeting durin= g the Plenary weeks, of course).

&n= bsp;

As many other WGs have, we plan on using= Github <https://github.com/> as = the repository for our documents and issues list(s). Best practices for usi= ng Github in IETF work are still evolving, but we will take appropriate ste= ps to assure that a) no information is "locked" into Github, and = b) it is possible to participate without disadvantage if you choose not to = create a Github account. If this causes you concern, please contact the cha= irs.

 

We'll be in touch soon with more information, but in the meantime, p= lease continue to discuss the documents and implementation of them on the l= ist. We look forward to working with all of you.

 

 

Regards,

 

Lars Eggert and Mark Nottingham, QUIC Working = Group Chairs

__________________________= _____________________

QUIC mailing list<= o:p>

QUIC@ie= tf.org

https://www.ietf.org/mailman/listinfo/quic

 

= --_000_900A1E2059ADB149B905E3C8FA0046A62D30CDBE1EFHDP1LUMXC7V2_-- From nobody Fri Oct 14 14:08:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D853129645 for ; Fri, 14 Oct 2016 14:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov8-VZPQJDF0 for ; Fri, 14 Oct 2016 14:08:50 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDEE129640 for ; Fri, 14 Oct 2016 14:08:50 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 2C7121A0A5A; Fri, 14 Oct 2016 23:08:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_133CEB7B-2384-4CBF-95CA-342061192FF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> Date: Fri, 14 Oct 2016 23:08:17 +0200 Message-Id: <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> To: "Mishra, Sanjay" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Welcome to QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 21:08:52 -0000 --Apple-Mail=_133CEB7B-2384-4CBF-95CA-342061192FF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Sanjay, > On 14 Oct 2016, at 20:43, Mishra, Sanjay = wrote: >=20 > I have a question on the clarity of text around network management = practices as stated in the charter: >=20 > Text from the QUIC charter: >=20 > Current practices for network management of transport protocols > include the ability to apply access control lists (ACLs), hashing of > flows for equal-cost multipath routing (ECMP), directional signaling > of flows, signaling of flow setup and teardown, and the ability to > export information about flows for accounting purposes. The QUIC > protocol need not be defined to enable each of these abilities, or > enable them in the same way as they are enabled by TCP when used > with TLS 1.3, but the working group must consider the impact of the > protocol on network management practices, reflecting the tensions > described in RFC 7258. >=20 > The efficacy of WG=E2=80=99s consideration on striving to achieve a = balance consistent with tension described in RFC 7258 may find that its = hands are tied given the charter text =E2=80=9CThe QUIC protocol need = not be defined to enable each of these abilities=E2=80=A6=E2=80=9D. I = may be missing, but what other mechanisms in the charter help ensure = working group can guide to an outcome consistent RFC 7258? Specifically, = the statement from RFC 7258 that says =E2=80=9CMaking networks = unmanageable to mitigate PM is not an acceptable outcome, but ignoring = PM would go against the consensus documented here." Since many of the words you seek to clarify come from language helped = write to be added to the charter, let me try to clarify the intent, and = explain what I see as the way to ensure an outcome consistent with = 7258's recognition that realization of the extent of large-scale = pervasive surveillance does not change the fact that manageability is a = first-order requirement of network protocols. Since much of the controversy on this point at the BoF was that "network = management and operations" was too vague, we wanted to be concrete about = what kinds of network management practices should be considered in = designing a new transport protocol. The five chosen are widely deployed, = well understood, and relatively uncontroversial. A requirement to support every one of these operations exactly as they = are presently supported by TCP would constrain the QUIC design space too = tightly: it would have to look and behave exactly like vanilla TCP on = the wire. We already have a transport protocol that does that. It's = called TCP. QUIC has one advantage that TCP doesn't: it can fall back to TLS over = TCP. Indeed, it is defined in such a way that applications that cannot = handle a fall back to TLS over TCP cannot run over it. We have to do = this to handle UDP blocking (relatively common, about 5%) and other = performance impairment (much rarer, still present). I personally think = that this should be seen as the starting point of an indefinite = transition, as opposed to a permanent convenience; the latter risks = stalling the deployment of the protocol. (Fallbacks are great for = reliability but terrible for ensuring deployment. Case in point, I'm a = huge fan of Happy Eyeballs, but last time I looked about 10% of the = sites in the Alexa top million that bothered to publish AAAA records had = them point to nonsensical places, or weren't listening where they = thought they were. Happy Eyeballs means nobody notices, so these = problems never get fixed.) But IETF-standard QUIC doesn't exist yet, in-network devices that = support these management functions in probably-somewhat-TCP-like but = not-TCP-wire-compatible don't either. They'll have to be developed in = tandem with the protocol. And if the working group finds that there is a = tradeoff -- for example, the working group may find that either flow = directionality or flow setup and teardown signaling needs to be impaired = or removed to meet some other more important requirement. Indeed, either = directionality signaling or end signaling is probably enough to do most = of what most firewalls need at layer 3/4. This text gives the working = group the flexibility to do that without rechartering. So I would interpret the text to mean that the working group must = consider operations and management functions in the design of the = protocol, especially how the protocol interacts with devices other than = the endpoints for these five management functions, and needs good = reasons to trade off against supporting them in the final protocol = design. I would not interpret this text to mean "QUIC may be defined to = enable *none* of these abilities". Hope this helps, cheers, Brian > Thanks > Sanjay >=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eggert, Lars > Sent: Monday, October 10, 2016 4:46 AM > To: quic@ietf.org > Subject: [E] [QUIC] Welcome to QUIC >=20 > As some of you have no doubt seen, QUIC is now chartered as am IETF = Working Group: >=20 > https://datatracker.ietf.org/wg/quic/charter/ >=20 > Welcome! >=20 > As a reminder, as an IETF list, activity here is covered by the NOTE = WELL terms; for more information, see: >=20 > https://www.ietf.org/about/note-well.html >=20 > This WG *will* be meeting at the Seoul IETF; we'll have a draft agenda = out for comments soon, but we expect to go over the charter and the = input documents there. If you have not already, please familiarise = yourself with all of them beforehand. >=20 > Our milestones are on an aggressive schedule, so we will be having a = number of Interim meetings (as highlighted in the charter). Details will = be forthcoming soon, but at this point we anticipate having at least = three standalone Interims in 2017, roughly half-way between the IETF = meetings (with the first in the mid-January to mid-Feburary timeframe), = with the potential for Interims held adjacent to the three IETF meetings = as well (in addition to meeting during the Plenary weeks, of course). >=20 > As many other WGs have, we plan on using Github = as the repository for our documents and issues list(s). Best practices = for using Github in IETF work are still evolving, but we will take = appropriate steps to assure that a) no information is "locked" into = Github, and b) it is possible to participate without disadvantage if you = choose not to create a Github account. If this causes you concern, = please contact the chairs. >=20 > We'll be in touch soon with more information, but in the meantime, = please continue to discuss the documents and implementation of them on = the list. We look forward to working with all of you. >=20 >=20 > Regards, >=20 > Lars Eggert and Mark Nottingham, QUIC Working Group Chairs > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_133CEB7B-2384-4CBF-95CA-342061192FF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYAUlBAAoJEIoSt78L6kajFnQP/Ap0yr1TvJFzet85QTTFwxIn w1xZjwiKwoK4lzrVV3K+lWCX9zeeOcTrruLoo+fP15ta6Xr4z0CW6JTAnaJxyMyQ OOaPrNgnnW0+ngDsCtQX6nHEdGOmvKAGCXApE20LtKFycxScfoCDjgb2QBrNR3gk nrtGZq3juHs2uIg7Yx+efD/OQw5eTXcxs0bBkkYeP7nplKdBycwdye0YRWBllkri SD1RFwbIJG1ETLCH7lziWtb/TN96ufJcXl5C0RjBX7lBzl3fjfWru7kHCo4sZGxB F7Jqr4c8Klfucn1GM7HFy3LN2e/UxinAu02yIVnpn9Gk2xlhiBAn09QMfWIEfohQ HkDHa4DvHCt8II9YT4WBUPI+j3l8Zv9rKVALyaBUXIBdHu9F+cDtx3Ilhyheeryn celcXQi0yplX4Vmfytnc07zyAsnmEId8o7/cWIoND3+NWQq5732JGYaOIG4DHYUE DGRoCFcNDbgvJCVy9QfQNu+k97/ouQ4PwTRKD6Bd0A5DbMTef0E3VXKqNV1ZWOcE TfQr5rNBQSJhyvrtLTlCJHprxUri+DU4gBLAC79bm+ekhbnCClMEWPQVcpSX4XtM cBaeRZ1uGBEN9qxypriHtmNWZK43qlN80Rv3575iHJ29xVd8oiEFoKyoWV9E46Hx SYqUl2WKVfB9enzK716m =sldj -----END PGP SIGNATURE----- --Apple-Mail=_133CEB7B-2384-4CBF-95CA-342061192FF4-- From nobody Mon Oct 17 11:15:45 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3ED129457 for ; Mon, 17 Oct 2016 11:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xGvDrnBFmtZ for ; Mon, 17 Oct 2016 11:15:41 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760EE129447 for ; Mon, 17 Oct 2016 11:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1476728141; x=1508264141; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZlrfatFfuAbflK4/T7wy68WYAytQV3zZwtE3LTtQ8Rw=; b=TIdFVLF2PJvgK0Ru22nc+JAqEX+q5Ez3a+5eOPSrMNtYF/a0MaiBGrOC 8W4hYxmeln9IRvbKLEzrrOe02QD1hEjUPUbv3fc92cINuJyayHPi8dUPU IcArk/JSAWLbxJ0J5wWClzGzALSQQm15Z4BjcdD7x9pgmZtLZGWK3HFBV I=; X-IronPort-Anti-Spam-Filtered: false Received: from omzsmtpi01.vzbi.com ([165.122.46.171]) by omzsmtpe01.verizonbusiness.com with ESMTP; 17 Oct 2016 18:15:30 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="5.31,358,1473120000"; d="scan'208";a="790860699" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by omzsmtpi01.vzbi.com with ESMTP/TLS/AES128-SHA; 17 Oct 2016 18:15:16 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Mon, 17 Oct 2016 14:15:13 -0400 To: Brian Trammell Date: Mon, 17 Oct 2016 14:15:12 -0400 Thread-Topic: [E] Re: [QUIC] Welcome to QUIC Thread-Index: AdImXyGS1MNlZvF5Sx+ARpwROuWwBACP9pCg Message-ID: <900A1E2059ADB149B905E3C8FA0046A62D30CDC01C@FHDP1LUMXC7V23.us.one.verizon.com> References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> In-Reply-To: <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] [E] Re: Welcome to QUIC X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 18:15:43 -0000 SGkgQnJpYW4gLS0NCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVzcG9uc2UgYW5kIGNsYXJp ZmljYXRpb24gdG8gdGhlIGNoYXJ0ZXIgdGV4dC4gDQoNCi1TYW5qYXkNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIFRyYW1tZWxsIFttYWlsdG86aWV0ZkB0cmFtbWVs bC5jaF0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIwMTYgNTowOCBQTQ0KVG86IE1pc2hy YSwgU2FuamF5DQpDYzogRWdnZXJ0LCBMYXJzOyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBbRV0g UmU6IFtRVUlDXSBXZWxjb21lIHRvIFFVSUMNCg0KaGkgU2FuamF5LA0KDQo+IE9uIDE0IE9jdCAy MDE2LCBhdCAyMDo0MywgTWlzaHJhLCBTYW5qYXkgPHNhbmpheS5taXNocmFAdmVyaXpvbi5jb20+ IHdyb3RlOg0KPiANCj4gSSBoYXZlIGEgcXVlc3Rpb24gb24gdGhlIGNsYXJpdHkgb2YgdGV4dCBh cm91bmQgbmV0d29yayBtYW5hZ2VtZW50IHByYWN0aWNlcyBhcyBzdGF0ZWQgaW4gdGhlIGNoYXJ0 ZXI6DQo+IA0KPiBUZXh0IGZyb20gdGhlIFFVSUMgY2hhcnRlcjoNCj4gDQo+IEN1cnJlbnQgcHJh Y3RpY2VzIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgb2YgdHJhbnNwb3J0IHByb3RvY29scyANCj4g aW5jbHVkZSB0aGUgYWJpbGl0eSB0byBhcHBseSBhY2Nlc3MgY29udHJvbCBsaXN0cyAoQUNMcyks IGhhc2hpbmcgb2YgDQo+IGZsb3dzIGZvciBlcXVhbC1jb3N0IG11bHRpcGF0aCByb3V0aW5nIChF Q01QKSwgZGlyZWN0aW9uYWwgc2lnbmFsaW5nIA0KPiBvZiBmbG93cywgc2lnbmFsaW5nIG9mIGZs b3cgc2V0dXAgYW5kIHRlYXJkb3duLCBhbmQgdGhlIGFiaWxpdHkgdG8gDQo+IGV4cG9ydCBpbmZv cm1hdGlvbiBhYm91dCBmbG93cyBmb3IgYWNjb3VudGluZyBwdXJwb3Nlcy4gVGhlIFFVSUMgDQo+ IHByb3RvY29sIG5lZWQgbm90IGJlIGRlZmluZWQgdG8gZW5hYmxlIGVhY2ggb2YgdGhlc2UgYWJp bGl0aWVzLCBvciANCj4gZW5hYmxlIHRoZW0gaW4gdGhlIHNhbWUgd2F5IGFzIHRoZXkgYXJlIGVu YWJsZWQgYnkgVENQIHdoZW4gdXNlZCB3aXRoIA0KPiBUTFMgMS4zLCBidXQgdGhlIHdvcmtpbmcg Z3JvdXAgbXVzdCBjb25zaWRlciB0aGUgaW1wYWN0IG9mIHRoZSANCj4gcHJvdG9jb2wgb24gbmV0 d29yayBtYW5hZ2VtZW50IHByYWN0aWNlcywgcmVmbGVjdGluZyB0aGUgdGVuc2lvbnMgDQo+IGRl c2NyaWJlZCBpbiBSRkMgNzI1OC4NCj4gDQo+IFRoZSBlZmZpY2FjeSBvZiBXR+KAmXMgY29uc2lk ZXJhdGlvbiBvbiAgc3RyaXZpbmcgdG8gYWNoaWV2ZSBhIGJhbGFuY2UgY29uc2lzdGVudCB3aXRo IHRlbnNpb24gZGVzY3JpYmVkIGluIFJGQyA3MjU4IG1heSBmaW5kIHRoYXQgaXRzIGhhbmRzIGFy ZSB0aWVkIGdpdmVuIHRoZSBjaGFydGVyIHRleHQg4oCcVGhlIFFVSUMgcHJvdG9jb2wgbmVlZCBu b3QgYmUgZGVmaW5lZCB0byBlbmFibGUgZWFjaCBvZiB0aGVzZSBhYmlsaXRpZXPigKbigJ0uIEkg bWF5IGJlIG1pc3NpbmcsIGJ1dCB3aGF0IG90aGVyIG1lY2hhbmlzbXMgaW4gdGhlIGNoYXJ0ZXIg aGVscCBlbnN1cmUgd29ya2luZyBncm91cCBjYW4gZ3VpZGUgdG8gYW4gb3V0Y29tZSBjb25zaXN0 ZW50IFJGQyA3MjU4PyBTcGVjaWZpY2FsbHksIHRoZSBzdGF0ZW1lbnQgZnJvbSBSRkMgNzI1OCB0 aGF0IHNheXMg4oCcTWFraW5nICBuZXR3b3JrcyB1bm1hbmFnZWFibGUgdG8gbWl0aWdhdGUgUE0g aXMgbm90IGFuIGFjY2VwdGFibGUgb3V0Y29tZSwgIGJ1dCBpZ25vcmluZyBQTSB3b3VsZCBnbyBh Z2FpbnN0IHRoZSBjb25zZW5zdXMgZG9jdW1lbnRlZCBoZXJlLiINCg0KU2luY2UgbWFueSBvZiB0 aGUgd29yZHMgeW91IHNlZWsgdG8gY2xhcmlmeSBjb21lIGZyb20gbGFuZ3VhZ2UgaGVscGVkIHdy aXRlIHRvIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyLCBsZXQgbWUgdHJ5IHRvIGNsYXJpZnkgdGhl IGludGVudCwgYW5kIGV4cGxhaW4gd2hhdCBJIHNlZSBhcyB0aGUgd2F5IHRvIGVuc3VyZSBhbiBv dXRjb21lIGNvbnNpc3RlbnQgd2l0aCA3MjU4J3MgcmVjb2duaXRpb24gdGhhdCByZWFsaXphdGlv biBvZiB0aGUgZXh0ZW50IG9mIGxhcmdlLXNjYWxlIHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UgZG9l cyBub3QgY2hhbmdlIHRoZSBmYWN0IHRoYXQgbWFuYWdlYWJpbGl0eSBpcyBhIGZpcnN0LW9yZGVy IHJlcXVpcmVtZW50IG9mIG5ldHdvcmsgcHJvdG9jb2xzLg0KDQpTaW5jZSBtdWNoIG9mIHRoZSBj b250cm92ZXJzeSBvbiB0aGlzIHBvaW50IGF0IHRoZSBCb0Ygd2FzIHRoYXQgIm5ldHdvcmsgbWFu YWdlbWVudCBhbmQgb3BlcmF0aW9ucyIgd2FzIHRvbyB2YWd1ZSwgd2Ugd2FudGVkIHRvIGJlIGNv bmNyZXRlIGFib3V0IHdoYXQga2luZHMgb2YgbmV0d29yayBtYW5hZ2VtZW50IHByYWN0aWNlcyBz aG91bGQgYmUgY29uc2lkZXJlZCBpbiBkZXNpZ25pbmcgYSBuZXcgdHJhbnNwb3J0IHByb3RvY29s LiBUaGUgZml2ZSBjaG9zZW4gYXJlIHdpZGVseSBkZXBsb3llZCwgd2VsbCB1bmRlcnN0b29kLCBh bmQgcmVsYXRpdmVseSB1bmNvbnRyb3ZlcnNpYWwuDQoNCkEgcmVxdWlyZW1lbnQgdG8gc3VwcG9y dCBldmVyeSBvbmUgb2YgdGhlc2Ugb3BlcmF0aW9ucyBleGFjdGx5IGFzIHRoZXkgYXJlIHByZXNl bnRseSBzdXBwb3J0ZWQgYnkgVENQIHdvdWxkIGNvbnN0cmFpbiB0aGUgUVVJQyBkZXNpZ24gc3Bh Y2UgdG9vIHRpZ2h0bHk6IGl0IHdvdWxkIGhhdmUgdG8gbG9vayBhbmQgYmVoYXZlIGV4YWN0bHkg bGlrZSB2YW5pbGxhIFRDUCBvbiB0aGUgd2lyZS4gV2UgYWxyZWFkeSBoYXZlIGEgdHJhbnNwb3J0 IHByb3RvY29sIHRoYXQgZG9lcyB0aGF0LiBJdCdzIGNhbGxlZCBUQ1AuDQoNClFVSUMgaGFzIG9u ZSBhZHZhbnRhZ2UgdGhhdCBUQ1AgZG9lc24ndDogaXQgY2FuIGZhbGwgYmFjayB0byBUTFMgb3Zl ciBUQ1AuIEluZGVlZCwgaXQgaXMgZGVmaW5lZCBpbiBzdWNoIGEgd2F5IHRoYXQgYXBwbGljYXRp b25zIHRoYXQgY2Fubm90IGhhbmRsZSBhIGZhbGwgYmFjayB0byBUTFMgb3ZlciBUQ1AgY2Fubm90 IHJ1biBvdmVyIGl0LiBXZSBoYXZlIHRvIGRvIHRoaXMgdG8gaGFuZGxlIFVEUCBibG9ja2luZyAo cmVsYXRpdmVseSBjb21tb24sIGFib3V0IDUlKSBhbmQgb3RoZXIgcGVyZm9ybWFuY2UgaW1wYWly bWVudCAobXVjaCByYXJlciwgc3RpbGwgcHJlc2VudCkuIEkgcGVyc29uYWxseSB0aGluayB0aGF0 IHRoaXMgc2hvdWxkIGJlIHNlZW4gYXMgdGhlIHN0YXJ0aW5nIHBvaW50IG9mIGFuIGluZGVmaW5p dGUgdHJhbnNpdGlvbiwgYXMgb3Bwb3NlZCB0byBhIHBlcm1hbmVudCBjb252ZW5pZW5jZTsgdGhl IGxhdHRlciByaXNrcyBzdGFsbGluZyB0aGUgZGVwbG95bWVudCBvZiB0aGUgcHJvdG9jb2wuIChG YWxsYmFja3MgYXJlIGdyZWF0IGZvciByZWxpYWJpbGl0eSBidXQgdGVycmlibGUgZm9yIGVuc3Vy aW5nIGRlcGxveW1lbnQuIENhc2UgaW4gcG9pbnQsIEknbSBhIGh1Z2UgZmFuIG9mIEhhcHB5IEV5 ZWJhbGxzLCBidXQgbGFzdCB0aW1lIEkgbG9va2VkIGFib3V0IDEwJSBvZiB0aGUgc2l0ZXMgaW4g dGhlIEFsZXhhIHRvcCBtaWxsaW9uIHRoYXQgYm90aGVyZWQgdG8gcHVibGlzaCBBQUFBIHJlY29y ZHMgaGFkIHRoZW0gcG9pbnQgdG8gbm9uc2Vuc2ljYWwgcGxhY2VzLCBvciB3ZXJlbid0IGxpc3Rl bmluZyB3aGVyZSB0aGV5IHRob3VnaHQgdGhleSB3ZXJlLiBIYXBweSBFeWViYWxscyBtZWFucyBu b2JvZHkgbm90aWNlcywgc28gdGhlc2UgcHJvYmxlbXMgbmV2ZXIgZ2V0IGZpeGVkLikNCg0KQnV0 IElFVEYtc3RhbmRhcmQgUVVJQyBkb2Vzbid0IGV4aXN0IHlldCwgaW4tbmV0d29yayBkZXZpY2Vz IHRoYXQgc3VwcG9ydCB0aGVzZSBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBpbiBwcm9iYWJseS1zb21l d2hhdC1UQ1AtbGlrZSBidXQgbm90LVRDUC13aXJlLWNvbXBhdGlibGUgZG9uJ3QgZWl0aGVyLiBU aGV5J2xsIGhhdmUgdG8gYmUgZGV2ZWxvcGVkIGluIHRhbmRlbSB3aXRoIHRoZSBwcm90b2NvbC4g QW5kIGlmIHRoZSB3b3JraW5nIGdyb3VwIGZpbmRzIHRoYXQgdGhlcmUgaXMgYSB0cmFkZW9mZiAt LSBmb3IgZXhhbXBsZSwgdGhlIHdvcmtpbmcgZ3JvdXAgbWF5IGZpbmQgdGhhdCBlaXRoZXIgZmxv dyBkaXJlY3Rpb25hbGl0eSBvciBmbG93IHNldHVwIGFuZCB0ZWFyZG93biBzaWduYWxpbmcgbmVl ZHMgdG8gYmUgaW1wYWlyZWQgb3IgcmVtb3ZlZCB0byBtZWV0IHNvbWUgb3RoZXIgbW9yZSBpbXBv cnRhbnQgcmVxdWlyZW1lbnQuIEluZGVlZCwgZWl0aGVyIGRpcmVjdGlvbmFsaXR5IHNpZ25hbGlu ZyBvciBlbmQgc2lnbmFsaW5nIGlzIHByb2JhYmx5IGVub3VnaCB0byBkbyBtb3N0IG9mIHdoYXQg bW9zdCBmaXJld2FsbHMgbmVlZCBhdCBsYXllciAzLzQuIFRoaXMgdGV4dCBnaXZlcyB0aGUgd29y a2luZyBncm91cCB0aGUgZmxleGliaWxpdHkgdG8gZG8gdGhhdCB3aXRob3V0IHJlY2hhcnRlcmlu Zy4NCg0KU28gSSB3b3VsZCBpbnRlcnByZXQgdGhlIHRleHQgdG8gbWVhbiB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIG11c3QgY29uc2lkZXIgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudCBmdW5jdGlv bnMgaW4gdGhlIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wsIGVzcGVjaWFsbHkgaG93IHRoZSBwcm90 b2NvbCBpbnRlcmFjdHMgd2l0aCBkZXZpY2VzIG90aGVyIHRoYW4gdGhlIGVuZHBvaW50cyBmb3Ig dGhlc2UgZml2ZSBtYW5hZ2VtZW50IGZ1bmN0aW9ucywgYW5kIG5lZWRzIGdvb2QgcmVhc29ucyB0 byB0cmFkZSBvZmYgYWdhaW5zdCBzdXBwb3J0aW5nIHRoZW0gaW4gdGhlIGZpbmFsIHByb3RvY29s IGRlc2lnbi4gSSB3b3VsZCBub3QgaW50ZXJwcmV0IHRoaXMgdGV4dCB0byBtZWFuICJRVUlDIG1h eSBiZSBkZWZpbmVkIHRvIGVuYWJsZSAqbm9uZSogb2YgdGhlc2UgYWJpbGl0aWVzIi4NCg0KSG9w ZSB0aGlzIGhlbHBzLCBjaGVlcnMsDQoNCkJyaWFuDQoNCj4gVGhhbmtzDQo+IFNhbmpheQ0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVnZ2VydCwgTGFycw0KPiBTZW50OiBNb25k YXksIE9jdG9iZXIgMTAsIDIwMTYgNDo0NiBBTQ0KPiBUbzogcXVpY0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbRV0gW1FVSUNdIFdlbGNvbWUgdG8gUVVJQw0KPiANCj4gQXMgc29tZSBvZiB5b3UgaGF2 ZSBubyBkb3VidCBzZWVuLCBRVUlDIGlzIG5vdyBjaGFydGVyZWQgYXMgYW0gSUVURiBXb3JraW5n IEdyb3VwOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9xdWljL2NoYXJ0 ZXIvDQo+IA0KPiBXZWxjb21lIQ0KPiANCj4gQXMgYSByZW1pbmRlciwgYXMgYW4gSUVURiBsaXN0 LCBhY3Rpdml0eSBoZXJlIGlzIGNvdmVyZWQgYnkgdGhlIE5PVEUgV0VMTCB0ZXJtczsgZm9yIG1v cmUgaW5mb3JtYXRpb24sIHNlZToNCj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2Fib3V0L25v dGUtd2VsbC5odG1sDQo+IA0KPiBUaGlzIFdHICp3aWxsKiBiZSBtZWV0aW5nIGF0IHRoZSBTZW91 bCBJRVRGOyB3ZSdsbCBoYXZlIGEgZHJhZnQgYWdlbmRhIG91dCBmb3IgY29tbWVudHMgc29vbiwg YnV0IHdlIGV4cGVjdCB0byBnbyBvdmVyIHRoZSBjaGFydGVyIGFuZCB0aGUgaW5wdXQgZG9jdW1l bnRzIHRoZXJlLiBJZiB5b3UgaGF2ZSBub3QgYWxyZWFkeSwgcGxlYXNlIGZhbWlsaWFyaXNlIHlv dXJzZWxmIHdpdGggYWxsIG9mIHRoZW0gYmVmb3JlaGFuZC4NCj4gDQo+IE91ciBtaWxlc3RvbmVz IGFyZSBvbiBhbiBhZ2dyZXNzaXZlIHNjaGVkdWxlLCBzbyB3ZSB3aWxsIGJlIGhhdmluZyBhIG51 bWJlciBvZiBJbnRlcmltIG1lZXRpbmdzIChhcyBoaWdobGlnaHRlZCBpbiB0aGUgY2hhcnRlciku IERldGFpbHMgd2lsbCBiZSBmb3J0aGNvbWluZyBzb29uLCBidXQgYXQgdGhpcyBwb2ludCB3ZSBh bnRpY2lwYXRlIGhhdmluZyBhdCBsZWFzdCB0aHJlZSBzdGFuZGFsb25lIEludGVyaW1zIGluIDIw MTcsIHJvdWdobHkgaGFsZi13YXkgYmV0d2VlbiB0aGUgSUVURiBtZWV0aW5ncyAod2l0aCB0aGUg Zmlyc3QgaW4gdGhlIG1pZC1KYW51YXJ5IHRvIG1pZC1GZWJ1cmFyeSB0aW1lZnJhbWUpLCB3aXRo IHRoZSBwb3RlbnRpYWwgZm9yIEludGVyaW1zIGhlbGQgYWRqYWNlbnQgdG8gdGhlIHRocmVlIElF VEYgbWVldGluZ3MgYXMgd2VsbCAoaW4gYWRkaXRpb24gdG8gbWVldGluZyBkdXJpbmcgdGhlIFBs ZW5hcnkgd2Vla3MsIG9mIGNvdXJzZSkuDQo+IA0KPiBBcyBtYW55IG90aGVyIFdHcyBoYXZlLCB3 ZSBwbGFuIG9uIHVzaW5nIEdpdGh1YiA8aHR0cHM6Ly9naXRodWIuY29tLz4gYXMgdGhlIHJlcG9z aXRvcnkgZm9yIG91ciBkb2N1bWVudHMgYW5kIGlzc3VlcyBsaXN0KHMpLiBCZXN0IHByYWN0aWNl cyBmb3IgdXNpbmcgR2l0aHViIGluIElFVEYgd29yayBhcmUgc3RpbGwgZXZvbHZpbmcsIGJ1dCB3 ZSB3aWxsIHRha2UgYXBwcm9wcmlhdGUgc3RlcHMgdG8gYXNzdXJlIHRoYXQgYSkgbm8gaW5mb3Jt YXRpb24gaXMgImxvY2tlZCIgaW50byBHaXRodWIsIGFuZCBiKSBpdCBpcyBwb3NzaWJsZSB0byBw YXJ0aWNpcGF0ZSB3aXRob3V0IGRpc2FkdmFudGFnZSBpZiB5b3UgY2hvb3NlIG5vdCB0byBjcmVh dGUgYSBHaXRodWIgYWNjb3VudC4gSWYgdGhpcyBjYXVzZXMgeW91IGNvbmNlcm4sIHBsZWFzZSBj b250YWN0IHRoZSBjaGFpcnMuDQo+IA0KPiBXZSdsbCBiZSBpbiB0b3VjaCBzb29uIHdpdGggbW9y ZSBpbmZvcm1hdGlvbiwgYnV0IGluIHRoZSBtZWFudGltZSwgcGxlYXNlIGNvbnRpbnVlIHRvIGRp c2N1c3MgdGhlIGRvY3VtZW50cyBhbmQgaW1wbGVtZW50YXRpb24gb2YgdGhlbSBvbiB0aGUgbGlz dC4gV2UgbG9vayBmb3J3YXJkIHRvIHdvcmtpbmcgd2l0aCBhbGwgb2YgeW91Lg0KPiANCj4gDQo+ IFJlZ2FyZHMsDQo+IA0KPiBMYXJzIEVnZ2VydCBhbmQgTWFyayBOb3R0aW5naGFtLCBRVUlDIFdv cmtpbmcgR3JvdXAgQ2hhaXJzIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBRVUlDIG1haWxpbmcgbGlzdA0KPiBRVUlDQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUVVJQyBtYWlsaW5nIGxp c3QNCj4gUVVJQ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3F1aWMNCg0K From nobody Wed Oct 19 15:26:24 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C91297FE for ; Wed, 19 Oct 2016 15:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B9-Cf9KhSe4 for ; Wed, 19 Oct 2016 15:26:19 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E4C37129847 for ; Wed, 19 Oct 2016 15:26:16 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id AE29C1A0857 for ; Thu, 20 Oct 2016 00:26:15 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_AE9C9754-74FA-4C89-89BC-F0D181795FEB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> Date: Thu, 20 Oct 2016 00:26:14 +0200 Message-Id: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> To: "quic@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 22:26:23 -0000 --Apple-Mail=_AE9C9754-74FA-4C89-89BC-F0D181795FEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, A couple of days ago, in a thread on the network management paragraph in = the charter, I wrote: > Indeed, either directionality signaling or end signaling is probably = enough to do most of what most firewalls need at layer 3/4. We've just posted a short draft on the signaling required to drive a = generic, transport-independent state machine for flow-state-keeping = network devices, as part of the PLUS effort: https://tools.ietf.org/html/draft-trammell-plus-statefulness Aside from the ability to associate packets to flows (generally via = their five-tuple), this approach requires only an association signal (to = indicate a receiving endpoint is interested in keeping a connection = open) and a stop signal (to indicate either endpoint is shutting the = connection down, and that state should be freed). Depending on how the = association signal is encoded, it might also provide information about = the directionality of a flow. We note that QUIC in its current state would need only very small = changes to support this state machine: the Connection ID already works = as an association signal (albeit without directionality), and the Public = Reset facility could be repurposed as a stop signal, if exposed on every = association shutdown, as opposed to just abnormal ones. This would be a first step toward the fulfillment of the charter goal to = ensure that QUIC is manageable; especially as "flow setup and teardown" = signaling is one of the example functions mentioned directly in the = charter. Cheers, Brian --Apple-Mail=_AE9C9754-74FA-4C89-89BC-F0D181795FEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYB/MHAAoJEIoSt78L6kajCGkP/RWvAWIiNnbMa5EPvHLVDTjm prkuOB7TXjhaLXb5EBxeTBjrYPUSIrVnu24PeY4q8hwokQohR8K7D4VRPBzAXila sKa+hQnkf7F+tq5+4a0awCGaDfZjeqRpBBhQ73G8XZSGSnkrjEaPpy/7KRN5ixeN j0oPsIWfA9E7utRVk2C/+7XsgJ+vsoQPXmj041OzSkIPvYKF7JzuYCMqdUwGlLUK 3ce/rKSVY7y2zPLguwaIhcO3I7A4VxkdprvwR7igKCuTA1n0OvZacs5w656pCfaC 0xA7hlLqlyUm9PCOAQN/QbB89WGGXLSY7ZNeH51S7aU653yGQv+g3xrJaIUSVou9 znbuxHhxIGMAH5KrVQRCAmycZpumdN8WMmv+ys31OvFd2pjog/g7SCZYDVO9/RaW RTXCjWZyyTW9ivwAEJay+PfXNLFuiyZHYNHdfx2UrOc1u6qiuvNo9L6/U7irFAEi V+d658+ejON/kBGGF8Y4z3/ArI/sh3p6HTPLOcqLtL1kpVgYvw13M//RPw106D7+ EU5UR/mUcByZZl2fN5pAME7x3bz2QniwWVH2TZmNn7HtDue0uO/of8IFMvIjopJ9 b+h5JNZcheMnUe2dbYpx40eU6WwVcjlVQv1lFQaJ2h4wx4kO9WETc1YSKhAYT3LU Jz6iZuVCYmo+nNVbtjNR =qjDP -----END PGP SIGNATURE----- --Apple-Mail=_AE9C9754-74FA-4C89-89BC-F0D181795FEB-- From nobody Wed Oct 19 19:36:58 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078A129473 for ; Wed, 19 Oct 2016 19:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjLum33Tr3i0 for ; Wed, 19 Oct 2016 19:36:55 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917BA127071 for ; Wed, 19 Oct 2016 19:36:55 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so68840655qkc.2 for ; Wed, 19 Oct 2016 19:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7gPhaKjVk8E0VDv35X5yVqMtmQ4Q7uNV982ZhjQUWvE=; b=KiB5Hxmzurx99gKLhT9Ckxgc13lrU+vWP4PibwNNMXxz8UH7XgY9rPQmJtI9PYB8qb c5rhM/bay25oDfcY2Ut/ojDWPaQCa/oa0NBNgqT6npVDOS1e2eKP76GOA2cW3xeD5wB9 dI/B2LdRbilMYJFsuAKtaKyOSCYv8JhwsskGFihXpEuCVpFycEONZQsGKBsABnLZKf9M b2ip4+27JoL70gJS/8//cTaocb2oj8l6GO7flqNt2u0hIo2kMoOLshRdrVSiYnpl8p5C 20Iqw/2VRs2YCoZIwIDYu4TeTaXAYkFC5BqNG5QSsgRLJptEHyMQORmVRkrvmlv1u6lF jxMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7gPhaKjVk8E0VDv35X5yVqMtmQ4Q7uNV982ZhjQUWvE=; b=dcUwvv0b0cH0kUKS8KUm89t4cJeT3j/3Y3wK6i6ITXDBiKiQ8Fr8fEmjueqIjRm/yx Tog0PTbfXq6SM+4A1cb5xPxNYxj+Nt7hEUuOIlfrbk0UWexka6k1ZHN9Q+Z79ihadR6h G/MwR2UndMn6Vit+kV7m1685TTaka94sYpofksf5WqmdjPzYACFuIbjeW8FqzMAaj9f6 3wo9pGsJCs6cpcSu6nbzRDCCrKCGZprHKZrVFSlgeLllsAgq8WsJhE3juXv9rOfC0N0q SWpJmzCR8gDgwOYLTL0YwtIjVjMMkeiwQQdAxne4mVccQMp4bHzjECy/qI7W3il6J+25 3ltA== X-Gm-Message-State: AA6/9Rm4g5+gwTSM3tNy4p8LE0pBD4cUNYOCZLlz8u57e9GJT7WxLxHTPx2U0aQtdt5OegUwVy9G9zDtIKTbcw== X-Received: by 10.55.155.15 with SMTP id d15mr8910936qke.115.1476931014603; Wed, 19 Oct 2016 19:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 19 Oct 2016 19:36:54 -0700 (PDT) In-Reply-To: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> From: Martin Thomson Date: Thu, 20 Oct 2016 13:36:54 +1100 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 02:36:57 -0000 You say: QUIC's cryptographic protocol, to be based on TLS [I-D.thomson-quic-tls], will provide the necessary integrity protection to drive the state machine. This isn't currently true. Any signal that you create will necessarily be outside of the confidentiality protection envelope. We would have to change the packet protection structure so that was added to the AAD. We currently do not use the AAD, so it's a kinda big change. I like the formulation of the association signal idea. This means that you only need to include a connection ID in packet 0. This covers the current mechanism (connection ID in initial packets and the combination of shorter or absent connection IDs and the 5-tuple in later packets). It also suggests the possibility that you might do other things that make things easier or harder depending on where you sit. One possibility is that we could make it difficult to trace backwards along a flow. We could even make it impossible to trace a flow without packet 0..n. Of course, I can't imagine a use case for either. It does suggest that there's a trade-off here though. One thing I'd like to see made a lot clearer is that you are talking about a single flow. There is no requirement for the network to be able to identify packets across disparate flows as belonging to the same connection (for multipath or even just for mobility). I can imagine no good reason to have on-path adversaries being able to correlate flows on different paths (yep, that's a challenge folks, let the counterarguments fly). The main reason being that correlation across flows would defeat some of the traffic analysis defenses we are considering. On 20 October 2016 at 09:26, Brian Trammell wrote: > Hi, all, > > A couple of days ago, in a thread on the network management paragraph in = the charter, I wrote: > >> Indeed, either directionality signaling or end signaling is probably eno= ugh to do most of what most firewalls need at layer 3/4. > > We've just posted a short draft on the signaling required to drive a gene= ric, transport-independent state machine for flow-state-keeping network dev= ices, as part of the PLUS effort: > > https://tools.ietf.org/html/draft-trammell-plus-statefulness > > Aside from the ability to associate packets to flows (generally via their= five-tuple), this approach requires only an association signal (to indicat= e a receiving endpoint is interested in keeping a connection open) and a st= op signal (to indicate either endpoint is shutting the connection down, and= that state should be freed). Depending on how the association signal is en= coded, it might also provide information about the directionality of a flow= . > > We note that QUIC in its current state would need only very small changes= to support this state machine: the Connection ID already works as an assoc= iation signal (albeit without directionality), and the Public Reset facilit= y could be repurposed as a stop signal, if exposed on every association shu= tdown, as opposed to just abnormal ones. > > This would be a first step toward the fulfillment of the charter goal to = ensure that QUIC is manageable; especially as "flow setup and teardown" sig= naling is one of the example functions mentioned directly in the charter. > > Cheers, > > Brian > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > From nobody Wed Oct 19 22:49:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412E81294CA for ; Wed, 19 Oct 2016 22:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGLJHZm8PotL for ; Wed, 19 Oct 2016 22:49:18 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA4C129446 for ; Wed, 19 Oct 2016 22:49:18 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 66so70291098itl.1 for ; Wed, 19 Oct 2016 22:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/4zNi2BMcpGTtDkfbo+THWovbTx6RfjYfRIovE0lo0U=; b=VrbOgGMaU2egQwrZzzcS6cbjptCXJKItGt+Gj469M/qOvhwLQ452cjI13bZz81KVlW 85gGoC+n5nWWn/VjoP412LI1gvBFr3c83Y9rJ50tyC/anvDpmbkxopHdmYAoiJvVLQff hWR8I94ae1slNJCYw0hHXf7WjrRJMFiqw7lMLVlH7uhfifTU8zAQ1LFljOuYuCoQuCQ/ FPGb9mKSSd0ltJrC/pfWxYO+YDDWmuBMf0HUdTZ5LW/GiYU/o0RhKtcySaL79yzIHEU7 35wAHbnMGMqQgQKivm7j8q6eHf+lFRMVLGARaVZ9sCReVF+yNixg3proc0U+nVioMOye Iwug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/4zNi2BMcpGTtDkfbo+THWovbTx6RfjYfRIovE0lo0U=; b=fDaz/jiwnZmyuJJA4TGYf/SPNs5prx2VRvJGPFtT5Om3lZfx1M5QV/FStgKZeZ//lo q0qtF15TQT68Yfhi/8Qd4VRCwqB4Cdhu1dEzVgLi2tIpTdMu5Ssi82p5amxx6HUDtR4E qvP2WRGiSf76W7kdUaDIDwbWtCIL0zl1TirwLOGEYJ3Y0P0RDUISTSR6N8re54TCq65J yr+35gYokb6XUjfTPKPC7g5ixXqwjTThazWiPv9NZ9nMbJJLTHbJIV1F4QwDF/zmgDLw lLtU+8z4SKlYh7hM4eK1UUEOVc8P/IMfDNIHkUxeJ1ZvWzZcIZjjSsj6HRNv8nrI++v4 Dcrg== X-Gm-Message-State: AA6/9RlGm3Uk7fWYW7YbvmKrFkH1QS1dk9p7Q7QVa4RZ0L5KKobYRxnCRVCgAJVn9YTfjWrSiSSpthYJN8gTYQcJ X-Received: by 10.36.108.8 with SMTP id w8mr6656732itb.83.1476942557490; Wed, 19 Oct 2016 22:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.76 with HTTP; Wed, 19 Oct 2016 22:49:16 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 19 Oct 2016 22:49:16 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a11452b167e937a053f457c4a Archived-At: Cc: draft-hamilton-quic-transport-protocol@ietf.org, quic@ietf.org Subject: Re: [QUIC] about draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 05:49:21 -0000 --001a11452b167e937a053f457c4a Content-Type: text/plain; charset=UTF-8 Hi Marcelo, Thanks much again for your detailed read of the document. Reponses inline: On Thu, Oct 6, 2016 at 2:37 AM, marcelo bagnulo braun wrote: > Hi, > > > Thanks for the document. I have been reading draft-hamilton-quic-transport-protocol-00 > and I find it not easy to read, probably because it is an early version and > mostly because of my own limitations. > > I attach a few comments and questions regarding the draft. Hope you find > them useful. > > > Section 3.5 on Stream and Connection Flow control. > > Is the offset announced for the connection the sum of the offsets > announced for each of the stream of that connection? > > If so, it seems redundant to announce both of them, no? > > If it is not, I am uncertain how this would work. If the connection one is > larger than the sum of the streams one, I am not sure how can the sender > use the remaining buffer, since it cannot allocate it any existing stream. > Is this meant to the be used for new streams? If the sum of the streams one > is higher than the connection buffer, then i guess the sender needs to to a > double check, first for available rcv window in the stream and then > available rcv window in the connection. Not sure what is the gain of having > both. Maybe it is worthwhile making explicit in this section why this is > useful? > Yes, like HTTP/2 flow control , the offset is announced at both the connection-level and the stream-level. The general intuition is exactly the same as with HTTP/2 -- that the connection-level window provides an upper bound on the memory commitment at the receiver for this connection. The expectation is that this window will be larger than any one stream's window. This is so that even if one stream were to be blocked (meaning that the receiver was not draining a stream), that stream would not consume the entire receiver buffer and allow other stream(s) to proceed. Does this make sense? This is basically what the text in the draft says, but if you think it can be clarified further, let me know. Section 3.7 on Resilience to NAT Rebinding. > > I assume that the same mechanisms that allow the connection to survive a > nat rebinding would be also useful to support some simple forms of mobility? > > I mean, probably these mechanisms are enough to support the client > changing IP address (for instance when doing a handover from cellular to > wifi)? > > I guess they are not enough to support more complex mobility scenarios, > such as simultaneous movement of both endpoints, but in any case, it may be > worthwhile mentioning this mobility support in this section? > That's correct -- this is enough to handle what we call "connection migration". I was considering making that section heading "Connection Migration and Resilience to NAT Rebinding", so I'll do that. On simultaneous mobility -- I have to think more about this, but it seems plausible with the connection ID as well. Basically, since the key still protects the header (including the connection ID), and proof of ownership of the key should be enough to authenticate the endpoint, so I think this is reasonable. I'll add a note about this to the spec as well. This mechanism isn't adequate to do general-purpose multipath (MPTCP-style) however. That will need more bells and whistles. Section 4.1 on Version Negotiation > > I understand that during version negotiation, the following information is > exchanged: version, version flag, connection ID, and in some cases the > server's supported versions. I understand that all this information is > exchanged before the crypto handshake, so it is exchange in clear text and > without authentication. Since in section 3.6 it is claimed that packets are > always authenticated, I guess we have a (mild) contradiction here (i > understand you verify this later on once the crypto has been exchanged). In > any case, maybe it is worthwhile to explicitly state in this section that > this information is exchanged in plain text and non authenticated. Yes, this is correct. Clarified text: "The version negotiation packet is unencrypted and exchanged without packet-level authentication. Therefore, in order to avoid downgrade attacks, the client and server MUST include their supported versions later in their corresponding crypto handshake data." I've also modified text in 3.6: "Generally, QUIC packets are always authenticated and typically the payload is fully encrypted. The parts of the packet header which are not encrypted are still authenticated by the receiver, so as to thwart any packet injection or manipulation by third parties. Some early handshake packets, such as the version negotiation packet, are not encrypted, but information sent in these unencrypted handshake packets is later verified under crypto cover." Also, the last paragraph of this section states that there are other > transport parameters exchanged in the connection establishment. I assume > that those are exchanged after the crypto, so they are encrypted and > authenticated? Is there any other transport parameter exchanged in clear > text? Probably it would be useful to make this explicit? > Yeah, currently the transport params sent by the client are sent in clear text, but again, later verified since the key derivation includes the handshake packets. This would be a requirement of the handshake protocol. I've added some text in the Crypto Handshake Protocol Features section: "Transport Negotiation: The crypto handshake MUST provide a mechanism for the transport component to exchange transport parameters and Source Address Tokens. To avoid downgrade attacks, the transport parameters sent and received MUST be verified before the handshake completes successfully." > In section 4.2.1.2 on Required Transport Parameters. > > One thing I am missing here (probably because suffering a TCP bias) is the > initial packet sequence number to be used in the connection. > > Do you always use 0 as initial PSN? If so, this is because you assume that > the crypto mechanisms established during the crypto handshake will prevent > packet form previous connections to re-emerge later on and be confused for > packets in the new connection? If this is the case, maybe you should state > it explicitly in section 4.2.3? > Correct. Zero is always the initial PSN, and yes, there should be no confusion with packets from other (previous) connections, since the key for this connection should be different. This should be a requirement of the crypto handshake, so thanks for pointing it out. I've added the following to section 4.2.3: "The crypto handshake MUST ensure that the final negotiated key is distinct for every connection between two endpoints." > However, from reading section 4.2.2 it seems that multiple connections > between two endpoints can reuse the same crypto material, is that the case? > > In this case, does each connection uses 0 as initial PSN? How can you > guarantee in this case that old packets with same PSN will no re surface > and appear as packet of a new connection, since they can be using the same > PSN? > Multiple connections do not share the same final crypto key. What in Section 4.2.2 led you to believe that? I'll respond to the rest of the comments tomorrow. Thanks again, - jana --001a11452b167e937a053f457c4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,

Thanks much again for you= r detailed read of the document. Reponses inline:

On Thu, Oct 6, 2016 at 2:37 AM, marce= lo bagnulo braun <marcelo@it.uc3m.es> wrote:
Hi,


Thanks for the document. I have been reading draft-hamilton-quic-transport-= protocol-00 and I find it not easy to read, probably because it is an = early version and mostly because of my own limitations.

I attach a few comments and questions regarding the draft. Hope you find th= em useful.


Section 3.5 on Stream and Connection Flow control.

Is the offset announced for the connection the sum of the offsets announced= for each of the stream of that connection?

If so, it seems redundant to announce both of them, no?

If it is not, I am uncertain how this would work. If the connection one is = larger than the sum of the streams one, I am not sure how can the sender us= e the remaining buffer, since it cannot allocate it any existing stream. Is= this meant to the be used for new streams? If the sum of the streams one i= s higher than the connection buffer, then i guess the sender needs to to a = double check, first for available rcv window in the stream and then availab= le rcv window in the connection. Not sure what is the gain of having both. = Maybe it is worthwhile making explicit in this section why this is useful?<= br>

Yes, like=C2=A0HTTP/2 flow control, the offse= t is announced at both the connection-level and the stream-level. The gener= al intuition is exactly the same as with HTTP/2 -- that the connection-leve= l window provides an upper bound on the memory commitment at the receiver f= or this connection. The expectation is that this window will be larger than= any one stream's window. This is so that even if one stream were to be= blocked (meaning that the receiver was not draining a stream), that stream= would not consume the entire receiver buffer and allow other stream(s) to = proceed.

Does this make sense? This is basically w= hat the text in the draft says, but if you think it can be clarified furthe= r, let me know.


Section 3.7 on Resilience to NAT Rebinding.

I assume that the same mechanisms that allow the connection to survive a na= t rebinding would be also useful to support some simple forms of mobility?<= br>
I mean, probably these mechanisms are enough to support the client changing= IP address (for instance when doing a handover from cellular to wifi)?

I guess they are not enough to support more complex mobility scenarios, suc= h as simultaneous movement of both endpoints, but in any case, it may be wo= rthwhile mentioning this mobility support in this section?
=

That's correct -- this is enough to handle what we = call "connection migration". I was considering making that sectio= n heading "Connection Migration and=C2=A0Resilience to NAT Rebinding&q= uot;, so I'll do that.=C2=A0

On simultaneous m= obility -- I have to think more about this, but it seems plausible with the= connection ID as well. Basically, since the key still protects the header = (including the connection ID), and proof of ownership of the key should be = enough to authenticate the endpoint, so I think this is reasonable. I'l= l add a note about this to the spec as well.

This = mechanism isn't adequate to do general-purpose multipath (MPTCP-style) = however. That will need more bells and whistles.

<= br>
Section 4.1 on Version Negotiation

I understand that during version negotiation, the following information is = exchanged: version, version flag, connection ID, and in some cases the serv= er's supported versions. I understand that all this information is exch= anged before the crypto handshake, so it is exchange in clear text and with= out authentication. Since in section 3.6 it is claimed that packets are alw= ays authenticated, I guess we have a (mild) contradiction here (i understan= d you verify this later on once the crypto has been exchanged). In any case= , maybe it is worthwhile to explicitly state in this section that this info= rmation is exchanged in plain text and non authenticated.

Yes, this is correct. Clarified text: "The version neg= otiation packet is unencrypted and exchanged without packet-level authentic= ation. Therefore, in order to avoid downgrade attacks, the client and serve= r MUST include their supported versions later in their corresponding crypto= handshake data."

I've also modified text= in 3.6: "Generally, QUIC packets are always authenticated and typical= ly the payload is fully encrypted. The parts of the packet header which are= not encrypted are still authenticated by the receiver, so as to thwart any= packet injection or manipulation by third parties. Some early handshake pa= ckets, such as the version negotiation packet, are not encrypted, but infor= mation sent in these unencrypted handshake packets is later verified under = crypto cover."

Also, the last paragraph of this section states that there a= re other transport parameters exchanged in the connection establishment. I = assume that those are exchanged after the crypto, so they are encrypted and= authenticated? Is there any other transport parameter exchanged in clear t= ext? Probably it would be useful to make this explicit?

Yeah, currently the transport params sent by the client ar= e sent in clear text, but again, later verified since the key derivation in= cludes the handshake packets. This would be a requirement of the handshake = protocol. I've added some text in the Crypto Handshake Protocol Feature= s section: "Transport Negotiation: The crypto handshake MUST provide a= mechanism for the transport component to exchange transport parameters and= Source Address Tokens. To avoid downgrade attacks, the transport parameter= s sent and received MUST be verified before the handshake completes success= fully."
=C2=A0
In section 4.2.1.2 on Required Transport Parameters.

One thing I am missing here (probably because suffering a TCP bias) is the = initial packet sequence number to be used in the connection.

Do you always use 0 as initial PSN? If so, this is because you assume that = the crypto mechanisms established during the crypto handshake will prevent = packet form previous connections to re-emerge later on and be confused for = packets in the new connection? If this is the case, maybe you should state = it explicitly in section 4.2.3?

Correct= . Zero is always the initial PSN, and yes, there should be no confusion wit= h packets from other (previous) connections, since the key for this connect= ion should be different. This should be a requirement of the crypto handsha= ke, so thanks for pointing it out. I've added the following to section = 4.2.3: "The crypto handshake MUST ensure that the final negotiated key= is distinct for every connection between two endpoints."
= =C2=A0
However, from reading section 4.2.2 it seems that multiple connections betw= een two endpoints can reuse the same crypto material, is that the case?

In this case, does each connection uses 0 as initial PSN? How can you guara= ntee in this case that old packets with same PSN will no re surface and app= ear as packet of a new connection, since they can be using the same PSN?

Multiple connections do not share the sam= e final crypto key. What in Section 4.2.2 led you to believe that?

I'll respond to the rest of the comments tomorrow.

Thanks again,
- jana
--001a11452b167e937a053f457c4a-- From nobody Thu Oct 20 03:19:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491D8129577 for ; Thu, 20 Oct 2016 03:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBk_ebFGJom6 for ; Thu, 20 Oct 2016 03:19:22 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1FCC129569 for ; Thu, 20 Oct 2016 03:19:21 -0700 (PDT) Received: from public-docking-cx-1688.ethz.ch (public-docking-pat-cx-mapped-0026.ethz.ch [195.176.111.27]) by trammell.ch (Postfix) with ESMTPSA id E52B01A029B; Thu, 20 Oct 2016 12:19:20 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_59841200-BA3A-4119-922F-FCBB739080FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 20 Oct 2016 12:19:20 +0200 Message-Id: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 10:19:24 -0000 --Apple-Mail=_59841200-BA3A-4119-922F-FCBB739080FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all, > On 20 Oct 2016, at 04:36, Martin Thomson = wrote: >=20 > You say: >=20 > QUIC's cryptographic protocol, to be based on TLS > [I-D.thomson-quic-tls], will provide the necessary integrity > protection to drive the state machine. >=20 > This isn't currently true. Any signal that you create will > necessarily be outside of the confidentiality protection envelope. We > would have to change the packet protection structure so that was added > to the AAD. We currently do not use the AAD, so it's a kinda big > change. Right, but aren't all the QUIC header bits also integrity-protected? > I like the formulation of the association signal idea. This means > that you only need to include a connection ID in packet 0. You *could* do this, at the expense of having to do a fast-reset = (resending the connection ID, to cause a connection ID echo) if you = detect connection disruption due to state loss (restart) of a device on = path. This is no better than the behavior of TCP with stateful firewalls = that need to see a SYN. > This > covers the current mechanism (connection ID in initial packets and the > combination of shorter or absent connection IDs and the 5-tuple in > later packets). It also suggests the possibility that you might do > other things that make things easier or harder depending on where you > sit. Yep. We tried to define association signals in the abstract to carry the = *minimum* possible information. If a protocol piggybacks association on = other information it radiates, there are of course tradeoffs in the = other things you want to do with that information. > One possibility is that we could make it difficult to trace backwards > along a flow. We could even make it impossible to trace a flow > without packet 0..n. Of course, I can't imagine a use case for > either. It does suggest that there's a trade-off here though. Yep. > One thing I'd like to see made a lot clearer is that you are talking > about a single flow. Hm, I was pretty sure that was already pretty clear, what with leading = off the terminology section with the definition of a Flow cribbed from = 7011. Text suggestions welcome :) > There is no requirement for the network to be > able to identify packets across disparate flows as belonging to the > same connection (for multipath or even just for mobility). I can > imagine no good reason to have on-path adversaries being able to > correlate flows on different paths (yep, that's a challenge folks, let > the counterarguments fly). The main reason being that correlation > across flows would defeat some of the traffic analysis defenses we are > considering. Agreed completely, noting that traffic analysis defense is extremely = hard to do if you have latency and bandwidth efficiency requirements = too. That's not a reason to make it easier for no reason, though. Cheers, Brian > On 20 October 2016 at 09:26, Brian Trammell wrote: >> Hi, all, >>=20 >> A couple of days ago, in a thread on the network management paragraph = in the charter, I wrote: >>=20 >>> Indeed, either directionality signaling or end signaling is probably = enough to do most of what most firewalls need at layer 3/4. >>=20 >> We've just posted a short draft on the signaling required to drive a = generic, transport-independent state machine for flow-state-keeping = network devices, as part of the PLUS effort: >>=20 >> https://tools.ietf.org/html/draft-trammell-plus-statefulness >>=20 >> Aside from the ability to associate packets to flows (generally via = their five-tuple), this approach requires only an association signal (to = indicate a receiving endpoint is interested in keeping a connection = open) and a stop signal (to indicate either endpoint is shutting the = connection down, and that state should be freed). Depending on how the = association signal is encoded, it might also provide information about = the directionality of a flow. >>=20 >> We note that QUIC in its current state would need only very small = changes to support this state machine: the Connection ID already works = as an association signal (albeit without directionality), and the Public = Reset facility could be repurposed as a stop signal, if exposed on every = association shutdown, as opposed to just abnormal ones. >>=20 >> This would be a first step toward the fulfillment of the charter goal = to ensure that QUIC is manageable; especially as "flow setup and = teardown" signaling is one of the example functions mentioned directly = in the charter. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >>=20 --Apple-Mail=_59841200-BA3A-4119-922F-FCBB739080FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYCJooAAoJEIoSt78L6kaj2s4P/18KSbE9wu2QwZohk2kNeZew rt2jNgTL1Sfkar5kpGVdPkk0Cse+FYWCnBPJl1r5x3AVOvQgQuMPhFRoV86eFOsW Ffa1ekZ2TllrIVEldFs84KhI4vetyKS8YK1lU+sh3UvxS9vSYuV0NEVMyMLTISnu XQdW/DOTlTlqlBr8mCxfQH297zTWky+G9KP4NNLpTw76Bgrq+KxCZ7HTSwHgie83 sbuhf61SEwZlRrXB+h/gl6bsOVmA8j5uMhQF3Ogv/sthj659gfSGEsoIkIJu0sCA e58btE1znsoFEt53cdg4amjI/k8gi1X24TuKR14DK3Y+lrgWhLvrmCiyKDjpQQps zTVNA8Ubx1aWrGwsIEvySL2Hu4zgWKzC2E6ilcoDpe6Rr3XkbpE50MxZR5mFg/ik g+cq00L2smuDwJGx5sgwv/wT7VEwKQF1yW2gU9NlqJ+yWFhlQWaAD2Y3tOkNga+z ZM0NQ5opSJk0loT49kO55pawQtTYLV8fvkaG7NscnHLkuMzzw8sm09DmJ6p/MqLK 6DhgRdkdHe4MjPmXkcN9yqeI+WqY6W+9IzTPfFHe8ff3VqA96lSiHrwmw3ivyH1v 3UrkgKUiOT4I1gNga8JRzkl3w52gd6Zavyfq/19BqnGKyyrDKrqsqVccHMrOc8Ty sq76rCrE9okkiB3T0nH0 =A2fG -----END PGP SIGNATURE----- --Apple-Mail=_59841200-BA3A-4119-922F-FCBB739080FE-- From nobody Thu Oct 20 03:43:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26551295AB for ; Thu, 20 Oct 2016 03:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxBPby6ODsA4 for ; Thu, 20 Oct 2016 03:43:18 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85F41295A6 for ; Thu, 20 Oct 2016 03:43:17 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o68so85761085qkf.3 for ; Thu, 20 Oct 2016 03:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TABPg3hv9p8fnwsXFNFyQn6cRgr/ZWurX+9iEXBYyxo=; b=nwoAwMqNK4XTSdk5TRLR7jDrOObTGDQwD6F2YD9KCMC+Qy4bih5sJw263stsK7OKeA 9omuQxDZEV0qXWRYJocnZPeuRV5r1aqlF4LKhXV+F0cMw1MXGUcNtL+UgY7+1gUDRxY9 UE3GTQ662xUeaq+LyaxoisjwYL4wJV9xIQc1elUdSaoCZ272p3UtleFNDkscWc/bIDA3 I0hWJKos4q2ROwh50OuMQl9gTrxV+Sy+i5mtkKFPkavFc58Lu8KFs0PR+Z6d5b5/2XE5 J08RHQ3cDAP6uZ+bAJYzvmrCiFlZMh8uam8QLVexcvBcNcVcmibNdr1rMcI+rfTiE+2V xh3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TABPg3hv9p8fnwsXFNFyQn6cRgr/ZWurX+9iEXBYyxo=; b=lQvIUYa3zvr2i/7S3Zs7zx4wbpSObfPSp6PTFBajZN3MmNsYgdApm6gQ2bwWFlXuU1 v9sDBy7NmthXhuUgWsiQXIltCIVu8BgOZGspN8zF7+la+CIRhm0hhCFcOlQZHsFZ5aSC dJ8vcHyDWmKF1L84AIDZsmZVceZ6LcBz9Zn/8c0sEkORPs0jqiYm/RI4eSqG8FHtJ4h3 aNXLk3hW+6qvmX3M/bRU14pe2CYdGAERZ2958Lm916MRLuJv5KVw7zVOc8X35ZpERs8S uY5VOcYbFZpqwHircEd4SER3g2rzVtoOqhCJjhj08HUWmx1hAyc887RjI9zoRTxB70Db 9Nsg== X-Gm-Message-State: AA6/9Rmft17x6/ereYuIcBDVKvfAGnYYWhjuBtx0jA45x9vXVB23vVKIUTjnxvI/wnRUcyIqt9eTFzRE5dePVQ== X-Received: by 10.55.155.15 with SMTP id d15mr10299939qke.115.1476960196950; Thu, 20 Oct 2016 03:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 03:43:16 -0700 (PDT) In-Reply-To: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> From: Martin Thomson Date: Thu, 20 Oct 2016 21:43:16 +1100 Message-ID: To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 10:43:21 -0000 Lifting a choice piece. On 20 October 2016 at 21:19, Brian Trammell wrote: > Right, but aren't all the QUIC header bits also integrity-protected? Let's quickly assess these: 1. connection ID - routing critical, so I didn't see a need for protection (though we would roll it into the handshake if it was needed - most fall into this category) 2. version - rolled into the handshake 3. sequence number - forms the nonce (see TLS for analysis of this) 4. public reset etc... - can't I realize now that I didn't write down the analysis of the first, so that could be wrong. Just thinking about this, if you signal end-of-flow in the clear and use the same techique for integrity as the version (corroboration rather than a cryptographic device), you can watch for a close_notify alert in the TLS to corroborate the cleartext signal. But that leads me to ask: how do you signal end-of-flow here? The close_notify will be reliable and therefore subject to repair. But if the middlebox sees the first close_notify with the cleartext end-of-flow marker, your model has it transition immediately to the zero state. I don't think that's a good outcome. If the close_notify is actually lost we don't have an authenticated end to communications. Sure, that's much less of a problem from a robustness perspective with the solid stream semantics in h2/quic, but it might lead to clients attempting to repair a connection that is unwanted. Enter TIME_WAIT. From nobody Thu Oct 20 07:11:35 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9F129567 for ; Thu, 20 Oct 2016 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuqwV_c4ouXN for ; Thu, 20 Oct 2016 07:11:29 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DC2129571 for ; Thu, 20 Oct 2016 07:11:26 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b75so83832985lfg.3 for ; Thu, 20 Oct 2016 07:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x4a7mzhb9bohOtDRlnn3rQxjyYJahGhryVesUNRS1rE=; b=LQ76upFGwxUXlTl/jzpNSHsYxrqiqKgooqgoUbOE/n/M3DWJhOjuxikbT+0fxqWovS KARW1tHi5W6WLudakQohDNay9rCzuPpaXIpZAbyzWijnSaRKt1a6ETRW2fwb7dnqUofi NPR0Py3js8EqPA+MOZa94oBXvo7eGO5aD+36nZ5xRqxqP4jxtoC2sy4vJWIDUNzMb3gp vtT7h0gnj43qEZmp8109AzdO8n1vF4+i6k3YxORqUbs4ewQD6oqUf0dVeu4qsyNWr9Q0 fK+O/H4/u2jttHXFfamWV1Ex1lCvik3e26Y5vuSnNmCUMJhma8bgjeRfBVGka4nw33/Q kElA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x4a7mzhb9bohOtDRlnn3rQxjyYJahGhryVesUNRS1rE=; b=fQyLUBsnxeBQzw9Qtc4K7qckKDxumeBhQ/egc7EHDMPz2Gt7cQ1qKeoomPJ5QHmAb0 2hmCmZlUm/vxiPIN1x4CnzYXJ5zCpn5/oxK/bdkr6Ipb4HDQtETt49w3oXEec6F5APyB tyWrHZEIJj6EEsnqz2peJ+RnTOW6GmWDRvegGLqtrN5haKvid3Jrei5ZNG9hmwKgyCSH 4C/HuuYVQQP4sWHq3i2kxqUX/pvW1z+MTqZNd/n/fnwstS+znM+kBivH6E9kJvq2UBM2 hF24V2RbIAH8HYkogQsk0NMMPvXxjOArBhq/8uepx3NZxETOFhaguaDEBFQHYP4q4hkI dbrQ== X-Gm-Message-State: AA6/9RnAdLciobbDD13n1oPCGgwVmcnpcqJx5cKIhyC+UqGLaT83cLdpgiUR5EcECzN5Ft0qRxnczPGEDtcl/1m6 X-Received: by 10.28.32.70 with SMTP id g67mr6212252wmg.94.1476972682973; Thu, 20 Oct 2016 07:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.199 with HTTP; Thu, 20 Oct 2016 07:11:22 -0700 (PDT) In-Reply-To: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> From: Ryan Hamilton Date: Thu, 20 Oct 2016 07:11:22 -0700 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a113d79ae1ceb34053f4c8013 Archived-At: Cc: "quic@ietf.org" , Martin Thomson Subject: Re: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 14:11:34 -0000 --001a113d79ae1ceb34053f4c8013 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2016 at 3:19 AM, Brian Trammell wrote: > Right, but aren't all the QUIC header bits also integrity-protected? > Yes indeed. All of the public QUIC header bits are integrity protected with the current code. I believe the plan with TLS is to provide the same integrity protect, just using the key derived during the TLS handshake. Of course, this only applies to post-handshake packets. =E2=80=8B --001a113d79ae1ceb34053f4c8013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 20, 2016 at 3:19 AM, Brian Trammell <ietf@tram= mell.ch> wrote:
Right, but aren't all the Q= UIC header bits also integrity-protected?

<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">Yes indeed. All of the public QUIC header bits are integrity pro= tected with the current code. I believe the plan with TLS is to provide the= same integrity protect, just using the key derived during the TLS handshak= e. Of course, this only applies to post-handshake packets. =E2=80=8B
<= br>
--001a113d79ae1ceb34053f4c8013-- From nobody Thu Oct 20 19:49:16 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A391294E9 for ; Thu, 20 Oct 2016 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gutnyEZSAYx2 for ; Thu, 20 Oct 2016 19:49:11 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD231288B8 for ; Thu, 20 Oct 2016 19:49:11 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 139so198559524itm.1 for ; Thu, 20 Oct 2016 19:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pYJIXV8hEds68+rgzCXfJz2y4I0SZ/n+w6XiF6PvFoM=; b=CIwk8oGEJsXIcZuVfaozHOJlmmtzaDpMTmOodfbmF/cGpc7VhzcgeZ7D6JB86lwB9Q ym1ebB8RFS9XLZ8lLVV8QkDVh6YldKymcR5BiQpiMk9QmNU8qqac27jhLMcQsNC4ffj0 rVC8rRYPLfIhpFjflSQscMzeR9Qo4xZu8/GYfYZKmjf+qAHg8MkiaBZpXUSpG74ie4zU ykjBCNJ62hXkB4o7q1e15rc0JA+O0FaV+/rUO8QB/XvnEsgozDgfyr91Z1GJQVX+b/ae cGxZjM7tQQFv9YvudVuZ9F1CfDQtVo5bQvxQqOxp7QPgabBoaNgIUVTBqt2rDaPcvVjG Ayow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pYJIXV8hEds68+rgzCXfJz2y4I0SZ/n+w6XiF6PvFoM=; b=MQwq2xc9EgtDASxenQwyMpz3BqOxJ4QbuN6ePnoZ0vL/o4BZ/PglAAqk8xDuCK16+I ROee6dyML64m4XYDCZ0E+cGzaodHFezuCxqv3PI+YtusKiQ1uVV1FEe9wHPr2e4dYwU2 OWCm8MgCrD9MXFyhQmD/8BlCITz3qloDeWuM5xaAoZpbeq8JZUYRKyt8ibBM++ZIgIU9 KR6K8D1KrENzSf74mVGDjsL5prPEyATtqdcjCN7//7BL7RJzvIlgbpXNkpkbRVkqAwEZ dSrqiU6j95LYCDuXfXEYoTlhTnSjCqcyeEULPBG0BiIKK1YOvad3i8YeJRYfpYF8CXJC hNaQ== X-Gm-Message-State: ABUngvd0fm5t7T0Jf7rmf8wJ83kHfEi6UEz1xjtf0k72S+j5BFuBykcwd5HED7xhCrTFhYZ3LkEdUDO2EDBiYeYg X-Received: by 10.107.44.17 with SMTP id s17mr4145991ios.212.1477018150005; Thu, 20 Oct 2016 19:49:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.76 with HTTP; Thu, 20 Oct 2016 19:49:09 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 20 Oct 2016 19:49:09 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a113ee41628e139053f5716cd Archived-At: Cc: draft-hamilton-quic-transport-protocol@ietf.org, quic@ietf.org Subject: Re: [QUIC] about draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 02:49:15 -0000 --001a113ee41628e139053f5716cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Marcelo, Thank you again for your really careful and deep dive in to the spec! Responses for rest of the comments inline: Section 4.2.2 on Proof of Source Address Ownership. > > I understand that the STK provides less protection than a reachability > check at the beginning of each connection, correct? > The STK provides proof of IP ownsership. A client includes the source address token (which was issued by the server to it in a previous connection) to demonstrate ownership of it's IP address. If the client has moved to a different IP address, if the token is too old, or if the client doesn=E2=80=99t have a token, then the server rejects the connection and is= sues a fresh token to the client. This is very similar to TFO's cookie, as the draft notes. I mean, the STK proves that the client was once in that location and it can > later leave the location and because it still has the STK, it can, by > spoofing the source address, pretend to still be there, since only the ST= K > is enough to pass this test. > > This means that for instance, an attacker can download a large file by > simply sending paced ACKs to any location it once was (given that the PSN > initial number is always 0, it doesnt even needs to guess the PSNs), > correct? > > Maybe this is acceptable, but maybe it is worthwhile stating it in the > security considerations section? > Yes, this is a legitimate attack vector. I'll note (also in the draft) that there are two simple mitigations. I've added the following text in Security Considerations. Make sense? " Spoofed Ack Attack An attacker steals the victim's STK, spoofs the victim's IP, and initiates a 0-RTT connection with a server on the victim's behalf. The attacker then spoofs ack packets to the server which cause the server to potentially drown the victim in data. There are two possible mitigations to this attack. The simplest one is that a server can unilaterally create a gap in the PSN space. In the non-attack scenario, the client will send back NACKs for the PSNs in the gap, but the server will eventually send a STOP_WAITING frame for those packets. In the attack scenario, the attacker may ack a packet in the gap. If the server sees an ack for a packet that was never sent, the connection can be aborted= . The second mitigation is that the server can require that acks for sent packets match the encryption level of the sent packet. This mitigation is useful if the connection has an ephemeral forward-secure key that is generated and used for every new connection. If a packet sent is encrypted with a forward-secure key, then any acks that are received for them must also be forward-secure encrypted. Since the attacker will not have the forward secure key, the attacker will not be able to generate forward-secure encrypted ack packets. " Section 4.2.3 on Crypto Handshake Protocol features > > In the bullet about Connection establishment in 0-RTT, it requires 0-RTT > connection establishment for subsequent connections between the same two > endpoints, in the subsequent connections, the client and server roles mus= t > be preserved or they can be changed? I mean, suppose that host A initiates a quic connection to host b. Does > this condition requires that a future connection (with the same ports) > initiated from host b to host A should be established in 0-RTT? > > I think this should be made explicitly because mixed with the STK, I > believe it changes the threat model significantly. > The presumption certainly was that the roles are preserved. With QUIC's current (non-TLS) crypto handshake, there are very clear roles, and I believe that TLS also has a clear expectation of client/server roles. That said, I think this consideration belongs in either the TLS mapping document (or in TLS itself) since that document should handle any threat models that arise from it's 0-RTT implementation with an STK and/or TFO cookie. Is there any clarification that you think might be useful to add to the crypto handshake requirements section? > Nit: the paragraph on the bullet on Server Config Update is truncated. > Removed the truncated sentence -- thanks! Section 5.1 on Life of a stream. > > It states that quic accommodates the possibility of out-of-order delivery= . > Do you mean out of order delivery within the same stream or across stream= s? > clarify? > Across streams. I've changed the text to: "the possibility of out-of-order delivery due to the use of multiple streams in QUIC" I understand that the creation of a stream is very lightweight and a new > stream is established by simply data with a new stream id, correct? > Correct. > I also understand that the initial stream sequence number is always 0, > correct? (I mean, the offset of the current data to the beginning of the > streams is included, and the initial packet has offset 0). > Correct. > So, similar to the question i posed about the initial PSN, how does quic > prevent old packets to reappear and be confused as being part of the new > stream while they were part of an older stream? It cannot be done using t= he > offset, since for all connection it starts in 0. I guess it could be done > using the PSN, but then the receiver needs to check that all PSN of packe= ts > for a new stream are higher than the PSN of the packet that terminated th= e > older stream, is this the proposed approach? Probably it is worthwhile clarifying what are the means that quic deals > with old packets re emerging after the connection/stream has ended, given > that it does not relies on the sequence number to do so, afaict. > Within the connection, the Section 5.2 says " A QUIC endpoint MUST NOT reuse a StreamID on a given connection," so such STREAM frames will be considered duplicates. Do you think this can be clarified better somewhere? > In particular, in section 5.1.1 it states that a stream is open by sendin= g > or receiving a data packet with that particular stream ID. I assume that > the data packet MUST contain a 0 offset to create the new stream? is this > correct? > Not necessarily, since the packet containing a STREAM frame with a 0 offset may have been dropped in the network. A STREAM frame with an offset > 0 may be accepted, but the data will not get delivered to the application until the intiial gap within the stream is filled. Section 5.2 on Stream Identifiers. > > I guess you should reserve a range of identifiers for future use, in case > other "special" streams are needed in the future? > I'm not sure what the point of reserving any would be, since if a special stream is needed in the future, this usage can be negotiated with either an option or with a version change. Section 5.4 on Sending and Receiving data. > > Is the initial offset for the data packet sent on a stream set to zero? I= f > this is the case, would be good to state it. > I've added this sentence: "The first byte of data that is sent on a stream has the stream offset 0." Section 6. on Packetization and reliability. What is the initial PSN in a > given connection? State it explicitly. > Added "The initial PSN used, at both the client and the server, MUST be 0. That is, the first packet in both directions of the connection MUST have a PSN of 0." > It is stated that a sender MAY wait for a short period of time to bundle > multiple frames. I guess it would be useful to provide guidance on what y= ou > consider a short period of time. Is that 500ms as in the delayed acks or > are you thinking much less? > MUCH less. This is definitely a MAY, and I am not sure if recommending something here makes sense, since the expectations in any deployment will be different about how much waiting makes sense. How's the following: "An implementation may use heuristics about expected application sending behavior to determine whether and for how long to wait. This waiting period is an implementation decision, and an implementation should be careful to delay conservatively, since any delay is likely to increase application-visible latency." Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not > be retransmitted, but all other frames must be retransmitted. This implie= s > than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i a= m > not sure if this makes sense. I mean, maybe there were other WINDOW_UPDAT= E > frames than were sent after this one so retransmitting this one probably > doesnt make sense, since the information it contains may be stalled, no? > You're correct that WINDOW_UPDATE and BLOCKED frames are retransmitted. It's hard to construct a scenario however where a WINDOW_UPDATE frame keeps getting dropped, but the client still sends enough data to cause a new revised WINDOW_UPDATE frame to be sent... I agree that in this case the sender would be retransmitted useless information, but I don't think we need to optimize for this case. I still dont understand why having both connection and stream flow control > is useful. I would assume that only stream flow control would be useful. = Or > having one or the other in a given connection, but i fail to understand w= hy > is useful to have both of them simultaneously in the same connection. > I've answered this above, let me know if there's more clarification that can be had in the doc. Section 6 states > > Regular QUIC Packets are "containers" of frames; a packet is never > retransmitted whole, but frames in a lost packet may be rebundled and > transmitted in a subsequent packet as necessary. > > So, let me see if i understand this. > > This means that if the sender sends packet with PSN 5, and if the packet > is lost (i.e. there is a timeout for that packet), the packet with PSN 5 > NOT retransmitted. the frames in the packet with PSN 5 are then > retransmitted in other packets with other PSN (other than 5). If this > correct? > Correct. > This means that there will be holes in the sequence of packets received b= y > the receiver i.e. any packet that get's lost, is simply lost and will nev= er > be received by the receiver. Am i understanding this correctly? > Correct. > A receiver acknowledges receipt of a received packet by sending one > or more ACK frames containing the PSN of the received packet. To > avoid perpetual acking between endpoints, a receiver MUST NOT > generate an ack in response to every packet containing only ACK > frames. > > Does this means that ACKs transmission is unreliable, correct? > Correct. > Since packets are never retransmitted with the same PSN, this basically > means that if an ACK is lost, then the sender gives up on this packet and > eventually will retransmit the data in other packets with a different PSN= , > correct? > Correct. > > Section 7.1.1 on Mid-stream RST_STREAM > > After a RST, when the stream identifier can be reused? probably some > guidance about this would be useful. > As I clarified above, a stream ID can never be reused. Section 7.1.4. > > Is the BLOCKED frame reliably transmitted? I assume it is, but, does it > make sense? > Yes, it is reliably transmitted. > I mean, if a sender sends a blocked frame and it get's lost, but after > that the receiver open the window, then retransmitting the BLOCKED frame = is > not useful (doesnt harm neither i guess) > > OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly > window syndrome? > The BLOCKED frame is really a debugging frame... it's good to know at the receiver that the sender was flow control blocked. Since the receiver is expected to have sent a WINDOW_UPDATE well in advance, and since the BLOCKED frame is not a required part of the flow control machinery, it doesn't cause SWS. It's currently required for the sender to send, but not required to be processed by the receiver beyond maybe logging it somewhere. I've modified the text in Section 7.1.4 to say: "If a sender does not receive a WINDOW_UPDATE frame when it has run out of flow control credit, the sender will be blocked and MUST send a BLOCKED frame. A BLOCKED frame is expected to be useful for debugging at the receiver. A receiver SHOULD NOT wait for a BLOCKED frame before sending with a WINDOW_UPDATE, since doing so will cause at least one roundtrip of quiescence. For smooth operation of the congestion controller, it is generally considered best to not let the sender go into quiescence if avoidable. To avoid blocking a sender, and to reasonably account for the possibiity of loss, a receiver should send a WINDOW_UPDATE frame at least two roundtrips before it expects the sender to get blocked." Is that clearer? I guess we could do what TCP does i.e. periodically transmit the BLOCKED > msg when there is no window (which is different from reliably transmittin= g > the BLOCKED message, since it is periodically sent only when the window i= s > 0) > > > Section 8 on connection termination > > After a connection close, does the same stream identifier can be reused > for a new connection? shouldnt also be a hold time to avoid delayed packe= ts > of the old connection? How much time would be safe? > Do you mean Connection ID? Again, since the expectation is that the keys will be different. Of course that depends on the KDF, but that depends on the crypto protocol in use. I think the clarification that I added above to the crypto requirements should be enough. What do you think? > Section 10.4 > > I understand ACK frames are unreliably transmitted. > > Also, I understand that packets are never retransmitted with the same PSN= . > So, if a packet is lost, there will be a hole in the receiver for that PS= N > and the data will be sent in other packets with othew PSN. Hence, you > cannot have cummulative acks. > Correct. > So, this means that it is possible for a packet to be received by the > receiver but that all the ACKs for that packet to be lost on the way back > and then the sender will timeout and retransmit, right? (I guess that is > ok, since data will be retransmitted in other packets) > Correct. > Let me verify that I understand when a stop waiting frames should be sent > by the sender. I guess that a sender should send a given PSN X in a stop > waiting frame if all the packet with PSN lower than X have been received = or > have timed out, correct? > Correct. I would say when all PSNs <=3D X are no longer considered in fligh= t. Thanks again, - jana > Regards, marcelo > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a113ee41628e139053f5716cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi M= arcelo,

Thank you again for your really careful and deep dive in to the spec! Res= ponses for rest of the comments inline:
Section 4.2.2 on Proof of Source Address Ownership.

I understand that the STK provides less protection than a reachability chec= k at the beginning of each connection, correct?

The STK provides proof of IP ownsership. A client includes the sou= rce address token (which was issued by the server to it in a previous conne= ction) to demonstrate ownership of it's IP address. If the client has m= oved to a different IP address, if the token is too old, or if the client d= oesn=E2=80=99t have a token, then the server rejects the connection and iss= ues a fresh token to the client. This is very similar to TFO's cookie, = as the draft notes.

I mean, the STK proves that the client was once in that location and it can= later leave the location and because it still has the STK, it can, by spoo= fing the source address, pretend to still be there, since only the STK is e= nough to pass this test.

This means that for instance, an attacker can download a large file by simp= ly sending paced ACKs to any location it once was (given that the PSN initi= al number is always 0, it doesnt even needs to guess the PSNs), correct?
Maybe this is acceptable, but maybe it is worthwhile stating it in the secu= rity considerations section?

Yes, this = is a legitimate attack vector. I'll note (also in the draft) that there= are two simple mitigations. I've added the following text in Security = Considerations. Make sense?
"
Spoofed Ack Attack
An attacker steals the victim's STK, spoofs the victim's IP, = and initiates a 0-RTT connection with a server on the victim's behalf. = The attacker then spoofs ack packets to the server which cause the server t= o potentially drown the victim in data.


There are two possible m= itigations to this attack. The simplest one is that a server can unilateral= ly create a gap in the PSN space. In the non-attack scenario, the client wi= ll send back NACKs for the PSNs in the gap, but the server will eventually = send a STOP_WAITING frame for those packets. In the attack scenario, the at= tacker may ack a packet in the gap. If the server sees an ack for a packet = that was never sent, the connection can be aborted.


The second m= itigation is that the server can require that acks for sent packets match t= he encryption level of the sent packet. This mitigation is useful if the co= nnection has an ephemeral forward-secure key that is generated and used for= every new connection. If a packet sent is encrypted with a forward-secure = key, then any acks that are received for them must also be forward-secure e= ncrypted. Since the attacker will not have the forward secure key, the atta= cker will not be able to generate forward-secure encrypted ack packets.
"


Section 4.2.3 on Crypto Handshake Protocol features

In the bullet about Connection establishment in 0-RTT, it requires 0-RTT co= nnection establishment for subsequent connections between the same two endp= oints, in the subsequent connections, the client and server roles must be p= reserved or they can be changed?
I mean, suppose that host A initiates a quic connection= to host b. Does this condition requires that a future connection (with the= same ports) initiated from host b to host A should be established in 0-RTT= ?

I think this should be made explicitly because mixed with the STK, I believ= e it changes the threat model significantly.

The presumption certainly was that the roles are preserved. With= QUIC's current (non-TLS) crypto handshake, there are very clear roles,= and I believe that TLS also has a clear expectation of client/server roles= . That said, I think this consideration belongs in either the TLS mapping d= ocument (or in TLS itself) since that document should handle=C2=A0any threa= t models that arise from it's 0-RTT implementation with an STK and/or T= FO cookie. Is there any clarification that you think might be useful to add= to the crypto handshake requirements section?
=C2=A0
=
Nit: the paragraph on the= bullet on Server Config Update is truncated.

Removed the truncated sentence -- thanks!

Section 5.1 on Life of a stream.

It states that quic accommodates the possibility of out-of-order delivery. = Do you mean out of order delivery within the same stream or across streams?= clarify?

Across streams. I've chan= ged the text to: "the possibility of out-of-order delivery due to the = use of multiple streams in QUIC"

I understand that the creation of a stream is very lightweight and a new st= ream is established by simply data with a new stream id, correct?

Correct.
=C2=A0
I also understand that the initial stream sequence number is always 0, corr= ect? (I mean, the offset of the current data to the beginning of the stream= s is included, and the initial packet has offset 0).
<= br>
Correct.
=C2=A0
So, similar to the question i posed about the initial PSN, how does quic pr= event old packets to reappear and be confused as being part of the new stre= am while they were part of an older stream? It cannot be done using the off= set, since for all connection it starts in 0. I guess it could be done usin= g the PSN, but then the receiver needs to check that all PSN of packets for= a new stream are higher than the PSN of the packet that terminated the old= er stream, is this the proposed approach?
Probably it is worthwhile clarifying what are = the means that quic deals with old packets re emerging after the connection= /stream has ended, given that it does not relies on the sequence number to = do so, afaict.

Within the connection, t= he Section 5.2 says " A QUIC endpoint MUST NOT reuse a StreamID on a g= iven connection," so such STREAM frames will be considered duplicates.= Do you think this can be clarified better somewhere?
=C2=A0
In particular, in section 5.1.1 it states that a stream is open by sending = or receiving a data packet with that particular stream ID. I assume that th= e data packet MUST contain a 0 offset to create the new stream? is this cor= rect?

Not necessarily, since the packet= containing a STREAM frame with a 0 offset may have been dropped in the net= work. A STREAM frame with an offset > 0 may be accepted, but the data wi= ll not get delivered to the application until the intiial gap within the st= ream is filled.

Section 5.2 on Stream Identifiers.

I guess you should reserve a range of identifiers for future use, in case o= ther "special" streams are needed in the future?
=

I'm not sure what the point of reserving any =C2=A0= would be, since if a special stream is needed in the future, this usage can= be negotiated with either an option or with a version change.
Section 5.4 on Sending and Receiving data.

Is the initial offset for the data packet sent on a stream set to zero? If = this is the case, would be good to state it.

I've added this sentence: "The first byte of data that is se= nt on a stream has the stream offset 0."


=
Section 6. on Packetization and reliability. What is the initial PSN in a g= iven connection? State it explicitly.

A= dded "The initial PSN used, at both the client and the server, MUST be= 0. That is, the first packet in both directions of the connection MUST hav= e a PSN of 0."
=C2=A0
It is stated that a sender MAY wait for a short period of time to bundle mu= ltiple frames. I guess it would be useful to provide guidance on what you c= onsider a short period of time. Is that 500ms as in the delayed acks or are= you thinking much less?

MUCH less. Thi= s is definitely a MAY, and I am not sure if recommending something here mak= es sense, since the expectations in any deployment will be different about = how much waiting makes sense. How's the following: "An implementat= ion may use heuristics about expected application sending behavior=C2=A0to = determine whether and for how long to wait. This waiting period is an imple= mentation decision, and an implementation should be careful to delay conser= vatively, since any delay is likely to increase application-visible latency= ."

Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not= be retransmitted, but all other frames must be retransmitted. This implies= than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i am= not sure if this makes sense. I mean, maybe there were other WINDOW_UPDATE= frames than were sent after this one so retransmitting this one probably d= oesnt make sense, since the information it contains may be stalled, no?
=

You're correct that WINDOW_UPDATE and = BLOCKED frames are retransmitted. It's hard to construct a scenario how= ever where a WINDOW_UPDATE frame keeps getting dropped, but the client stil= l sends enough data to cause a new revised WINDOW_UPDATE frame to be sent..= . I agree that in this case the sender would be retransmitted useless infor= mation, but I don't think we need to optimize for this case.
=
I still dont understand why having both connection and stream flow control = is useful. I would assume that only stream flow control would be useful. Or= having one or the other in a given connection, but i fail to understand wh= y is useful to have both of them simultaneously in the same connection.
=

I've answered this above, let me know = if there's more clarification that can be had in the doc.
Section 6 states

=C2=A0 =C2=A0Regular QUIC Packets are "containers" of frames; a p= acket is never
=C2=A0 =C2=A0retransmitted whole, but frames in a lost packet may be rebund= led and
=C2=A0 =C2=A0transmitted in a subsequent packet as necessary.

So, let me see if i understand this.

This means that if the sender sends packet with PSN 5, and if the packet is= lost (i.e. there is a timeout for that packet), the packet with PSN 5 NOT = retransmitted. the frames in the packet with PSN 5 are then retransmitted i= n other packets with other PSN (other than 5). If this correct?

Correct.
=C2=A0
This means that there will be holes in the sequence of packets received by = the receiver i.e. any packet that get's lost, is simply lost and will n= ever be received by the receiver. Am i understanding this correctly?

Correct.
=C2=A0
=C2=A0 =C2=A0A receiver acknowledges receipt of a received packet by sendin= g one
=C2=A0 =C2=A0or more ACK frames containing the PSN of the received packet.= =C2=A0 To
=C2=A0 =C2=A0avoid perpetual acking between endpoints, a receiver MUST NOT<= br> =C2=A0 =C2=A0generate an ack in response to every packet containing only AC= K
=C2=A0 =C2=A0frames.

Does this means that ACKs transmission is unreliable, correct?

Correct.
=C2=A0
Since packets are never retransmitted with the same PSN, this basically mea= ns that if an ACK is lost, then the sender gives up on this packet and even= tually will retransmit the data in other packets with a different PSN, corr= ect?

Correct.
=C2=A0

Section 7.1.1 on Mid-stream RST_STREAM

After a RST, when the stream identifier can be reused? probably some guidan= ce about this would be useful.

As I cla= rified above, a stream ID can never be reused.

Section 7.1.4.

Is the BLOCKED frame reliably transmitted? I assume it is, but, does it mak= e sense?

Yes, it is reliably transmitte= d.
=C2=A0
I mean, if a sender sends a blocked frame and it get's lost, but after = that the receiver open the window, then retransmitting the BLOCKED frame is= not useful (doesnt harm neither i guess)

OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly= window syndrome?

The BLOCKED frame is = really a debugging frame... it's good to know at the receiver that the = sender was flow control blocked. Since the receiver is expected to have sen= t a WINDOW_UPDATE well in advance, and since the BLOCKED frame is not a req= uired part of the flow control machinery, it doesn't cause SWS. It'= s currently required for the sender to send, but not required to be process= ed by the receiver beyond maybe logging it somewhere. I've modified the= text in Section 7.1.4 to say:=C2=A0

"If a se= nder does not receive a WINDOW_UPDATE frame when it has run out of flow con= trol credit, the sender will be blocked and MUST send a BLOCKED frame. A BL= OCKED frame is expected to be useful for debugging at the receiver. A recei= ver SHOULD NOT wait for a BLOCKED frame before sending with a WINDOW_UPDATE= , since doing so will cause at least one roundtrip of quiescence. For smoot= h operation of the congestion controller, it is generally considered best t= o not let the sender go into quiescence if avoidable. To avoid blocking a s= ender, and to reasonably account for the possibiity of loss, a receiver sho= uld send a WINDOW_UPDATE frame at least two roundtrips before it expects th= e sender to get blocked."

Is that clearer?

I guess we could do what TCP does i.e. periodically transmit the BLOCKED ms= g when there is no window (which is different from reliably transmitting th= e BLOCKED message, since it is periodically sent only when the window is 0)=


Section 8 on connection termination

After a connection close, does the same stream identifier can be reused for= a new connection? shouldnt also be a hold time to avoid delayed packets of= the old connection? How much time would be safe?

=
Do you mean Connection ID? Again, since the expectation is that = the keys will be different. Of course that depends on the KDF, but that dep= ends on the crypto protocol in use. I think the clarification that I added = above to the crypto requirements should be enough. What do you think?
=
=C2=A0
Section 10.4

I understand ACK frames are unreliably transmitted.

Also, I understand that packets are never retransmitted with the same PSN. = So, if a packet is lost, there will be a hole in the receiver for that PSN = and the data will be sent in other packets with othew PSN. Hence, you canno= t have cummulative acks.

Correct.
=
=C2=A0
So, this means that it is possible for a packet to be received by the recei= ver but that all the ACKs for that packet to be lost on the way back and th= en the sender will timeout and retransmit, right? (I guess that is ok, sinc= e data will be retransmitted in other packets)

Correct.
=C2=A0
Let me verify that I understand when a stop waiting frames should be sent b= y the sender. I guess that a sender should send a given PSN X in a stop wai= ting frame if all the packet with PSN lower than X have been received or ha= ve timed out, correct?

Correct. I would= say when all PSNs <=3D X are no longer considered in flight.
=

Thanks again,
- jana
=C2= =A0
Regards, marcelo

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a113ee41628e139053f5716cd-- From nobody Thu Oct 20 22:14:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41571294CC for ; Thu, 20 Oct 2016 22:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydImtnkEay5Q for ; Thu, 20 Oct 2016 22:14:01 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3204129481 for ; Thu, 20 Oct 2016 22:14:01 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id k64so45245428itb.0 for ; Thu, 20 Oct 2016 22:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=agpBjh9lqWWdzcz3usEfa8CYHe/akQLuQumhlUWXVUA=; b=GOFhSYNkEmZlH2e7EP/HRf3t+U4n2xS/rUg26dz+SU9qzy338/iCC5KvaZxjGhBC/M IBUdesmKklwmHPlfn5PkeN+0G3l2KlNR8GYG2Q4l0/tdYSNfz9rNKyBk4I6aLSpLt+DQ K6I4F9a3WlZ05VOhxf2P23ag8jh6GOP9KBd0e1r02hu+SNgsPm08F83/9DhyUOh9sV/o 1M64AhGpk6MbyqzJ1Mt/wqL/T1R2OeYqaVD3ZSp2eY27sGfz9w1WiWhsOU5/T5YKMoLM M8eJRl6+M44SBX0YkF2eHW07n/X4eWhJtxd6/qUxMCj8Vy09QxCyQJJn+8Rev+41JRQE lw0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=agpBjh9lqWWdzcz3usEfa8CYHe/akQLuQumhlUWXVUA=; b=O0FGdzEck+NlB+mYV/D+tvZqkyrBgc3KoVgMA6DKTsw/dogm3mZSxE9Bxf7uGXzb2j r13M1uUFOV5l6s9ei6FsBnm4pi4IKS9EozoPB8/5uMeBl1LPcH+ys+KclyyI5Brpqabz fcwKOsjM57oo/K52QJ385Iqg5Y6suh17a0whQ5gzbrzuwKzrEKdz5yF+2/eviN/CLzn0 eMmBohEVTypdSK2LJDS2jO5T6ar5EP2DMwnq491GKZPvX87b4+uf+R1CdL4lYxe/bVlc Tnq5/tDEOPz2EhDH2tWSugmbCYSIrf18wq/aAqlVVtpGpeYwHo1T8xaNv+T3F9nFoTHf w00A== X-Gm-Message-State: ABUngvfPvkY11BAm844OkGM9i9lAYCbjLGgnQ62ixI/ESpg1uHGdMbXVgba4zJOCKg4QvduO2LBuFOSQIWzrm48x X-Received: by 10.107.128.28 with SMTP id b28mr5228747iod.134.1477026840784; Thu, 20 Oct 2016 22:14:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.36.216 with HTTP; Thu, 20 Oct 2016 22:14:00 -0700 (PDT) In-Reply-To: <04C36CF1-387A-460D-8820-591BD2ED7C90@netapp.com> References: <04C36CF1-387A-460D-8820-591BD2ED7C90@netapp.com> From: Jana Iyengar Date: Thu, 20 Oct 2016 22:14:00 -0700 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a113f9a622ba5c5053f591ceb Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Early implementation feedback on draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 05:14:04 -0000 --001a113f9a622ba5c5053f591ceb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lars, Thanks again for your implementation effort and detailed feedback, and apologies for taking a while to respond. I'm happy to iterate, and I expect that my turnaround will be much faster (unlike this time :-)) On Fri, Sep 23, 2016 at 2:47 AM, Eggert, Lars wrote: > Hi, > > I've started to do a little QUIC implementation exercise, to see if > the current set of documents is sufficient to allow independent > implementation. As can be expected, they're not, but I wanted to post > some feedback based on what I encountered at this very, very, VERY > early phase, so the documents can be improved. > Thank you! This is what we're hoping for as well. Thank you for being a willing early implementer. > I'm purposefully avoiding to rely at documentation other than the IDs. > I won't look at the Chromium code, and I'm only looking at the specs > on Google Docs or wireshark outputs in order to more accurately > describe what's currently missing in the IDs. However, I run my > implementation against the Chromium quic_server and quic_client > implementations, in order to see if they interoperate. > I anticipate some trouble in getting it to work with quic_client and quic_server if you're just building from the spec, since these binaries use the QUIC crypto handshake , and the spec currently does not specify one. > (I may open source this pure C implementation at some point; at the > moment, it's too embarrassing to do so.) > > I began by reading draft-hamilton-quic-transport-protocol-00, in order > to implement the initial handshake. The ID is reasonably long and > complete-looking. Sections 1, 2 and 3 are reasonable in terms of > content. > > Section 4 (Connection Establishment) is difficult to make sense of > without first reading Section 9 (Packet Types and Formats), because > Section 4 refers to header fields, flags and other concepts that are > only defined in Section 9. The content seems arbitrarily split between > those sections, e.g., Section 4.1 attempts to specify version > negotiation, but Section 9.2.1 describes the version negotiation > packet format. One needs to constantly flip back and forth, which is > annoying. I'd recommend reordering the content here. > I wasn't sure how to organize this content, so it's currently mechanisms in early sections and wire formats later. From your experience it seems like it may be better organized if the the wire format of the various packets and frames were alongside the mechanisms. Does that sound like a good rule of thumb? Given the size of the draft, that may be better, so I'm happy to do it. One thing that threw me was that Section 9.1 states "all QUIC packets > on the wire begin with a public header" and then has a diagram of what > that header looks like, only to immediately follow it in Section 9.2 > with special packets that don't fully include that public header. > That's really confusing. Is there a way to describe the public header > that would include the format of the special packets? Is there a way > to make those special packets use the public header? They're so rarely > sent that deviating to save a few bytes doesn't seem to be a smart > tradeoff. > I think there may be a way to separate the common parts out. Specifically, the flags and the connection ID are really the "common header", but the reason for having these three packet types is because they differ in the parts that are not encrypted (The parts that are encrypted should be specified, and I'll add that.) Perhaps one way to describe them would be to say: - Common Header =3D Flags + (optional) Connection ID - Regular Packets =3D Common Header + (optional) Version + Packet Number + Frames - Version Negotiation Packet =3D Common Header (Version Negotiation bit set= ) + Version List - Public Reset Packet =3D Common Header (Reset bit set) + Optional tag-valu= es I realized that we don't describe the format for the optional tag-values in the spec, but they're potentially useful to help authenticate the Reset. That's entirely optional at the moment, but really the Public Reset packet is identified by the bit in the flags and the connection is identified by the Connection ID. > Also, the document makes no mention of what endianness the protocol > fields are supposed to be encoded in. > Good point -- I've added a sentence to the Packet Types and Formats saying "All values are little-endian unless otherwise noted." This sentence will likely move as the doc gets restructured, but that is the first place a packet format is currently being described. The ID mentions QUIC version "Q025", so my code attempts to negotiate > this version with the Chromium quic_server, but that offers "Q036" and > indicates support for "Q035Q034Q033Q032" as well. The negotiation > response from the server does not conform to what's in the ID, since > it has the "diversification nonce" flag set (0x04), which is not > specified in Section 9.2.1. It also seems to use only 12 bytes of the > fixed 32 bytes that the nonce should occupy to indicate support for > other versions, according to Section 9.1. > > Also, that "diversification nonce" is not referred to anywhere else in > the ID other than Section 9.1. It remains fully unclear what it is. > Good catch. The diversification nonce was a need for QUIC crypto, and it won't be required for TLS or for the general format. I'll remove mentions of it from the document. > I change my code to negotiate version "Q036", and am trying to > figure out which frame types I am supposed to include in the initial > packet. The various subsections of Section 4.2 list some (and say that > some are required), but there is not enough information here for me to > determine which to include and what the initial values should be. > So, this initial packet will be a CHLO, which is a crypto handshake packet. Basically, this is a Regular QUIC Packet, with the crypto handshake bits being sent as a STREAM frame on stream ID 1. It's clear to me now that having a detailed description of a handshake packet at this point in the text is probably helpful. If the reorganization that I suggested earlier makes sense, this may be around where I'd introduce the Regular Packet and the STREAM frame format. So I'm cheating, and am looking at a wireshark dump of the initial > packet that the Chromium quic_client sends to my server. I notice > there is a "Message Authentication Hash" following the public header > that is not mentioned at all in the ID. There is some brief text about > "AEAD data" in Section 9.3, but nothing that would let me understand > how that hash is computed. A quick glance at draft-thomson-quic-tls > doesn't resolve this either. Googling around, I find that older > versions of the spec on Google Docs have a short paragraph on "Initial > Packet Null Encryption" that talks about using a FNV1a=C2=AD128 hash, but > even the current version on Google Docs doesn't have that paragraph > anymore. There's clearly some content missing here. > Right -- this is the hash that is used by the AEAD algo used by QUIC's current packet crypto. This may change with TLS, and may be a different hash, but the location of the hash is right after the public header. This isn't documtned in the spec as you note, so I'll add some text about this along with the revision of the Packet Formats. And that's where I'm currently at, after a few hours of coding. Hope > this is useful. > Yes, extremely useful. Thanks again for your effort and feedback -- I'll try to incorporate as much as I can before the next rev. - jana > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a113f9a622ba5c5053f591ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lars,

Thanks again for your implemen= tation effort and detailed feedback, and apologies for taking a while to re= spond. I'm happy to iterate, and I expect that my turnaround will be mu= ch faster (unlike this time :-))

On Fri, Sep 23, 2016 at 2:47 AM, Eggert, La= rs <lars@netapp.com> wrote:
Hi,

I've started to do a little QUIC implementation exercise, to see if
the current set of documents is sufficient to allow independent
implementation. As can be expected, they're not, but I wanted to post some feedback based on what I encountered at this very, very, VERY
early phase, so the documents can be improved.

Thank you! This is what we're hoping for as well. Thank you for= being a willing early implementer.
=C2=A0
I'm purposefully avoiding to rely at documentation other than the IDs.<= br> I won't look at the Chromium code, and I'm only looking at the spec= s
on Google Docs or wireshark outputs in order to more accurately
describe what's currently missing in the IDs. However, I run my
implementation against the Chromium quic_server and quic_client
implementations, in order to see if they interoperate.

I anticipate some trouble in getting it to work with quic_c= lient and quic_server if you're just building from the spec, since thes= e binaries use the QUIC crypto handshake, and the= spec currently does not specify one.=C2=A0
=C2=A0
(I may open source this pure C implementation at some point; at the
moment, it's too embarrassing to do so.)

I began by reading draft-hamilton-quic-transport-protocol-00, in order=
to implement the initial handshake. The ID is reasonably long and
complete-looking. Sections 1, 2 and 3 are reasonable in terms of
content.

Section 4 (Connection Establishment) is difficult to make sense of
without first reading Section 9 (Packet Types and Formats), because
Section 4 refers to header fields, flags and other concepts that are
only defined in Section 9. The content seems arbitrarily split between
those sections, e.g., Section 4.1 attempts to specify version
negotiation, but Section 9.2.1 describes the version negotiation
packet format. One needs to constantly flip back and forth, which is
annoying. I'd recommend reordering the content here.

I wasn't sure how to organize this content, so it'= ;s currently mechanisms in early sections and wire formats later. From your= experience it seems like it may be better organized if the the wire format= of the various packets and frames were alongside the mechanisms. Does that= sound like a good rule of thumb? Given the size of the draft, that may be = better, so I'm happy to do it.

One thing that threw me was that Section 9.1 states "all QUIC packets<= br> on the wire begin with a public header" and then has a diagram of what=
that header looks like, only to immediately follow it in Section 9.2
with special packets that don't fully include that public header.
That's really confusing. Is there a way to describe the public header that would include the format of the special packets? Is there a way
to make those special packets use the public header? They're so rarely<= br> sent that deviating to save a few bytes doesn't seem to be a smart
tradeoff.

I think there may be a way to= separate the common parts out. Specifically, the flags and the connection = ID are really the "common header", but the reason for having thes= e three packet types is because they differ in the parts that are not encry= pted (The parts that are encrypted should be specified, and I'll add th= at.) Perhaps one way to describe them would be to say:
- Common H= eader =3D Flags + (optional) Connection ID
- Regular Packets =3D = Common Header + (optional) Version + Packet Number + Frames
- Ver= sion Negotiation Packet =3D Common Header (Version Negotiation bit set) + V= ersion List
- Public Reset Packet =3D Common Header (Reset bit se= t) + Optional tag-values

I realized that we don= 9;t describe the format for the optional tag-values in the spec, but they&#= 39;re potentially useful to help authenticate the Reset. That's entirel= y optional at the moment, but really the Public Reset packet is identified = by the bit in the flags and the connection is identified by the Connection = ID.
=C2=A0
Also, the document makes no mention of what endianness the protocol
fields are supposed to be encoded in.

G= ood point -- I've added a sentence to the Packet Types and Formats sayi= ng "All values are little-endian unless otherwise noted." This se= ntence will likely move as the doc gets restructured, but that is the first= place a packet format is currently being described.

The ID mentions QUIC version "Q025", so my code attempts to negot= iate
this version with the Chromium quic_server, but that offers "Q036"= ; and
indicates support for "Q035Q034Q033Q032" as well. The negotiation=
response from the server does not conform to what's in the ID, since it has the "diversification nonce" flag set (0x04), which is not<= br> specified in Section 9.2.1. It also seems to use only 12 bytes of the
fixed 32 bytes that the nonce should occupy to indicate support for
other versions, according to Section 9.1.

Also, that "diversification nonce" is not referred to anywhere el= se in
the ID other than Section 9.1. It remains fully unclear what it is.

Good catch. The diversification nonce was a ne= ed for QUIC crypto, and it won't be required for TLS or for the general= format. I'll remove mentions of it from the document.
=C2=A0=
I change my code to negotiate version "Q036", and am trying to figure out which frame types I am supposed to include in the initial
packet. The various subsections of Section 4.2 list some (and say that
some are required), but there is not enough information here for me to
determine which to include and what the initial values should be.

So, this initial packet will be a CHLO, which is= a crypto handshake packet. Basically, this is a Regular QUIC Packet, with = the crypto handshake bits being sent as a STREAM frame on stream ID 1. It&#= 39;s clear to me now that having a detailed description of a handshake pack= et at this point in the text is probably helpful. If the reorganization tha= t I suggested earlier makes sense, this may be around where I'd introdu= ce the Regular Packet and the STREAM frame format.

So I'm cheating, and am looking at a wireshark dump of the initial
packet that the Chromium quic_client sends to my server. I notice
there is a "Message Authentication Hash" following the public hea= der
that is not mentioned at all in the ID. There is some brief text about
"AEAD data" in Section 9.3, but nothing that would let me underst= and
how that hash is computed. A quick glance at draft-thomson-quic-tls
doesn't resolve this either. Googling around, I find that older
versions of the spec on Google Docs have a short paragraph on "Initial=
Packet Null Encryption" that talks about using a FNV1a=C2=AD128 hash, = but
even the current version on Google Docs doesn't have that paragraph
anymore. There's clearly some content missing here.

Right -- this is the hash that is used by the AEAD algo us= ed by QUIC's current packet crypto. This may change with TLS, and may b= e a different hash, but the location of the hash is right after the public = header. This isn't documtned in the spec as you note, so I'll add s= ome text about this along with the revision of the Packet Formats.

And that's where I'm currently at, after a few hours of coding. Hop= e
this is useful.

Yes, extremely useful. = Thanks again for your effort and feedback -- I'll try to incorporate as= much as I can before the next rev.

- jana
=C2=A0
Lars
_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a113f9a622ba5c5053f591ceb-- From nobody Fri Oct 21 05:02:24 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377431295AA for ; Fri, 21 Oct 2016 05:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaXpEWjAH0uY for ; Fri, 21 Oct 2016 05:02:19 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6721294A4 for ; Fri, 21 Oct 2016 05:02:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,376,1473145200"; d="scan'208";a="150899181" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx143-out.netapp.com with ESMTP; 21 Oct 2016 05:01:49 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 05:01:56 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 21 Oct 2016 05:01:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h77c3npgFGv4yY/YhdVYoDa4+iHU0Q3pIOXZjJX5f+M=; b=J78m5ZB/dIgS073iyI/v4OVQS7nM39rVpbwUDtmy/Tm0/DMQwmpDwp+SflYxBjACsnoN5IiPhXJ2xf6mCgxcqPbVMmHUsyx5mFXqogNXPL5lLMosXH4avHa/x4d0/oB9N3wFZAnVMREynSpOtX/sleePIqTuQgbhfkEWZhja+0g= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Fri, 21 Oct 2016 12:01:54 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0659.025; Fri, 21 Oct 2016 12:01:54 +0000 From: "Eggert, Lars" To: Jana Iyengar Thread-Topic: [QUIC] Early implementation feedback on draft-hamilton-quic-transport-protocol-00 Thread-Index: AQHSFX9vCC/rzHVRH0ap9TECi8nzO6CyiN4AgABx9oA= Date: Fri, 21 Oct 2016 12:01:54 +0000 Message-ID: References: <04C36CF1-387A-460D-8820-591BD2ED7C90@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3226) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: ecdb36d3-5c3b-48f8-4f42-08d3f9aa0d0b x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:IoyqFrvJ+hnmTLz/Not3CPxqYZkCLV81Iicw2uJsCaI+ticS8Wu0vQ4MGsGi4VVAlyLnWqewXaQIAUN6e/yCFB2KlB5jJHx4HC7xrk2o7Umx9JGt0V5ZEm13U6bg9HC+gZxfGliLijk1Dfkf5EmzKUpnS8Sm6/SZFRv0WKIyXpOD1kFSfQ/TyMikgSmMaxz3PscCpiDisJ8iaxlMdLD/LGwEqqlJlW/YdS4nBghn27v5AabymHdjX523LE6H4t3e2y/z8t9DqX3K4qaVRhMk9YwjoIMIkJcApwgKZOitwQE7Uc5oQWHgkA0v1iKFe7T0jIUhLLgl6IyDkOwOAmkmwfGUz4iGVAMI8bM01SImTjo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 01026E1310 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(43784003)(377454003)(199003)(189002)(24454002)(377424004)(106356001)(8936002)(4001150100001)(66066001)(2906002)(50226002)(305945005)(101416001)(7736002)(7846002)(68736007)(5660300001)(8676002)(76176999)(57306001)(230783001)(99286002)(122556002)(10400500002)(92566002)(50986999)(36756003)(105586002)(81156014)(19580405001)(106116001)(81166006)(110136003)(19580395003)(33656002)(82746002)(5002640100001)(6916009)(2950100002)(345774005)(6116002)(586003)(3846002)(4326007)(189998001)(83716003)(87936001)(15975445007)(86362001)(2900100001)(77096005)(102836003)(3660700001)(97736004)(3280700002)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 12:01:54.5921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Early implementation feedback on draft-hamilton-quic-transport-protocol-00 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 12:02:22 -0000 VGhhbmtzLCB0aGlzIGlzIGhlbHBmdWwhDQoNCk9uIDIwMTYtMTAtMjEsIGF0IDc6MTQsIEphbmEg SXllbmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KPiANCj4gSGkgTGFycywNCj4gDQo+IFRo YW5rcyBhZ2FpbiBmb3IgeW91ciBpbXBsZW1lbnRhdGlvbiBlZmZvcnQgYW5kIGRldGFpbGVkIGZl ZWRiYWNrLCBhbmQgYXBvbG9naWVzIGZvciB0YWtpbmcgYSB3aGlsZSB0byByZXNwb25kLiBJJ20g aGFwcHkgdG8gaXRlcmF0ZSwgYW5kIEkgZXhwZWN0IHRoYXQgbXkgdHVybmFyb3VuZCB3aWxsIGJl IG11Y2ggZmFzdGVyICh1bmxpa2UgdGhpcyB0aW1lIDotKSkNCj4gDQo+IE9uIEZyaSwgU2VwIDIz LCAyMDE2IGF0IDI6NDcgQU0sIEVnZ2VydCwgTGFycyA8bGFyc0BuZXRhcHAuY29tPiB3cm90ZToN Cj4gSGksDQo+IA0KPiBJJ3ZlIHN0YXJ0ZWQgdG8gZG8gYSBsaXR0bGUgUVVJQyBpbXBsZW1lbnRh dGlvbiBleGVyY2lzZSwgdG8gc2VlIGlmDQo+IHRoZSBjdXJyZW50IHNldCBvZiBkb2N1bWVudHMg aXMgc3VmZmljaWVudCB0byBhbGxvdyBpbmRlcGVuZGVudA0KPiBpbXBsZW1lbnRhdGlvbi4gQXMg Y2FuIGJlIGV4cGVjdGVkLCB0aGV5J3JlIG5vdCwgYnV0IEkgd2FudGVkIHRvIHBvc3QNCj4gc29t ZSBmZWVkYmFjayBiYXNlZCBvbiB3aGF0IEkgZW5jb3VudGVyZWQgYXQgdGhpcyB2ZXJ5LCB2ZXJ5 LCBWRVJZDQo+IGVhcmx5IHBoYXNlLCBzbyB0aGUgZG9jdW1lbnRzIGNhbiBiZSBpbXByb3ZlZC4N Cj4gDQo+IFRoYW5rIHlvdSEgVGhpcyBpcyB3aGF0IHdlJ3JlIGhvcGluZyBmb3IgYXMgd2VsbC4g VGhhbmsgeW91IGZvciBiZWluZyBhIHdpbGxpbmcgZWFybHkgaW1wbGVtZW50ZXIuDQo+ICANCj4g SSdtIHB1cnBvc2VmdWxseSBhdm9pZGluZyB0byByZWx5IGF0IGRvY3VtZW50YXRpb24gb3RoZXIg dGhhbiB0aGUgSURzLg0KPiBJIHdvbid0IGxvb2sgYXQgdGhlIENocm9taXVtIGNvZGUsIGFuZCBJ J20gb25seSBsb29raW5nIGF0IHRoZSBzcGVjcw0KPiBvbiBHb29nbGUgRG9jcyBvciB3aXJlc2hh cmsgb3V0cHV0cyBpbiBvcmRlciB0byBtb3JlIGFjY3VyYXRlbHkNCj4gZGVzY3JpYmUgd2hhdCdz IGN1cnJlbnRseSBtaXNzaW5nIGluIHRoZSBJRHMuIEhvd2V2ZXIsIEkgcnVuIG15DQo+IGltcGxl bWVudGF0aW9uIGFnYWluc3QgdGhlIENocm9taXVtIHF1aWNfc2VydmVyIGFuZCBxdWljX2NsaWVu dA0KPiBpbXBsZW1lbnRhdGlvbnMsIGluIG9yZGVyIHRvIHNlZSBpZiB0aGV5IGludGVyb3BlcmF0 ZS4NCj4gDQo+IEkgYW50aWNpcGF0ZSBzb21lIHRyb3VibGUgaW4gZ2V0dGluZyBpdCB0byB3b3Jr IHdpdGggcXVpY19jbGllbnQgYW5kIHF1aWNfc2VydmVyIGlmIHlvdSdyZSBqdXN0IGJ1aWxkaW5n IGZyb20gdGhlIHNwZWMsIHNpbmNlIHRoZXNlIGJpbmFyaWVzIHVzZSB0aGUgUVVJQyBjcnlwdG8g aGFuZHNoYWtlLCBhbmQgdGhlIHNwZWMgY3VycmVudGx5IGRvZXMgbm90IHNwZWNpZnkgb25lLiAN Cj4gIA0KPiAoSSBtYXkgb3BlbiBzb3VyY2UgdGhpcyBwdXJlIEMgaW1wbGVtZW50YXRpb24gYXQg c29tZSBwb2ludDsgYXQgdGhlDQo+IG1vbWVudCwgaXQncyB0b28gZW1iYXJyYXNzaW5nIHRvIGRv IHNvLikNCj4gDQo+IEkgYmVnYW4gYnkgcmVhZGluZyBkcmFmdC1oYW1pbHRvbi1xdWljLXRyYW5z cG9ydC1wcm90b2NvbC0wMCwgaW4gb3JkZXINCj4gdG8gaW1wbGVtZW50IHRoZSBpbml0aWFsIGhh bmRzaGFrZS4gVGhlIElEIGlzIHJlYXNvbmFibHkgbG9uZyBhbmQNCj4gY29tcGxldGUtbG9va2lu Zy4gU2VjdGlvbnMgMSwgMiBhbmQgMyBhcmUgcmVhc29uYWJsZSBpbiB0ZXJtcyBvZg0KPiBjb250 ZW50Lg0KPiANCj4gU2VjdGlvbiA0IChDb25uZWN0aW9uIEVzdGFibGlzaG1lbnQpIGlzIGRpZmZp Y3VsdCB0byBtYWtlIHNlbnNlIG9mDQo+IHdpdGhvdXQgZmlyc3QgcmVhZGluZyBTZWN0aW9uIDkg KFBhY2tldCBUeXBlcyBhbmQgRm9ybWF0cyksIGJlY2F1c2UNCj4gU2VjdGlvbiA0IHJlZmVycyB0 byBoZWFkZXIgZmllbGRzLCBmbGFncyBhbmQgb3RoZXIgY29uY2VwdHMgdGhhdCBhcmUNCj4gb25s eSBkZWZpbmVkIGluIFNlY3Rpb24gOS4gVGhlIGNvbnRlbnQgc2VlbXMgYXJiaXRyYXJpbHkgc3Bs aXQgYmV0d2Vlbg0KPiB0aG9zZSBzZWN0aW9ucywgZS5nLiwgU2VjdGlvbiA0LjEgYXR0ZW1wdHMg dG8gc3BlY2lmeSB2ZXJzaW9uDQo+IG5lZ290aWF0aW9uLCBidXQgU2VjdGlvbiA5LjIuMSBkZXNj cmliZXMgdGhlIHZlcnNpb24gbmVnb3RpYXRpb24NCj4gcGFja2V0IGZvcm1hdC4gT25lIG5lZWRz IHRvIGNvbnN0YW50bHkgZmxpcCBiYWNrIGFuZCBmb3J0aCwgd2hpY2ggaXMNCj4gYW5ub3lpbmcu IEknZCByZWNvbW1lbmQgcmVvcmRlcmluZyB0aGUgY29udGVudCBoZXJlLg0KPiANCj4gSSB3YXNu J3Qgc3VyZSBob3cgdG8gb3JnYW5pemUgdGhpcyBjb250ZW50LCBzbyBpdCdzIGN1cnJlbnRseSBt ZWNoYW5pc21zIGluIGVhcmx5IHNlY3Rpb25zIGFuZCB3aXJlIGZvcm1hdHMgbGF0ZXIuIEZyb20g eW91ciBleHBlcmllbmNlIGl0IHNlZW1zIGxpa2UgaXQgbWF5IGJlIGJldHRlciBvcmdhbml6ZWQg aWYgdGhlIHRoZSB3aXJlIGZvcm1hdCBvZiB0aGUgdmFyaW91cyBwYWNrZXRzIGFuZCBmcmFtZXMg d2VyZSBhbG9uZ3NpZGUgdGhlIG1lY2hhbmlzbXMuIERvZXMgdGhhdCBzb3VuZCBsaWtlIGEgZ29v ZCBydWxlIG9mIHRodW1iPyBHaXZlbiB0aGUgc2l6ZSBvZiB0aGUgZHJhZnQsIHRoYXQgbWF5IGJl IGJldHRlciwgc28gSSdtIGhhcHB5IHRvIGRvIGl0Lg0KPiANCj4gT25lIHRoaW5nIHRoYXQgdGhy ZXcgbWUgd2FzIHRoYXQgU2VjdGlvbiA5LjEgc3RhdGVzICJhbGwgUVVJQyBwYWNrZXRzDQo+IG9u IHRoZSB3aXJlIGJlZ2luIHdpdGggYSBwdWJsaWMgaGVhZGVyIiBhbmQgdGhlbiBoYXMgYSBkaWFn cmFtIG9mIHdoYXQNCj4gdGhhdCBoZWFkZXIgbG9va3MgbGlrZSwgb25seSB0byBpbW1lZGlhdGVs eSBmb2xsb3cgaXQgaW4gU2VjdGlvbiA5LjINCj4gd2l0aCBzcGVjaWFsIHBhY2tldHMgdGhhdCBk b24ndCBmdWxseSBpbmNsdWRlIHRoYXQgcHVibGljIGhlYWRlci4NCj4gVGhhdCdzIHJlYWxseSBj b25mdXNpbmcuIElzIHRoZXJlIGEgd2F5IHRvIGRlc2NyaWJlIHRoZSBwdWJsaWMgaGVhZGVyDQo+ IHRoYXQgd291bGQgaW5jbHVkZSB0aGUgZm9ybWF0IG9mIHRoZSBzcGVjaWFsIHBhY2tldHM/IElz IHRoZXJlIGEgd2F5DQo+IHRvIG1ha2UgdGhvc2Ugc3BlY2lhbCBwYWNrZXRzIHVzZSB0aGUgcHVi bGljIGhlYWRlcj8gVGhleSdyZSBzbyByYXJlbHkNCj4gc2VudCB0aGF0IGRldmlhdGluZyB0byBz YXZlIGEgZmV3IGJ5dGVzIGRvZXNuJ3Qgc2VlbSB0byBiZSBhIHNtYXJ0DQo+IHRyYWRlb2ZmLg0K PiANCj4gSSB0aGluayB0aGVyZSBtYXkgYmUgYSB3YXkgdG8gc2VwYXJhdGUgdGhlIGNvbW1vbiBw YXJ0cyBvdXQuIFNwZWNpZmljYWxseSwgdGhlIGZsYWdzIGFuZCB0aGUgY29ubmVjdGlvbiBJRCBh cmUgcmVhbGx5IHRoZSAiY29tbW9uIGhlYWRlciIsIGJ1dCB0aGUgcmVhc29uIGZvciBoYXZpbmcg dGhlc2UgdGhyZWUgcGFja2V0IHR5cGVzIGlzIGJlY2F1c2UgdGhleSBkaWZmZXIgaW4gdGhlIHBh cnRzIHRoYXQgYXJlIG5vdCBlbmNyeXB0ZWQgKFRoZSBwYXJ0cyB0aGF0IGFyZSBlbmNyeXB0ZWQg c2hvdWxkIGJlIHNwZWNpZmllZCwgYW5kIEknbGwgYWRkIHRoYXQuKSBQZXJoYXBzIG9uZSB3YXkg dG8gZGVzY3JpYmUgdGhlbSB3b3VsZCBiZSB0byBzYXk6DQo+IC0gQ29tbW9uIEhlYWRlciA9IEZs YWdzICsgKG9wdGlvbmFsKSBDb25uZWN0aW9uIElEDQo+IC0gUmVndWxhciBQYWNrZXRzID0gQ29t bW9uIEhlYWRlciArIChvcHRpb25hbCkgVmVyc2lvbiArIFBhY2tldCBOdW1iZXIgKyBGcmFtZXMN Cj4gLSBWZXJzaW9uIE5lZ290aWF0aW9uIFBhY2tldCA9IENvbW1vbiBIZWFkZXIgKFZlcnNpb24g TmVnb3RpYXRpb24gYml0IHNldCkgKyBWZXJzaW9uIExpc3QNCj4gLSBQdWJsaWMgUmVzZXQgUGFj a2V0ID0gQ29tbW9uIEhlYWRlciAoUmVzZXQgYml0IHNldCkgKyBPcHRpb25hbCB0YWctdmFsdWVz DQo+IA0KPiBJIHJlYWxpemVkIHRoYXQgd2UgZG9uJ3QgZGVzY3JpYmUgdGhlIGZvcm1hdCBmb3Ig dGhlIG9wdGlvbmFsIHRhZy12YWx1ZXMgaW4gdGhlIHNwZWMsIGJ1dCB0aGV5J3JlIHBvdGVudGlh bGx5IHVzZWZ1bCB0byBoZWxwIGF1dGhlbnRpY2F0ZSB0aGUgUmVzZXQuIFRoYXQncyBlbnRpcmVs eSBvcHRpb25hbCBhdCB0aGUgbW9tZW50LCBidXQgcmVhbGx5IHRoZSBQdWJsaWMgUmVzZXQgcGFj a2V0IGlzIGlkZW50aWZpZWQgYnkgdGhlIGJpdCBpbiB0aGUgZmxhZ3MgYW5kIHRoZSBjb25uZWN0 aW9uIGlzIGlkZW50aWZpZWQgYnkgdGhlIENvbm5lY3Rpb24gSUQuDQo+ICANCj4gQWxzbywgdGhl IGRvY3VtZW50IG1ha2VzIG5vIG1lbnRpb24gb2Ygd2hhdCBlbmRpYW5uZXNzIHRoZSBwcm90b2Nv bA0KPiBmaWVsZHMgYXJlIHN1cHBvc2VkIHRvIGJlIGVuY29kZWQgaW4uDQo+IA0KPiBHb29kIHBv aW50IC0tIEkndmUgYWRkZWQgYSBzZW50ZW5jZSB0byB0aGUgUGFja2V0IFR5cGVzIGFuZCBGb3Jt YXRzIHNheWluZyAiQWxsIHZhbHVlcyBhcmUgbGl0dGxlLWVuZGlhbiB1bmxlc3Mgb3RoZXJ3aXNl IG5vdGVkLiIgVGhpcyBzZW50ZW5jZSB3aWxsIGxpa2VseSBtb3ZlIGFzIHRoZSBkb2MgZ2V0cyBy ZXN0cnVjdHVyZWQsIGJ1dCB0aGF0IGlzIHRoZSBmaXJzdCBwbGFjZSBhIHBhY2tldCBmb3JtYXQg aXMgY3VycmVudGx5IGJlaW5nIGRlc2NyaWJlZC4NCj4gDQo+IFRoZSBJRCBtZW50aW9ucyBRVUlD IHZlcnNpb24gIlEwMjUiLCBzbyBteSBjb2RlIGF0dGVtcHRzIHRvIG5lZ290aWF0ZQ0KPiB0aGlz IHZlcnNpb24gd2l0aCB0aGUgQ2hyb21pdW0gcXVpY19zZXJ2ZXIsIGJ1dCB0aGF0IG9mZmVycyAi UTAzNiIgYW5kDQo+IGluZGljYXRlcyBzdXBwb3J0IGZvciAiUTAzNVEwMzRRMDMzUTAzMiIgYXMg d2VsbC4gVGhlIG5lZ290aWF0aW9uDQo+IHJlc3BvbnNlIGZyb20gdGhlIHNlcnZlciBkb2VzIG5v dCBjb25mb3JtIHRvIHdoYXQncyBpbiB0aGUgSUQsIHNpbmNlDQo+IGl0IGhhcyB0aGUgImRpdmVy c2lmaWNhdGlvbiBub25jZSIgZmxhZyBzZXQgKDB4MDQpLCB3aGljaCBpcyBub3QNCj4gc3BlY2lm aWVkIGluIFNlY3Rpb24gOS4yLjEuIEl0IGFsc28gc2VlbXMgdG8gdXNlIG9ubHkgMTIgYnl0ZXMg b2YgdGhlDQo+IGZpeGVkIDMyIGJ5dGVzIHRoYXQgdGhlIG5vbmNlIHNob3VsZCBvY2N1cHkgdG8g aW5kaWNhdGUgc3VwcG9ydCBmb3INCj4gb3RoZXIgdmVyc2lvbnMsIGFjY29yZGluZyB0byBTZWN0 aW9uIDkuMS4NCj4gDQo+IEFsc28sIHRoYXQgImRpdmVyc2lmaWNhdGlvbiBub25jZSIgaXMgbm90 IHJlZmVycmVkIHRvIGFueXdoZXJlIGVsc2UgaW4NCj4gdGhlIElEIG90aGVyIHRoYW4gU2VjdGlv biA5LjEuIEl0IHJlbWFpbnMgZnVsbHkgdW5jbGVhciB3aGF0IGl0IGlzLg0KPiANCj4gR29vZCBj YXRjaC4gVGhlIGRpdmVyc2lmaWNhdGlvbiBub25jZSB3YXMgYSBuZWVkIGZvciBRVUlDIGNyeXB0 bywgYW5kIGl0IHdvbid0IGJlIHJlcXVpcmVkIGZvciBUTFMgb3IgZm9yIHRoZSBnZW5lcmFsIGZv cm1hdC4gSSdsbCByZW1vdmUgbWVudGlvbnMgb2YgaXQgZnJvbSB0aGUgZG9jdW1lbnQuDQo+ICAN Cj4gSSBjaGFuZ2UgbXkgY29kZSB0byBuZWdvdGlhdGUgdmVyc2lvbiAiUTAzNiIsIGFuZCBhbSB0 cnlpbmcgdG8NCj4gZmlndXJlIG91dCB3aGljaCBmcmFtZSB0eXBlcyBJIGFtIHN1cHBvc2VkIHRv IGluY2x1ZGUgaW4gdGhlIGluaXRpYWwNCj4gcGFja2V0LiBUaGUgdmFyaW91cyBzdWJzZWN0aW9u cyBvZiBTZWN0aW9uIDQuMiBsaXN0IHNvbWUgKGFuZCBzYXkgdGhhdA0KPiBzb21lIGFyZSByZXF1 aXJlZCksIGJ1dCB0aGVyZSBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIGhlcmUgZm9yIG1lIHRv DQo+IGRldGVybWluZSB3aGljaCB0byBpbmNsdWRlIGFuZCB3aGF0IHRoZSBpbml0aWFsIHZhbHVl cyBzaG91bGQgYmUuDQo+IA0KPiBTbywgdGhpcyBpbml0aWFsIHBhY2tldCB3aWxsIGJlIGEgQ0hM Tywgd2hpY2ggaXMgYSBjcnlwdG8gaGFuZHNoYWtlIHBhY2tldC4gQmFzaWNhbGx5LCB0aGlzIGlz IGEgUmVndWxhciBRVUlDIFBhY2tldCwgd2l0aCB0aGUgY3J5cHRvIGhhbmRzaGFrZSBiaXRzIGJl aW5nIHNlbnQgYXMgYSBTVFJFQU0gZnJhbWUgb24gc3RyZWFtIElEIDEuIEl0J3MgY2xlYXIgdG8g bWUgbm93IHRoYXQgaGF2aW5nIGEgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgYSBoYW5kc2hha2Ug cGFja2V0IGF0IHRoaXMgcG9pbnQgaW4gdGhlIHRleHQgaXMgcHJvYmFibHkgaGVscGZ1bC4gSWYg dGhlIHJlb3JnYW5pemF0aW9uIHRoYXQgSSBzdWdnZXN0ZWQgZWFybGllciBtYWtlcyBzZW5zZSwg dGhpcyBtYXkgYmUgYXJvdW5kIHdoZXJlIEknZCBpbnRyb2R1Y2UgdGhlIFJlZ3VsYXIgUGFja2V0 IGFuZCB0aGUgU1RSRUFNIGZyYW1lIGZvcm1hdC4NCj4gDQo+IFNvIEknbSBjaGVhdGluZywgYW5k IGFtIGxvb2tpbmcgYXQgYSB3aXJlc2hhcmsgZHVtcCBvZiB0aGUgaW5pdGlhbA0KPiBwYWNrZXQg dGhhdCB0aGUgQ2hyb21pdW0gcXVpY19jbGllbnQgc2VuZHMgdG8gbXkgc2VydmVyLiBJIG5vdGlj ZQ0KPiB0aGVyZSBpcyBhICJNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIEhhc2giIGZvbGxvd2luZyB0 aGUgcHVibGljIGhlYWRlcg0KPiB0aGF0IGlzIG5vdCBtZW50aW9uZWQgYXQgYWxsIGluIHRoZSBJ RC4gVGhlcmUgaXMgc29tZSBicmllZiB0ZXh0IGFib3V0DQo+ICJBRUFEIGRhdGEiIGluIFNlY3Rp b24gOS4zLCBidXQgbm90aGluZyB0aGF0IHdvdWxkIGxldCBtZSB1bmRlcnN0YW5kDQo+IGhvdyB0 aGF0IGhhc2ggaXMgY29tcHV0ZWQuIEEgcXVpY2sgZ2xhbmNlIGF0IGRyYWZ0LXRob21zb24tcXVp Yy10bHMNCj4gZG9lc24ndCByZXNvbHZlIHRoaXMgZWl0aGVyLiBHb29nbGluZyBhcm91bmQsIEkg ZmluZCB0aGF0IG9sZGVyDQo+IHZlcnNpb25zIG9mIHRoZSBzcGVjIG9uIEdvb2dsZSBEb2NzIGhh dmUgYSBzaG9ydCBwYXJhZ3JhcGggb24gIkluaXRpYWwNCj4gUGFja2V0IE51bGwgRW5jcnlwdGlv biIgdGhhdCB0YWxrcyBhYm91dCB1c2luZyBhIEZOVjFhwq0xMjggaGFzaCwgYnV0DQo+IGV2ZW4g dGhlIGN1cnJlbnQgdmVyc2lvbiBvbiBHb29nbGUgRG9jcyBkb2Vzbid0IGhhdmUgdGhhdCBwYXJh Z3JhcGgNCj4gYW55bW9yZS4gVGhlcmUncyBjbGVhcmx5IHNvbWUgY29udGVudCBtaXNzaW5nIGhl cmUuDQo+IA0KPiBSaWdodCAtLSB0aGlzIGlzIHRoZSBoYXNoIHRoYXQgaXMgdXNlZCBieSB0aGUg QUVBRCBhbGdvIHVzZWQgYnkgUVVJQydzIGN1cnJlbnQgcGFja2V0IGNyeXB0by4gVGhpcyBtYXkg Y2hhbmdlIHdpdGggVExTLCBhbmQgbWF5IGJlIGEgZGlmZmVyZW50IGhhc2gsIGJ1dCB0aGUgbG9j YXRpb24gb2YgdGhlIGhhc2ggaXMgcmlnaHQgYWZ0ZXIgdGhlIHB1YmxpYyBoZWFkZXIuIFRoaXMg aXNuJ3QgZG9jdW10bmVkIGluIHRoZSBzcGVjIGFzIHlvdSBub3RlLCBzbyBJJ2xsIGFkZCBzb21l IHRleHQgYWJvdXQgdGhpcyBhbG9uZyB3aXRoIHRoZSByZXZpc2lvbiBvZiB0aGUgUGFja2V0IEZv cm1hdHMuDQo+IA0KPiBBbmQgdGhhdCdzIHdoZXJlIEknbSBjdXJyZW50bHkgYXQsIGFmdGVyIGEg ZmV3IGhvdXJzIG9mIGNvZGluZy4gSG9wZQ0KPiB0aGlzIGlzIHVzZWZ1bC4NCj4gDQo+IFllcywg ZXh0cmVtZWx5IHVzZWZ1bC4gVGhhbmtzIGFnYWluIGZvciB5b3VyIGVmZm9ydCBhbmQgZmVlZGJh Y2sgLS0gSSdsbCB0cnkgdG8gaW5jb3Jwb3JhdGUgYXMgbXVjaCBhcyBJIGNhbiBiZWZvcmUgdGhl IG5leHQgcmV2Lg0KPiANCj4gLSBqYW5hDQo+ICANCj4gTGFycw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBRVUlDIG1haWxpbmcgbGlzdA0KPiBR VUlDQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVp Yw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gUVVJQyBtYWlsaW5nIGxpc3QNCj4gUVVJQ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMNCg0K From nobody Fri Oct 21 05:05:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22A129547 for ; Fri, 21 Oct 2016 05:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3G6tTHL4cZd for ; Fri, 21 Oct 2016 05:05:05 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F5B12951C for ; Fri, 21 Oct 2016 05:05:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,376,1473145200"; d="scan'208";a="152605867" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx144-out.netapp.com with ESMTP; 21 Oct 2016 05:04:10 -0700 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 05:04:20 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Fri, 21 Oct 2016 05:04:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XrInIBZZyIeumTpwmiZEzZBx5QfNaSTL/oP9OWd9LaY=; b=dR1/J/Z3Cx1R6e+Cow9dQshC8XmdUZWC9GN6RD3xyh0czJgqC1dmqbBtxkgPmHxBcfQyk1WzNt8Wt0sDGUoEDQoy12+4h3ZAFXUyNxn0dD249Vu3GHRt7BB23FpunP/uEYyn0uB5QGhUevwPcHIdsLsvGrRh+CcpYH4JLUoNPSc= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.16; Fri, 21 Oct 2016 12:04:19 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0659.025; Fri, 21 Oct 2016 12:04:19 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: Multiple frames of the same type per packet? Thread-Index: AQHSK5NAKh87wBm7K02DCL18z00xSA== Date: Fri, 21 Oct 2016 12:04:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3226) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 926d5d46-78fe-46bc-f27b-08d3f9aa6354 x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:4lC/W9gdEfkZgMJ38YoPnzaiThw7se/eLJjIAUziz/Ml/ZoinZaxrnMI2uqjC5V4rNPLNWWx9xpNmytYpX/mnI4iil+NzVyrnfTpw949cDzwZAoys1RNH27wSBqr1fxZxZT40guLQ/MPh6A0laqDVx+Ia+DRxD3Hd1ZiEBdB64hLzYEf2K950VZbrIsRN8wUDC/0NfFndPVvGRQ9Eln/2tpxasZcLb6nFpykmjyHU44k68k4PjPsKoMvaMDCVhD8MV4wV9muPxNt+NP/NS//awz4FgB9VJtO6vFVMzFlXrNg8rJVhW6KnHtoYFGwBWxoe3My2Ccg4388aZuTlFDNGCSwE0Vdf6fQZFhX4wmOIYU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 01026E1310 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(122556002)(87936001)(101416001)(450100001)(83716003)(10400500002)(5002640100001)(36756003)(7846002)(92566002)(8676002)(82746002)(81156014)(305945005)(86362001)(2900100001)(77096005)(81166006)(7736002)(1730700003)(2906002)(3280700002)(229853001)(2351001)(33656002)(102836003)(8936002)(110136003)(3660700001)(5640700001)(6116002)(11100500001)(3846002)(586003)(2501003)(99286002)(50986999)(57306001)(5660300001)(189998001)(107886002)(66066001)(97736004)(6916009)(68736007)(105586002)(106356001)(50226002)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <0157AAFF4C5AA440BBFC3F7655C24C9F@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 12:04:19.3788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Subject: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 12:05:07 -0000 Hi, Section 10 says: > 10. Frame Types and Formats >=20 > A single Regular Packet MAY contain multiple frames and multiple > frame types. However, it remains unclear if a regular packet is permitted to contain mul= tiple frames of the same type. I guess this should be permitted for STREAM = frames. But is there any reason to permit this for any of the other frame t= ypes? Thanks, Lars= From nobody Fri Oct 21 06:13:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C05B1296FA for ; Fri, 21 Oct 2016 06:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4EFofwRCm6k for ; Fri, 21 Oct 2016 06:13:35 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8057A129526 for ; Fri, 21 Oct 2016 06:13:34 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bxZdb-00063r-OF for quic@ietf.org; Fri, 21 Oct 2016 15:13:32 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bxZaS-0004PM-FE for quic@ietf.org; Fri, 21 Oct 2016 09:13:29 -0400 Received: (qmail 29279 invoked from network); 21 Oct 2016 13:10:15 -0000 Received: from unknown (HELO [29.137.161.217]) (Authenticated-user:_huitema@huitema.net@[172.58.40.53]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2016 13:10:14 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Fri, 21 Oct 2016 06:10:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01689EBB-6B7C-4C16-B205-84620D700855@huitema.net> References: To: "Eggert, Lars" X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD1sm jqqpDd7/YPFh/AKPYjGJZuM0nKdm+UkzQVmfEavvdcmtTcWSOKD5RASVzg27inXh5noZfH+Ue/bn p6ZbxyV5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdItI+H292vaf+flnjcpZKBvi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suok3DPIWrP5+rmqhQ+VmxXJXgZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 13:13:36 -0000 There are good reasons to have multiple stream and stream control frames. No= t much point in having multiple ACK or similar frames, but we have to weight= the cost. Forbidding it means more code. The natural implementation is to p= rocess a queue of frames as they arrive in one or multiple packets. To forbi= d it you need to add code, and that can be a source of bugs. Now, there is another issue. Frames can be received and processed out of ord= er. We need to analyze for each frame what the consequences are. -- Christian Huitema=20 > On Oct 21, 2016, at 5:04 AM, Eggert, Lars wrote: >=20 > Hi, >=20 > Section 10 says: >=20 >> 10. Frame Types and Formats >>=20 >> A single Regular Packet MAY contain multiple frames and multiple >> frame types. >=20 > However, it remains unclear if a regular packet is permitted to contain mu= ltiple frames of the same type. I guess this should be permitted for STREAM f= rames. But is there any reason to permit this for any of the other frame typ= es? >=20 > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Fri Oct 21 06:14:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15FF129526 for ; Fri, 21 Oct 2016 06:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whCJNc-dojvj for ; Fri, 21 Oct 2016 06:14:18 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814951296FA for ; Fri, 21 Oct 2016 06:14:18 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id m5so85166261qtb.3 for ; Fri, 21 Oct 2016 06:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HqgHDtbWZLdb33gpfWovVT4aLCxWY3gUpU8SJkwhImI=; b=e/xJcWHW2XCaWABihrXeTAa5HvOeVlmIczlJw13U8cmbz4xuaNZG2g7moBwmm1l6ry zwqiHUyYqWSa/Ks5J7bM+ugNPq1q/5GjNt7ieiSHeaNsd7ihuYfFYJ4aO84EKzmqpsPG v319U16k2mOEzgkpEc5SVGehaNrxr/LGqxICfKvsFA1tOxjQiYaPeWYQTLnIv3VRIElk dqTx5NiHumtzPx4m7CCb1IDTz7hHj/ZnAEeVJpvZeFtQUw3vyPYbFiCRlBzlm5Pv/VxB DX6CdOWVzxPsJ8q/5h5UASdRmdWmY7RiU2FLGiaREKYcirqIE7my4q02NwL5TpcZffNa 8U5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HqgHDtbWZLdb33gpfWovVT4aLCxWY3gUpU8SJkwhImI=; b=aisDmBzB3v4O8lvKImTfCeVQVoi/U3TS05IlHm65YqokeOWH62IUBAl6N5q6OWBEWM M/tmSkhENQsnrzuY/eCaBvkbuGoE6JqMGoTDokDY3xpcdOIj4de0sRzlr3fiAKA+8x54 xxdoFscb8PNRxfIA7SFGaYDVxPinNXZibBasdjh1mMJXE6MIzBD8Q4TWSQfRfKO3BDhb gNNzXy8JFxxsdYVIHCyfiPKZxwAs7obG+ZxhBZ05KPyUdCra9NBmKQMb1NmfPAPzadiU TkpthZjl21UplCtq37GbsNv1fCQKlV2yv8mf+LZb10/kDpoKq/M5yd9qzwWX8p/ejrBR beIg== X-Gm-Message-State: ABUngvcbtRjCOooZhPzPngti5OnL1rim/38FnO/iSWFIvWXSQ2tFS3c7Jk9jzxpHz2HhTBerzANTvLZ/i8FOTZtN X-Received: by 10.194.242.1 with SMTP id wm1mr758918wjc.14.1477055657318; Fri, 21 Oct 2016 06:14:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.175.81 with HTTP; Fri, 21 Oct 2016 06:13:56 -0700 (PDT) In-Reply-To: References: From: Robbie Shade Date: Fri, 21 Oct 2016 09:13:56 -0400 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=089e013d1448c51e6e053f5fd1a3 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 13:14:20 -0000 --089e013d1448c51e6e053f5fd1a3 Content-Type: text/plain; charset=UTF-8 I think for any of the stream-specific frame types it makes sense to allow multiples in one packet. For example if an endpoint wants to reset N streams, they should be able to send a single packet with as many RST_STREAM frames packed in as possible, rather than sending N packets each with a single frame. The same argument applies to WINDOW_UPDATE, BLOCKED, and of course STREAM frames. On Fri, Oct 21, 2016 at 8:04 AM, Eggert, Lars wrote: > Hi, > > Section 10 says: > > > 10. Frame Types and Formats > > > > A single Regular Packet MAY contain multiple frames and multiple > > frame types. > > However, it remains unclear if a regular packet is permitted to contain > multiple frames of the same type. I guess this should be permitted for > STREAM frames. But is there any reason to permit this for any of the other > frame types? > > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --089e013d1448c51e6e053f5fd1a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think for any of the stream-specific frame types it make= s sense to allow multiples in one packet. For example if an endpoint wants = to reset N streams, they should be able to send a single packet with as man= y RST_STREAM frames packed in as possible, rather than sending N packets ea= ch with a single frame. The same argument applies to WINDOW_UPDATE, BLOCKED= , and of course STREAM frames.

On Fri, Oct 21, 2016 at 8:04 AM, Eggert, Lars <lars@neta= pp.com> wrote:
Hi,

Section 10 says:

> 10.=C2=A0 Frame Types and Formats
>
>=C2=A0 =C2=A0 A single Regular Packet MAY contain multiple frames and m= ultiple
>=C2=A0 =C2=A0 frame types.

However, it remains unclear if a regular packet is permitted to contain mul= tiple frames of the same type. I guess this should be permitted for STREAM = frames. But is there any reason to permit this for any of the other frame t= ypes?

Thanks,
Lars
_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--089e013d1448c51e6e053f5fd1a3-- From nobody Fri Oct 21 06:17:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE85912971B for ; Fri, 21 Oct 2016 06:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW-w4Jjf_Eqb for ; Fri, 21 Oct 2016 06:17:04 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603AF129715 for ; Fri, 21 Oct 2016 06:17:04 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bxZh0-0001pD-CJ for quic@ietf.org; Fri, 21 Oct 2016 15:17:03 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bxZgu-0000ai-1D for quic@ietf.org; Fri, 21 Oct 2016 09:17:00 -0400 Received: (qmail 29279 invoked from network); 21 Oct 2016 13:10:15 -0000 Received: from unknown (HELO [29.137.161.217]) (Authenticated-user:_huitema@huitema.net@[172.58.40.53]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2016 13:10:14 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Fri, 21 Oct 2016 06:10:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01689EBB-6B7C-4C16-B205-84620D700855@huitema.net> References: To: "Eggert, Lars" X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDwBN X4vIxZhYuKAWZ+/dkDFichJXWWichVCI9V/nUU9gdcmtTcWSOKD5RASVzg27iipWm9T+NduR4dWL Z2bCpe95kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdTKVpN/T1izsFH8GxvfdR5Pi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokZWuZCNTggpXQig+nII4NmQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 13:17:07 -0000 There are good reasons to have multiple stream and stream control frames. No= t much point in having multiple ACK or similar frames, but we have to weight= the cost. Forbidding it means more code. The natural implementation is to p= rocess a queue of frames as they arrive in one or multiple packets. To forbi= d it you need to add code, and that can be a source of bugs. Now, there is another issue. Frames can be received and processed out of ord= er. We need to analyze for each frame what the consequences are. -- Christian Huitema=20 > On Oct 21, 2016, at 5:04 AM, Eggert, Lars wrote: >=20 > Hi, >=20 > Section 10 says: >=20 >> 10. Frame Types and Formats >>=20 >> A single Regular Packet MAY contain multiple frames and multiple >> frame types. >=20 > However, it remains unclear if a regular packet is permitted to contain mu= ltiple frames of the same type. I guess this should be permitted for STREAM f= rames. But is there any reason to permit this for any of the other frame typ= es? >=20 > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Fri Oct 21 06:45:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD9129456 for ; Fri, 21 Oct 2016 06:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeBtyvgmWfYP for ; Fri, 21 Oct 2016 06:45:05 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2478212952F for ; Fri, 21 Oct 2016 06:45:05 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id u124so95023262ywg.3 for ; Fri, 21 Oct 2016 06:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YkJYnIsV6fgr+6/ycmtEpHI94RgPjV/t8Epx3FMSvZs=; b=XuRnr7eRcIbEEOBYNY8IKrqDZMLa2I/5v14LmRhPlQEJwlNddFDp6kACzVFfTRIx3K 0RVXPPRtaRakdwLjU0UbYnLTn5/wHjCUGC+t1saZuy+uT88IUTmqxGahNx6LvHBRnL3e 8jdJXB0IvVeF0hgeNMOxGw47j57Y4eLUXAjEG5C9P/fD9RvriwHZrUnDj2lNJUYsai5U 7Jvm0AnfyfcBUtFEVLhrm5qkN35xvXQVhKy12NY31S8wHzoh6GBWv6aBNGU3JZBBQlVU j5bV58QUFHanknczNjnwbVOMJQVkQqHpjBEmlRj/aD9qlK8avBr0WuJCwGzR3MuwKcEd XFYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YkJYnIsV6fgr+6/ycmtEpHI94RgPjV/t8Epx3FMSvZs=; b=aWXMN0Vf96JtDw4htz3fzzwtpDciZuwfQxlJksaOK4GQ04AuhUO0mDr9QtMRE5GSUf RHG69WRwB8RkfDhMI9kLkRXVpTanTozGRz0IkgBJJS/souXkfoD9PUtvZjK9Fnz9Ycw8 WAiGE9IEurEeI+IHf4wRCROldSRrt+SvTOY2vnpOnABywYFi8Y2uoDH/GZ5ZZ+Gw3hCh VCURpJmx7Me1eXy73kXN4hqBPOkqms41fQKh17dqL+UlrY+0WbMhrxb6F73DSljl2z89 X9yUMdH/1HhRmm40Z1sAD+s3T5WHIWMJ1l95UIKGNvYr7sPvBW85JVS8/7gEA7cr4imU SZJw== X-Gm-Message-State: ABUngvfbOtqBU6k/QY2YP5uJlM9/vze4yqpIEEsd3ueWglWVhNyX9mciS7AGKAUddOMvYAZvqd9SCvmPFP+t5oz9 X-Received: by 10.13.234.73 with SMTP id t70mr1098921ywe.12.1477057504184; Fri, 21 Oct 2016 06:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.39.135 with HTTP; Fri, 21 Oct 2016 06:44:43 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Fri, 21 Oct 2016 09:44:43 -0400 Message-ID: To: "Eggert, Lars" , Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c086e6cdac24e053f603ff5 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 13:45:07 -0000 --94eb2c086e6cdac24e053f603ff5 Content-Type: text/plain; charset=UTF-8 Multiple reset stream, window update, or blocked frames would be valid as well. For other frame types, I believe it would not. It's likely worth clarifying this? On Fri, Oct 21, 2016 at 8:04 AM, Eggert, Lars wrote: > Hi, > > Section 10 says: > > > 10. Frame Types and Formats > > > > A single Regular Packet MAY contain multiple frames and multiple > > frame types. > > However, it remains unclear if a regular packet is permitted to contain > multiple frames of the same type. I guess this should be permitted for > STREAM frames. But is there any reason to permit this for any of the other > frame types? > > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --94eb2c086e6cdac24e053f603ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Multiple reset stream, window update, or blocked frames wo= uld be valid as well.=C2=A0 For other frame types, I believe it would not.<= div>
It's likely worth clarifying this?

On Fri, Oct 21, 2016 at= 8:04 AM, Eggert, Lars <lars@netapp.com> wrote:
Hi,

Section 10 says:

> 10.=C2=A0 Frame Types and Formats
>
>=C2=A0 =C2=A0 A single Regular Packet MAY contain multiple frames and m= ultiple
>=C2=A0 =C2=A0 frame types.

However, it remains unclear if a regular packet is permitted to contain mul= tiple frames of the same type. I guess this should be permitted for STREAM = frames. But is there any reason to permit this for any of the other frame t= ypes?

Thanks,
Lars
_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--94eb2c086e6cdac24e053f603ff5-- From nobody Fri Oct 21 06:52:43 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B827C1297A8 for ; Fri, 21 Oct 2016 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb6oA1c9M9c2 for ; Fri, 21 Oct 2016 06:52:39 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F18B1297BE for ; Fri, 21 Oct 2016 06:52:39 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id CAF551C12CE; Fri, 21 Oct 2016 15:52:37 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id BC21C1C12C3; Fri, 21 Oct 2016 15:52:31 +0200 (CEST) (Extended-Queue-bit tech_jvddu@fff.in.tum.de) To: Ian Swett , "Eggert, Lars" , Jana Iyengar References: From: Joerg Ott Message-ID: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> Date: Fri, 21 Oct 2016 15:52:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 13:52:42 -0000 Christian's point that forbidding certain combinations requires checking and appropriate reaction and thus needs code and increases complexity is well taken. If multiple frames of the same type pertaining, e.g., to the same stream or connection, are included, it may make sense to clearly specify that must be handled in the order they appear in the packet and that state updates are performed on each such frame so that the next one only acts upon the outcome. This would lead to frame being treated the same no matter if they are in the same packet or not. (But I am not sure if this works for all the QUIC protocol machinery.) Jörg On 21.10.16 15:44, Ian Swett wrote: > Multiple reset stream, window update, or blocked frames would be valid > as well. For other frame types, I believe it would not. > > It's likely worth clarifying this? > > On Fri, Oct 21, 2016 at 8:04 AM, Eggert, Lars > wrote: > > Hi, > > Section 10 says: > > > 10. Frame Types and Formats > > > > A single Regular Packet MAY contain multiple frames and multiple > > frame types. > > However, it remains unclear if a regular packet is permitted to > contain multiple frames of the same type. I guess this should be > permitted for STREAM frames. But is there any reason to permit this > for any of the other frame types? > > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > From nobody Fri Oct 21 12:13:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFE11294D4 for ; Fri, 21 Oct 2016 12:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz8XUNkR9pgy for ; Fri, 21 Oct 2016 12:13:22 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A991296A9 for ; Fri, 21 Oct 2016 12:13:21 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 66so2153939itl.1 for ; Fri, 21 Oct 2016 12:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=VzhIkl/Y+FS+GEWjkCrZm0mlDVBGDpIFQuxM/kRvs+o=; b=E5z6aWL/QMdffjTR5IHZgS802xLS+SdzbSLB+gvq2C+UXVxHmh32DHGxoTBl7ZdMol cDGevNgJNkSRQIcvQ0x04RpfxbwIjEOEHwP6938JwKRP3paUpapzSrB6H563HMG4YFFn ilfkQMojU5yqgZYlfXfcExIEO9IzsGF/IdBLkwhSV0a1QC4HO59fGV6LbIYixEl+TW8/ JiKEHuxkYdrHFlrttBLNd09/UusjRbgcwPZf+BCrmgme7nkji6G+YPuyPqTJ0V0ab+2M MiXlyuHfCEgB/3IRqhCMctHFrAJgmzp3rm3vMpsrPWwsaWkumMCxyx24Jn5YlJ0GSy+w vYgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VzhIkl/Y+FS+GEWjkCrZm0mlDVBGDpIFQuxM/kRvs+o=; b=PKTlIxisHrRwWzlY7blU11YxnwVSQNH9p9xxpb+PRGiBXUvy5YuZ6owjucC6DKDUda nktZpF67vPuLoGAnNJ9pG+IAQJRVXD3Ofgyu0rtPSam7BzPImkBAWqPIK9KAt1wd8S9t KNWP4RDibKhKoZZ1lSdYXlJKiIUTLAxWPEarVbpmOBUVIXxQQ7LaVoCTOHzqEIhsJFkf BqWzQ3GyTNNrVbCL04UgTcv92fkg0quK550oW2s/3c+h0t4H08q5R5FysnpwBDFbWRzQ SaYA7M7oMdHIuJ0zp86EoU+AnLxcWy6w4bPbj5TWTtZFQFv9dFIhbwo+jpRhxJLl9TBU c/ZQ== X-Gm-Message-State: AA6/9RmgGYPc/mN9u+BCgVWjk0RJnPVqftcdlmYFwR786K8vRjbzXxsCQRheiSH6j1gGXMHPfOpjm0k+FGPM0UU/ X-Received: by 10.36.117.133 with SMTP id y127mr15696101itc.111.1477077196200; Fri, 21 Oct 2016 12:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.67 with HTTP; Fri, 21 Oct 2016 12:13:15 -0700 (PDT) From: Jana Iyengar Date: Fri, 21 Oct 2016 12:13:15 -0700 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114aacbc9640c4053f64d5bd Archived-At: Cc: Mark Nottingham , lars Eggert , Spencer Dawkins Subject: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 19:13:24 -0000 --001a114aacbc9640c4053f64d5bd Content-Type: text/plain; charset=UTF-8 Hello folks, There's been some really useful feedback on some of the input drafts from folks on the list, and I'd like to update them before the drafts deadline, so the changes are part of the wg discussions in Seoul. I also wondered if folks had any specific comments on draft structure and split at this stage, so the authors of the input drafts could get those in before the conversation about adoption. Thanks for all the feedback so far, - jana --001a114aacbc9640c4053f64d5bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello folks,

There's been some really useful fe= edback on some of the input drafts from folks on the list, and I'd like= to update them before the drafts deadline, so the changes are part of the = wg discussions in Seoul. I also wondered if folks had any specific comments= on draft structure and split at this stage, so the authors of the input dr= afts could get those in before the conversation about adoption.

Thanks for all the feedback so far,
- jana
--001a114aacbc9640c4053f64d5bd-- From nobody Fri Oct 21 13:25:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB931296C9 for ; Fri, 21 Oct 2016 13:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVw5R7x0vS9t for ; Fri, 21 Oct 2016 13:25:33 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4468129428 for ; Fri, 21 Oct 2016 13:25:32 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id f193so5526522wmg.0 for ; Fri, 21 Oct 2016 13:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ZdFvVVzOPJ5jXfOtDW/IjmhOKrz7EW8ncZvbjDumf4I=; b=uCDpbKluCohuKowXtlXDI7QkzMhJHshopoZ7SCSyelo4+JloNENDCbRVQ0fnGVJAT/ 9rJLFdXw5QmSwtcX8CoFGzuB7uJsPq49FA6JX7eM4BHs9GAKkP9XLWveNSpoHT2BMMag grbazsGdpeKDtQGyN7SXMNx1T4AJbvkcG4M713DCTZnsVefFn4bwja42mS3Bfe5WF7S8 iF0amRRmZfmesFXLlNe9d6/hdGcP2FXpSwlbY9tr/SgLUVArpCjBI7sqKTQLxKWoS4xI 3yRjJF6zDVLimARHkhnZQs0lErHVTj8DreURPeKbk4MNj7XVtXKvz8FB/7lnj6GfaFeS wjbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZdFvVVzOPJ5jXfOtDW/IjmhOKrz7EW8ncZvbjDumf4I=; b=GVmL51aNjkoIn8su9wVhafw2skg3vUL1qwf8P9gubH5+YGX0bMW/BpflzX7Ejqq/qt f23/gmvZPtCxkLvRD82Iqe7rajgxXI3s5Lq2tWHiLZpbF+plKc90SuCucCNLIQc3iGNh XVzjNhE0Asl2/8D3Ive8E7kGRFy6nE5sUX0uncDqfOpV7ZbZSBEmB6mG9+zxe5WKxDOd YSRMEjwb1H/uiL9lnbfdnVO9JOxNMc07FznQS+V2jujmWVj4aYPHvJvEySHtOcTVxN2n 3JeZy24vIyfWGQdCxDuwg8lKCXLz1A16uT6ISazZRznr/o70+RDgImzrhVTPz1M+8kFy Tcjg== X-Gm-Message-State: AA6/9Rk8m5livzTERkETkcyK9zI56VcT43UulAYSS0G7ViU3/jN2YZI7EYYRDhpR66ozb6rW X-Received: by 10.28.194.7 with SMTP id s7mr4580447wmf.4.1477081531051; Fri, 21 Oct 2016 13:25:31 -0700 (PDT) Received: from Macintosh-6.local (41.175.16.95.dynamic.jazztel.es. [95.16.175.41]) by smtp.gmail.com with ESMTPSA id p9sm4647858wjs.11.2016.10.21.13.25.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Oct 2016 13:25:30 -0700 (PDT) To: quic@ietf.org References: From: marcelo bagnulo braun Message-ID: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> Date: Fri, 21 Oct 2016 22:25:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 20:25:36 -0000 Hi, I been wondering about this. Sometimes, i feel that the loss detection and reliability belongs to the protocol document (at least the basic loss detection and retransmision) and leave the congestion control in a separated document. I mean, it seems that loss detection and retransmission is too closely related to the basic protocol. But i dont really have a strong opinion. Regards, marcelo El 21/10/16 a las 21:13, Jana Iyengar escribió: > Hello folks, > > There's been some really useful feedback on some of the input drafts > from folks on the list, and I'd like to update them before the drafts > deadline, so the changes are part of the wg discussions in Seoul. I > also wondered if folks had any specific comments on draft structure > and split at this stage, so the authors of the input drafts could get > those in before the conversation about adoption. > > Thanks for all the feedback so far, > - jana > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Fri Oct 21 13:36:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56793129542 for ; Fri, 21 Oct 2016 13:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbPgekEyx8vK for ; Fri, 21 Oct 2016 13:36:23 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E8C129423 for ; Fri, 21 Oct 2016 13:36:23 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bxgY8-00076Y-3z for quic@ietf.org; Fri, 21 Oct 2016 22:36:21 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bxgXY-0006VT-Tq for quic@ietf.org; Fri, 21 Oct 2016 16:36:18 -0400 Received: (qmail 3345 invoked from network); 21 Oct 2016 20:35:44 -0000 Received: from unknown (HELO [30.98.51.77]) (Authenticated-user:_huitema@huitema.net@[208.54.83.131]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2016 20:35:43 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14A456) In-Reply-To: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> Date: Fri, 21 Oct 2016 13:35:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> To: marcelo bagnulo braun X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD4yA NTilqaLZCyjqLa74NKZR0N0v4g6VaK2m5WhxVdpudcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdbNYJZHmTztvoh1m9SAwL4/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokd0uMbDf1yoqZkUeJni0+RQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 20:36:25 -0000 There is a natural layering of stream controls on top of a packet transmissi= on layer, which itself depends on security negotiations performed on stream 1= . The packet transmission layer would specify packet transmission, ack and err= or detection, and packet level flow control and connection control. In my mi= nd, it should not specify retransmission, since that is stream specific, but= it should notify the stream level when a stream frame has been lost, or ack= nowledged. Congestion control should be pluggable. -- Christian Huitema=20 > On Oct 21, 2016, at 1:25 PM, marcelo bagnulo braun wr= ote: >=20 > Hi, >=20 > I been wondering about this. Sometimes, i feel that the loss detection and= reliability belongs to the protocol document (at least the basic loss detec= tion and retransmision) and leave the congestion control in a separated docu= ment. I mean, it seems that loss detection and retransmission is too closely= related to the basic protocol. >=20 > But i dont really have a strong opinion. > Regards, marcelo >=20 >=20 >=20 >> El 21/10/16 a las 21:13, Jana Iyengar escribi=C3=B3: >> Hello folks, >>=20 >> There's been some really useful feedback on some of the input drafts from= folks on the list, and I'd like to update them before the drafts deadline, s= o the changes are part of the wg discussions in Seoul. I also wondered if fo= lks had any specific comments on draft structure and split at this stage, so= the authors of the input drafts could get those in before the conversation a= bout adoption. >>=20 >> Thanks for all the feedback so far, >> - jana >>=20 >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >=20 >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Fri Oct 21 14:53:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07F612962D for ; Fri, 21 Oct 2016 14:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBNM0KeVAlfB for ; Fri, 21 Oct 2016 14:53:34 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296641293E3 for ; Fri, 21 Oct 2016 14:53:34 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e187so10168510itc.1 for ; Fri, 21 Oct 2016 14:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rmpDYB1qUzBendZS8WWb7p/T+htdA+jBCEAym8/HWJo=; b=GUgC35rB5o1MPntkVEXUPzBC0KiN03MEalvMOLVQMz+So8EKJxmwtjsE8BwU7CGBBd kkkPi8HjeXW+KpUeENXg/FmR/HjlcoCsjFpLPXpQM7zGHJSF99VVT+6MlslSRNyvOLwp z1ALmYoB+lhsH8iCXLI6X4c0rsvcJt2hn1VmB5Kd5TcMEC4SD5N45Ri0yWtBPBElkoDb 2PAiPDCZ0FlXDbUf2eqO0eLim1i8Wz3X6UEo3fEdQ+Rg0fbq2KXDhfzN4jufkaWyBMjK qg2O04bjrRWKsuD30OtTqaruQbQwNwCidsaIvCwhkJzvbGntP12u6/fa4Jr8uCCraI9f PXEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rmpDYB1qUzBendZS8WWb7p/T+htdA+jBCEAym8/HWJo=; b=F2fSk+1O8yxYhfNL5fChd0qhuqMWo/eebIRImh75YwHJXRpXJs5QNg1Mci4Knr6Uwz VoKSW4ulUWK6LQUZg4mvj/Jx+1fjKYkzCgKi8jEkJQEWOfpzHGNTuLph/eYcodVI2NJ4 Ip2fY514ZJG6vB58ZjQOXFtN4mh0K6orI0BpduIJwLyCP77fU6Ci4EIoY1ExYdYjX/IW YUoJR2neLKQnaSviltUJVXOfTDpPeUdD/Yx3EZLqA4x6iuRGZxxdG96Jtmexbr3zClhW 027TrpRxTuwn5/s9YXEz4pZzVKgtE2ZzgXfOCnh8LUBMHgJMf8+hshr3Ub8HIc2QMyCQ qmJA== X-Gm-Message-State: ABUngvc9CgXTkwXaS0PzrY/KZ/WEdaaFK3bshh/dvC09cIoHISYDfI1gHvmsUAvyoK6gcb95Kq8P8zmorY+9/rx1 X-Received: by 10.36.117.133 with SMTP id y127mr588643itc.111.1477086813246; Fri, 21 Oct 2016 14:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.67 with HTTP; Fri, 21 Oct 2016 14:53:32 -0700 (PDT) In-Reply-To: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> From: Jana Iyengar Date: Fri, 21 Oct 2016 14:53:32 -0700 Message-ID: To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a114aacbccebadd053f67122b Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 21:53:36 -0000 --001a114aacbccebadd053f67122b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think perhaps what the document should really be called is not "loss recovery", but "loss detection". Pretty much everything in the doc is expected to be about how to detect losses, and not so much about retransmitting. What gets retransmitted and/or rebundled in actually specified currently in the main protocol spec. Since loss detection is intertwined with the currently specified congestion controllers for TCP, it seems natural to combine them in a single doc. There were two reasons for moving the loss detection and CC out into a separate doc: so the main spec could be smaller, and so the loss detection mechanisms could be independently evolved (later) as updates to the loss recovery spec. Much like 793 and 2581 (though admittedly separate evolution was not the concern then.) It might also help with reviews later on, since, for example, folks in tcpm ought to be able to read, review, and understand the similarities with and differences from TCP in terms of loss detection without having to closely follow the rest of the QUIC spec. On Fri, Oct 21, 2016 at 1:25 PM, marcelo bagnulo braun wrote: > Hi, > > I been wondering about this. Sometimes, i feel that the loss detection an= d > reliability belongs to the protocol document (at least the basic loss > detection and retransmision) and leave the congestion control in a > separated document. I mean, it seems that loss detection and retransmissi= on > is too closely related to the basic protocol. > > But i dont really have a strong opinion. > Regards, marcelo > > > > El 21/10/16 a las 21:13, Jana Iyengar escribi=C3=B3: > >> Hello folks, >> >> There's been some really useful feedback on some of the input drafts fro= m >> folks on the list, and I'd like to update them before the drafts deadlin= e, >> so the changes are part of the wg discussions in Seoul. I also wondered = if >> folks had any specific comments on draft structure and split at this sta= ge, >> so the authors of the input drafts could get those in before the >> conversation about adoption. >> >> Thanks for all the feedback so far, >> - jana >> >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114aacbccebadd053f67122b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think perhaps what the docume= nt should really be called is not "loss recovery", but "loss= detection". Pretty much everything in the doc is expected to be about= how to detect losses, and not so much about retransmitting. What gets retr= ansmitted and/or rebundled in actually specified currently in the main prot= ocol spec. Since loss detection is intertwined with the currently specified= congestion controllers for TCP, it seems natural to combine them in a sing= le doc.

There were two reasons for moving the loss = detection and CC out into a separate doc: so the main spec could be smaller= , and so the loss detection mechanisms could be independently evolved (late= r) as updates to the loss recovery spec. Much like 793 and 2581 (though adm= ittedly separate evolution was not the concern then.) It might also help wi= th reviews later on, since, for example, folks in tcpm ought to be able to = read, review, and understand the similarities with and differences from TCP= in terms of loss detection without having to closely follow the rest of th= e QUIC spec.


<= div class=3D"gmail_quote">On Fri, Oct 21, 2016 at 1:25 PM, marcelo bagnulo = braun <marcelo@it.uc3m.es> wrote:
Hi,

I been wondering about this. Sometimes, i feel that the loss detection and = reliability belongs to the protocol document (at least the basic loss detec= tion and retransmision) and leave the congestion control in a separated doc= ument. I mean, it seems that loss detection and retransmission is too close= ly related to the basic protocol.

But i dont really have a strong opinion.
Regards, marcelo



El 21/10/16 a las 21:13, Jana Iyengar escribi=C3=B3:
Hello folks,

There's been some really useful feedback on some of the input drafts fr= om folks on the list, and I'd like to update them before the drafts dea= dline, so the changes are part of the wg discussions in Seoul. I also wonde= red if folks had any specific comments on draft structure and split at this= stage, so the authors of the input drafts could get those in before the co= nversation about adoption.

Thanks for all the feedback so far,
- jana


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a114aacbccebadd053f67122b-- From nobody Fri Oct 21 15:15:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0353129513 for ; Fri, 21 Oct 2016 15:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uixoQTEw4b4r for ; Fri, 21 Oct 2016 15:15:30 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D270D1294DB for ; Fri, 21 Oct 2016 15:15:27 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 4so12785175itv.0 for ; Fri, 21 Oct 2016 15:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qr/pUY9YY7Secuz2NDMSfpk7iMrmz0lKirVCD0JHxgU=; b=iKPxzdQ1nJ8Y1iZCtxAK51KgaH9xlRA05Zm2wUKmcBp3P4AGhJGpLSI7gD2pkY1tgw /VtX/xWzNxWsOIxNL6VBJdV3WTZxqQdUlASrTDHcPsUSh1mrLyoJqTnznbTAAfxEa84U pKCjUWXlcE0R/fjorHgNvmV88HVP5DASYemgENg0U/QV097pL5+/r64KDziru8DMC9Ia Afe3Se0CLhdsKScsiZbtpdhIkP6piVhhll85ONkmdkrw48i0vU3KY7zogTdsDL0AsPyo QDdFY5KQHxPRgucTuJAEDkgRXYJPT39aGMkbdAzByS5VBmWV2pAQaZHbxccygXINMK6g H9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qr/pUY9YY7Secuz2NDMSfpk7iMrmz0lKirVCD0JHxgU=; b=e+hHX4Dp+OoJhDwau8fl+MHSw0LF0jTxjMWkNiNhrc1dapWo3KzS5Jz/ErH2Qi9VR4 Bqe3C729qYr7Rn0dsfYVn7cZrHKBW/4daHUt7Rsa7cryt6FjLybES/XGPLVEVxiQWN75 xUDSCsHj+BjZzZa4ouwEtAgppTGDedlug+WDoFxRlAGBrP0iyd3pF6XS26zqCxgA26Lr K9IaMAweWoYgrt0SoxOrVDsyE4M33N5UDH3r48UBA8kI5kisJ/HCQoXKwzICsJ3WHeHJ Pmigvlj9UIPJ8ORPXQSoaw415T6Wt070mpokxjI2juDGkZ60/1+2lNJt1xkH8twO0Ucn NYvA== X-Gm-Message-State: ABUngveMEsNVhGu/kwtXhb4tkiDXVNrGTvINZvZt83uHefFoArYkZYpYn3V/XnATmLZNzRjrYEeNKkxVy9Dox8D8 X-Received: by 10.36.7.69 with SMTP id f66mr3289162itf.111.1477088127048; Fri, 21 Oct 2016 15:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.67 with HTTP; Fri, 21 Oct 2016 15:15:26 -0700 (PDT) In-Reply-To: <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jana Iyengar Date: Fri, 21 Oct 2016 15:15:26 -0700 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1143ee3e1dc41c053f676110 Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 22:15:32 -0000 --001a1143ee3e1dc41c053f676110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christian, I definitely like your layering in terms of an intellectual separation. Tell me if you think differently, but I think the documents roughly reflect some of the separation you suggest, but we've tried to keep the number of docs from becoming too large (we already have 4). The stream abstraction and the general protocol mechanisms for packet transmission are described in the core protocol spec. Since streams and connection signaling may require reliability, retransmissions and rebundling logic is described in this doc. The loss detection and congestion control spec describes how to use various signals to detect losses, and (will describe) how to modulate the congestion controller based on losses and received acks. This makes both the congestion controller and the loss detection pluggable. To be clear, even if these were to become a part of the core protocol document, I would have a strong recommendation in there for implementers to keep their congestion controller and loss detection machinery separate and pluggable. I think keeping the docs separate helps for reviews and later updates, i.e., "document pluggability." - jana On Fri, Oct 21, 2016 at 1:35 PM, Christian Huitema wrote: > There is a natural layering of stream controls on top of a packet > transmission layer, which itself depends on security negotiations perform= ed > on stream 1. > > The packet transmission layer would specify packet transmission, ack and > error detection, and packet level flow control and connection control. In > my mind, it should not specify retransmission, since that is stream > specific, but it should notify the stream level when a stream frame has > been lost, or acknowledged. > > Congestion control should be pluggable. > > -- Christian Huitema > > > On Oct 21, 2016, at 1:25 PM, marcelo bagnulo braun > wrote: > > > > Hi, > > > > I been wondering about this. Sometimes, i feel that the loss detection > and reliability belongs to the protocol document (at least the basic loss > detection and retransmision) and leave the congestion control in a > separated document. I mean, it seems that loss detection and retransmissi= on > is too closely related to the basic protocol. > > > > But i dont really have a strong opinion. > > Regards, marcelo > > > > > > > >> El 21/10/16 a las 21:13, Jana Iyengar escribi=C3=B3: > >> Hello folks, > >> > >> There's been some really useful feedback on some of the input drafts > from folks on the list, and I'd like to update them before the drafts > deadline, so the changes are part of the wg discussions in Seoul. I also > wondered if folks had any specific comments on draft structure and split = at > this stage, so the authors of the input drafts could get those in before > the conversation about adoption. > >> > >> Thanks for all the feedback so far, > >> - jana > >> > >> > >> _______________________________________________ > >> QUIC mailing list > >> QUIC@ietf.org > >> https://www.ietf.org/mailman/listinfo/quic > > > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a1143ee3e1dc41c053f676110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christian,

I definitely like your= layering in terms of an intellectual separation.

Tell m= e if you think differently, but I think the documents roughly reflect some = of the separation you suggest, but we've tried to keep the number of do= cs from becoming too large (we already have 4). The stream abstraction and = the general protocol mechanisms for packet transmission are described in th= e core protocol spec. Since streams and connection signaling may require re= liability, retransmissions and rebundling logic is described in this doc.

The loss detection and congestion control spec desc= ribes how to use various signals to detect losses, and (will describe) how = to modulate the congestion controller based on losses and received acks. Th= is makes both the congestion controller and the loss detection pluggable. T= o be clear, even if these were to become a part of the core protocol docume= nt, I would have a strong recommendation in there for implementers to keep = their congestion controller and loss detection machinery separate and plugg= able. I think keeping the docs separate helps for reviews and later updates= , i.e., "document pluggability."

- ja= na

On F= ri, Oct 21, 2016 at 1:35 PM, Christian Huitema <huitema@huitema.net&= gt; wrote:
Ther= e is a natural layering of stream controls on top of a packet transmission = layer, which itself depends on security negotiations performed on stream 1.=

The packet transmission layer would specify packet transmission, ack and er= ror detection, and packet level flow control and connection control. In my = mind, it should not specify retransmission, since that is stream specific, = but it should notify the stream level when a stream frame has been lost, or= acknowledged.

Congestion control should be pluggable.

-- Christian Huitema

> On Oct 21, 2016, at 1:25 PM, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
>
> Hi,
>
> I been wondering about this. Sometimes, i feel that the loss detection= and reliability belongs to the protocol document (at least the basic loss = detection and retransmision) and leave the congestion control in a separate= d document. I mean, it seems that loss detection and retransmission is too = closely related to the basic protocol.
>
> But i dont really have a strong opinion.
> Regards, marcelo
>
>
>
>> El 21/10/16 a las 21:13, Jana Iyengar escribi=C3=B3:
>> Hello folks,
>>
>> There's been some really useful feedback on some of the input = drafts from folks on the list, and I'd like to update them before the d= rafts deadline, so the changes are part of the wg discussions in Seoul. I a= lso wondered if folks had any specific comments on draft structure and spli= t at this stage, so the authors of the input drafts could get those in befo= re the conversation about adoption.
>>
>> Thanks for all the feedback so far,
>> - jana
>>
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a1143ee3e1dc41c053f676110-- From nobody Fri Oct 21 15:24:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FA8129534 for ; Fri, 21 Oct 2016 15:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H13--YsLR6v4 for ; Fri, 21 Oct 2016 15:23:57 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A752512943B for ; Fri, 21 Oct 2016 15:23:57 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m138so12819489itm.0 for ; Fri, 21 Oct 2016 15:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Meqj3feh/Fa5huNBDUDTVr7YtaQ62ryrp3QQ9v2Exsw=; b=EEa+v9uCg6M60w2yJDFRUZRCfZFcwvnenDMimX06WZUb56H2uecoA5o93BaxwLEAy8 BKQ3iQ0UB0XNuwMkFVCfsDu32bBAmymmK9ANZI8jQPTU23+ESEkzFi0XC9gLaY1oyiX6 VS5ZclZ0J3FPrtvat9+bR61GeawwcqVa1xpdJeE5t/DNAPt0v5fKAWPETM4rsVywmX3G K0KMLOemvmXS1HPUOqAmNIRV7xr441ljjXlrHskva5QLo22AgV4nqxOc0kSA551yKIum YWP3gNIxajpFr+gsODPc3WnVcdNcmhsGBjCe9CfnNu9LRm6Yt+3GJ83LK+UtNtYuGMrw Rp2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Meqj3feh/Fa5huNBDUDTVr7YtaQ62ryrp3QQ9v2Exsw=; b=QlwrXqeNkq6i3hNcVuGsfKByf/23f/atKWx13R2I40Sd0RY/YuNDRCu0vTftO17XtC H92hV/UaEvnbNwSkV/fACWX/rExzIoE/cFzPvFIb8y0iNWgRRWPhJiSixOkF9vZo5HUO OTEKh6Wu4N5bRErDZYcve1NFeKYua3ECYjxJ2UY9eEVcqSscwnn2U+Af5ew5ZduT+8bO A5nyeO/NJODjfubYEPMpZZVlzYBke8U3EfxPay8TrVqkLsntcQOBGJyxYhbn107XHezq 81AFFVjeBrZzPimiNlVgoJgq6Ovfq3XXPJDzPJ5tomn9K1HIz2mf3EotPGfb+BoXKnQv 12Jw== X-Gm-Message-State: ABUngvfz+FIvHsaSolnviQozDvssARpqVwXlX4u1N7JbAjm5hYI0hzo/WBWlLIIVp0S4YUUjC8yg22w4dfrvyDZi X-Received: by 10.36.7.69 with SMTP id f66mr3316852itf.111.1477088636948; Fri, 21 Oct 2016 15:23:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.24.67 with HTTP; Fri, 21 Oct 2016 15:23:56 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jana Iyengar Date: Fri, 21 Oct 2016 15:23:56 -0700 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1143ee3e821d78053f677fd6 Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 22:23:59 -0000 --001a1143ee3e821d78053f677fd6 Content-Type: text/plain; charset=UTF-8 One thing I meant to but forgot to mention: Tell me if you think differently, but I think the documents roughly reflect > some of the separation you suggest, but we've tried to keep the number of > docs from becoming too large (we already have 4). The stream abstraction > and the general protocol mechanisms for packet transmission are described > in the core protocol spec. Since streams and connection signaling may > require reliability, retransmissions and rebundling logic is described in > this doc. > (Since this doc has streams, it also has Flow Control.) I can see this doc being separated into two parts, split at the interface between the stream abstractions and the packet transport logic. I wonder how useful it would be to split this into two docs. We could point out that there are these two distinct parts to the transport (which we can do within the core protocol spec.) --001a1143ee3e821d78053f677fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One thing I meant to but forgot to mention:

Tell me if you think differently, but I think the= documents roughly reflect some of the separation you suggest, but we'v= e tried to keep the number of docs from becoming too large (we already have= 4). The stream abstraction and the general protocol mechanisms for packet = transmission are described in the core protocol spec. Since streams and con= nection signaling may require reliability, retransmissions and rebundling l= ogic is described in this doc.

= (Since this doc has streams, it also has Flow Control.) I can see this doc = being separated into two parts, split at the interface between the stream a= bstractions and the packet transport logic. I wonder how useful it would be= to split this into two docs. We could point out that there are these two d= istinct parts to the transport (which we can do within the core protocol sp= ec.)
=C2=A0
--001a1143ee3e821d78053f677fd6-- From nobody Fri Oct 21 16:23:33 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 246241296F2; Fri, 21 Oct 2016 16:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207014.28214.12078811512611826014.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:10 -0700 Archived-At: Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com Subject: [QUIC] quic - Requested session has been scheduled for IETF 97 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:10 -0000 Dear Cindy Morgan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Grand Ballroom 1 size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: irtfopen artarea ianaplan t2trg taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme Special Requests: If the schedule is tight, this could go in a 2-hour slot. --------------------------------------------------------- From nobody Sat Oct 22 00:29:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CF129691 for ; Sat, 22 Oct 2016 00:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1la1Lai-Oei for ; Sat, 22 Oct 2016 00:29:05 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81B8129672 for ; Sat, 22 Oct 2016 00:29:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,529,1473145200"; d="scan'208";a="152760989" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx144-out.netapp.com with ESMTP; 22 Oct 2016 00:28:31 -0700 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Oct 2016 00:28:41 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sat, 22 Oct 2016 00:28:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LFbqlqEd81YfWFLcvk+jBVkkRShPPYlePqBB20VFbik=; b=RucLdJhfZrnbAyjx9FS3fQseST59U8ogFI/naX7US1KTNcnVaLU/2pMfF2jt1mCDfrHXEb1fua4n3SBCKPvCb8NUc8xU9ErXhkqa0jRFvA45rNSimzBuiuR9bVLRiDQpeYs9F35/uuntjWrP/tckdYfiNy+ct9WsO90KgOKqDMc= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.16; Sat, 22 Oct 2016 07:28:40 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0659.025; Sat, 22 Oct 2016 07:28:40 +0000 From: "Eggert, Lars" To: Jana Iyengar Thread-Topic: [QUIC] Drafts structure and split Thread-Index: AQHSK886aGaFiSE3E0qv9dvrNBMw16C0FDKA Date: Sat, 22 Oct 2016 07:28:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3226) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31f2:c001:9ce7:5c3c:a630:fa9b] x-ms-office365-filtering-correlation-id: 99d9e03c-4754-4a2c-83b0-08d3fa4d0bae x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:oe1WpA+A0+oOR5+iPzEWR8LLM7UAS/AapbRQgEvncvF/vXR9XZM5lNeUpE2AMfm6djArDlNdFdMaKQwHsryIBHlKGttOXGZPcgtMqi6N+9VTlDfqFwUx2A7wJ7YfaotHvo6xlZxKFT/ohS7QUcuBS2iuDJ71oGx7877/MJ7iv7rsg+u4xNYtAIQEjh2VCvDTmj6+wOpS+xUQkIcCWDleGOtM+BIgTjDEQulNxZX69C8zRMVzEpT8BYkIQ1bxDgXLFiVustt4zDqsUjzF9snPQ1Y7P/G198nyW6BPJtDg55S03UqAub2otUSWEe1dJWrjDUEubfMGqIEJ7y8bMgvAF2eIaz1UnUvuXl+RgShp5BQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6043046)(6042046); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(377424004)(189002)(11100500001)(19580405001)(81156014)(4326007)(5660300001)(19580395003)(97736004)(57306001)(3280700002)(7736002)(7846002)(77096005)(106356001)(99286002)(2906002)(83716003)(87936001)(102836003)(6116002)(106116001)(50226002)(105586002)(2900100001)(586003)(5002640100001)(68736007)(8936002)(76176999)(10400500002)(36756003)(6916009)(101416001)(305945005)(33656002)(189998001)(4001150100001)(3660700001)(86362001)(8676002)(81166006)(82746002)(110136003)(50986999)(92566002)(122556002)(2950100002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2016 07:28:39.8358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: Cc: Mark Nottingham , "quic@ietf.org" , Spencer Dawkins Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 07:29:06 -0000 On 2016-10-21, at 21:13, Jana Iyengar wrote: > I also wondered if folks had any specific comments on draft structure and= split at this stage, so the authors of the input drafts could get those in= before the conversation about adoption. Without my chair hat on, I had been wondering if it makes sense to break ou= t the overview parts from core-protocols and stick into a new "start readin= g here" document. Lars= From nobody Sat Oct 22 01:53:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB811296E9 for ; Sat, 22 Oct 2016 01:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z83-5ALZ35nf for ; Sat, 22 Oct 2016 01:53:16 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AD91296F2 for ; Sat, 22 Oct 2016 01:53:15 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id n189so182176364qke.0 for ; Sat, 22 Oct 2016 01:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fmCeMm6sdHx67pxx+17B4H1hptisoEskuFge92u7UBw=; b=AbhChJ3M5P9OiL0HWUbK7eotCbI3RgnOCJ9JPn+eWk43RAS8Kw4DykJZTcEtoA30hF gpiVK3eCfTqKnEvo58ZmnrSKpXsODZd7gLEruCWO+QKKfAe0WjlxY5HNnWGXe2VDJ9cI z0uHmdNdoQl/gzPbBZQLJHwD8wWyqa1aTboyHjv8VenuNd+2haY4Jc1rUYlB8xeqlObf KzGfNA5IiqwE2SDVcg1FYhwEpsQBI/1qvDR1lekTjdY/3v+z27QH+O52zz63VeoRSSNE um1hiyFLvfHX3W0ZwOcapwc59WfnK22zLpCiNSloTgwC70SrtV5WCDPaCrCpecYWnO7W 74pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fmCeMm6sdHx67pxx+17B4H1hptisoEskuFge92u7UBw=; b=ZTgQvxVzgglZ1CiyzIwxLmAofnh806vaY1QxjBihhv2Y9+RiSFzBtWu757VevENCQK 9IXZ3Nw0GknoXAm9YGdx76Ovs1UatAgDRKZJvlo6xW3Q+9oQTf5OyQ3/yv8oIn8O4lfR dEmgVKmj3kZDsHRiAcr8earFlkvibNxYQX7BLGyxkiVITU3SaENYsIGPuveASdmtnCRd gj49kjBVS3miZ2n/DA+LHOM9FuqmDmt7XTbsPOOholoH8TQKGNAOl+yPgg741yHwelaz Mr3R8WydGoWACg8RSW3MDdNydCinczxOv2XASwq/ezcqo5xu/Ijuoj94Jts50aN9Cxju qNHg== X-Gm-Message-State: ABUngvc53MBH9MmXLjMik4XLtgHs2I+gO2LbCb07MVGemq+Ew6Tl3e/8XXv5Ia3H1y8RO9S51jTRPvQlpOT94Q== X-Received: by 10.55.158.139 with SMTP id h133mr6028993qke.202.1477126394895; Sat, 22 Oct 2016 01:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sat, 22 Oct 2016 01:53:14 -0700 (PDT) In-Reply-To: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> From: Martin Thomson Date: Sat, 22 Oct 2016 19:53:14 +1100 Message-ID: To: Joerg Ott Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , Ian Swett , "quic@ietf.org" , "Eggert, Lars" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 08:53:17 -0000 On 22 October 2016 at 00:52, Joerg Ott wrote: > Christian's point that forbidding certain combinations requires checking > and appropriate reaction and thus needs code and increases complexity is > well taken. You don't have to insist on the receiver enforcing this, all you have to do is permit them to. Of course, the most is gained when every implementation checks and reports it (by killing the connection or something equally visible, of course), then you find that mistakes are quickly identified. I get Christian's point, but the amount of extra code is worth it. Then you don't end up with systemic tolerance for bad implementations. From nobody Sat Oct 22 09:25:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D854E1294A2 for ; Sat, 22 Oct 2016 09:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD6qYGZo1ymy for ; Sat, 22 Oct 2016 09:25:05 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 123F912945D for ; Sat, 22 Oct 2016 09:25:04 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 62C631A030C; Sat, 22 Oct 2016 18:24:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0384C454-B593-4F69-88BD-1E96A76816ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Sat, 22 Oct 2016 18:24:27 +0200 Message-Id: References: To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , Mark Nottingham , "quic@ietf.org" , Spencer Dawkins Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 16:25:07 -0000 --Apple-Mail=_0384C454-B593-4F69-88BD-1E96A76816ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Oct 2016, at 09:28, Eggert, Lars wrote: >=20 > On 2016-10-21, at 21:13, Jana Iyengar wrote: >> I also wondered if folks had any specific comments on draft structure = and split at this stage, so the authors of the input drafts could get = those in before the conversation about adoption. >=20 > Without my chair hat on, I had been wondering if it makes sense to = break out the overview parts from core-protocols and stick into a new = "start reading here" document. FWIW, I had the same thought. Cheers, Brian >=20 > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_0384C454-B593-4F69-88BD-1E96A76816ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYC5K9AAoJEIoSt78L6kaj6AcQAIbwivfoOijbcNAvchXBEX75 ZFCeFW80Pb6iJhgevNv+z4NXyHpJBGqIUOhpHuV6w+k8AzVPT7QsxqEFx5OCMdhk u8KFUtySetK83kDBVHh8FDWkXjZllGuh8aFTwSbtx0o6wwttppbopwcDjuNL8+ms kJRK8QKNZKTCzMi+z2ZNJsWtZm7lXNoecg2+yZhqtdlpwZDgKTHnvIbgv7He/lRd GtgTTYmAlHklRgPq67i8Mc6pEzkXZTCAx9MXEIeY4m8Bifs7lfvEQQsag1KKDn5L EsgqP8PzO03CXTxxT9co31Pe6J5nP1Zqphli3KG3TiFqX2vOhDy1WN+1inLJ7YII ibmELKQo4F+7HR18v0fbOuXaEownRjGB6Ne8Lo+EjE++hCOQguZ5I3PM6pt0J5wk zNXvPReJ9rrXL0x7BpG22l9ve56dkpkLGnsJ5DSA3z3jwMEU+VehCV23m16Fdxgo vQjg+dea5DZZ+mq3DpZgOC++VfKTACZyOzhUzPbWHx0mHmvVykHYIVqVMVDoRf3L MlJ9uP6131Q7SEMoemWoUQH635hcuAZcz4J9ldbb70f6CtRyVXjacsR/LUk+onIe gTwe77P3x5CZtAzkaCHsez3Rq/UXX9OtFVTXPYeZUStwYpDUBKfTG6VTMFJvYJqL LToT8ogx8Tkg6huFmaDv =5KFV -----END PGP SIGNATURE----- --Apple-Mail=_0384C454-B593-4F69-88BD-1E96A76816ED-- From nobody Sat Oct 22 11:07:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F10129556 for ; Sat, 22 Oct 2016 11:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnhFii4zZHUu for ; Sat, 22 Oct 2016 11:07:17 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643F312944D for ; Sat, 22 Oct 2016 11:07:17 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1by0hP-0003Xu-2R for quic@ietf.org; Sat, 22 Oct 2016 20:07:15 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1by0gR-0003cR-Rm for quic@ietf.org; Sat, 22 Oct 2016 14:07:13 -0400 Received: (qmail 24650 invoked from network); 22 Oct 2016 18:06:15 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Oct 2016 18:06:15 -0000 From: "Christian Huitema" To: "'Martin Thomson'" , "'Joerg Ott'" References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> In-Reply-To: Date: Sat, 22 Oct 2016 11:06:11 -0700 Message-ID: <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHWgpYH6pq3ZWyQhJL+LulNFENsGQLq3H3XAKlO1uwCP0caGqB9e3OQ Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD5nM /T9q/sh6D+XUqHRSAiFNUtOXFy0hefkqSBMnmYsmdcmtTcWSOKD5RASVzg27iqvOPVJ3SnRg7eM0 KERedRd5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdmH1gZeWXJLsO6P2DBgM/q/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokGZF4dHDvKOr394oq9u2X8AZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept Archived-At: Cc: 'Jana Iyengar' , 'Ian Swett' , quic@ietf.org, "'Eggert, Lars'" Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 18:07:19 -0000 On October 22, 2016 1:53 AM, Martin Thomson wrote: > On 22 October 2016 at 00:52, Joerg Ott wrote: >> Christian's point that forbidding certain combinations requires checking >> and appropriate reaction and thus needs code and increases complexity is >> well taken. > > You don't have to insist on the receiver enforcing this, all you have > to do is permit them to. Of course, the most is gained when every > implementation checks and reports it (by killing the connection or > something equally visible, of course), then you find that mistakes are > quickly identified. Yes. Crowd immunity and all that. > I get Christian's point, but the amount of extra code is worth it. > Then you don't end up with systemic tolerance for bad implementations. I would be OK with something like "must not include the same frame type related to the same stream more than once per packet, may drop connections if encountering a packet that violates that rule." The point is that compliance is easy, it is quite natural to only process a particular stream once per packet, but enforcement is somewhat onerous. I would not want to end up with some kind of compliance test in which the tester sends malformed packets and flags the implementation as non-conforming because it did not implement the verification code. -- Christian Huitema From nobody Sat Oct 22 14:55:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BE41294D0 for ; Sat, 22 Oct 2016 14:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sm5ixBbNLPh for ; Sat, 22 Oct 2016 14:55:29 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24376126D74 for ; Sat, 22 Oct 2016 14:55:29 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o68so194798286qkf.3 for ; Sat, 22 Oct 2016 14:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GaLlo70kbJZrNQmn1n4L2jjOjB5DHJM43l+kkNS9/QA=; b=BxXxkP7uZs9fZ+VtKFuxupS7Uoa8mjPNKRR61QHbEhzEDpDqXgaH/1OJQCe63iMEDy LEzRA7XDDBM9NJ65xhJX+zpueY/ezl6xQIQZMFXa7paEQAt8vZ+XPo0SJ3ocqTf8Yyhq vdJcyWN4fBX+goy4TDrz7T9Ow4YUAeGbQ8GP44Zsf3SIjjfeDIgWpVnlIcnT4nKRwtUs qVl9RdjZwlOJu3i9oOz2MDGbRRHfb3K+ZfS0UG9utqSSbySlSVX4s5ZoJNI0SuQkVtIG 8oD0x77+3VSscKIPLu8nW4xE+cOEb3cSJzLagkr6X6yLzbLtsULxZ4VkgGCVXO+XBg8R kebA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GaLlo70kbJZrNQmn1n4L2jjOjB5DHJM43l+kkNS9/QA=; b=PLzjMNDSa3ouh7tneosh+1A8N9GMeqOxLn3qlF2TyDzSttmsQrPRKbJFZRoGjNgHWo 2fBgFjwngi4htdIYpbEMRYOcSOnnIrVe5YAgA9dIpdfhD/N7m6kOKCn2cCL9Dipukwno /bjFQxAOApoQR9JrYTzum/XCgIPNtgwlliND1PjaYdsjZVPbIDQx1gkSnWJz1nCDZObf oxehZ7qE+6Jenju+x7PyHKBSSBjRoy5ZTR/PPmSKj0SZKbyMmzf7yTlvb5Eo2G9CS/fx AGDxnt2fyF+tzQUjlTlmM37sTn86g1YDnVmE+tNtY6W77VJjheKePf6s86ruoCxxY3u+ BrMQ== X-Gm-Message-State: ABUngvceaOgdOqZok1wdmeoTDxdW47MrGDUBlVrCNzeyfF9C0ic6cFa+np/3XVwqDOnrF7FsGcL8JZ1TNBP1jsRu X-Received: by 10.55.129.1 with SMTP id c1mr7865330qkd.53.1477173328142; Sat, 22 Oct 2016 14:55:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.98.134 with HTTP; Sat, 22 Oct 2016 14:55:27 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Victor Vasiliev Date: Sat, 22 Oct 2016 17:55:27 -0400 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c05a6fa7f4c4b053f7b373c Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 21:55:31 -0000 --94eb2c05a6fa7f4c4b053f7b373c Content-Type: text/plain; charset=UTF-8 My intuitive split would be: * Overview document * Packet layer document -- describes packet wire format, record-level protection, ACK/STOP_WAITING, loss detection and congestion control. * Stream layer document -- describes streams, flow control, and other higher-level issues. * Session establishment using TLS 1.3 * HTTP/2 mapping I believe this split would be useful for the implementers given that this layering seems to have worked out well in Google's current QUIC implementation. On Fri, Oct 21, 2016 at 6:23 PM, Jana Iyengar wrote: > One thing I meant to but forgot to mention: > > Tell me if you think differently, but I think the documents roughly >> reflect some of the separation you suggest, but we've tried to keep the >> number of docs from becoming too large (we already have 4). The stream >> abstraction and the general protocol mechanisms for packet transmission are >> described in the core protocol spec. Since streams and connection signaling >> may require reliability, retransmissions and rebundling logic is described >> in this doc. >> > > (Since this doc has streams, it also has Flow Control.) I can see this doc > being separated into two parts, split at the interface between the stream > abstractions and the packet transport logic. I wonder how useful it would > be to split this into two docs. We could point out that there are these two > distinct parts to the transport (which we can do within the core protocol > spec.) > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --94eb2c05a6fa7f4c4b053f7b373c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My intuitive split would be:
* Overview document
=
* Packet layer document -- describes packet wire format, record-level = protection, ACK/STOP_WAITING, loss detection and congestion control.
<= div>* Stream layer document -- describes streams, flow control, and other h= igher-level issues.
* Session establishment using TLS 1.3
* HTTP/2 mapping

I believe this split would be = useful for the implementers given that this layering seems to have worked o= ut well in Google's current QUIC implementation.

On Fri, Oct 21, 2016 at 6:2= 3 PM, Jana Iyengar <jri@google.com> wrote:
One thing I meant to but forgot to mention:<= div>
Tell me if you t= hink differently, but I think the documents roughly reflect some of the sep= aration you suggest, but we've tried to keep the number of docs from be= coming too large (we already have 4). The stream abstraction and the genera= l protocol mechanisms for packet transmission are described in the core pro= tocol spec. Since streams and connection signaling may require reliability,= retransmissions and rebundling logic is described in this doc.
=

(Since this doc has streams, it als= o has Flow Control.) I can see this doc being separated into two parts, spl= it at the interface between the stream abstractions and the packet transpor= t logic. I wonder how useful it would be to split this into two docs. We co= uld point out that there are these two distinct parts to the transport (whi= ch we can do within the core protocol spec.)
=C2=A0

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--94eb2c05a6fa7f4c4b053f7b373c-- From nobody Sun Oct 23 11:21:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87112954C for ; Sun, 23 Oct 2016 11:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKajx9ToYDKP for ; Sun, 23 Oct 2016 11:21:30 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DED91294DA for ; Sun, 23 Oct 2016 11:21:30 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id n189so210534019qke.0 for ; Sun, 23 Oct 2016 11:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6ktNHAr5piVVU0E+ez/xoNGnF25zBH1Nqd7p49Ob3Qg=; b=TjP7gyFIzB73mrzpBYexoXiodik02QPbULjJAOrELkfSlPZtdAvo2s28jhSgLIRETv 2KBpVdTCcvJx1TTPXLSUlrm+j4vxjhxth07RWQZ9rfHamL2hmHlqtlNn/OPm3BQw4J0Y ftleWRKwzlEnX6NbMnyNvml0Satfc93huWFJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6ktNHAr5piVVU0E+ez/xoNGnF25zBH1Nqd7p49Ob3Qg=; b=M7gdigybZQ6McF3lWQaD56UhAoPhTW/+PP/5XTJftTMrEnUPjF90ijoSYU4cNd0e5g B77qYFWaM2cJxIewujbznoPlsPID8Kl7l8VZocVii7NPlKxM5E7hckN9BH0eZUCobHm5 YfoNo3xdynXo3M/hTDKWZ+grqiss8F6HH4jW3QRamWC9lDos1qxuvsFfoqSkfJmVXRTw TYXNE06dxscXrkaRi5bYDkj4DSsCUO6pAdpi5e1f2YGRtMnaL0asFWmf7KlC5Ks9nDit 7vl5P3L1a/I9EECzc9mhA0kYYtvO/jxAunkqYRZirz1D8sWUNCWLx7fZSxm1GO44hYp4 p3YQ== X-Gm-Message-State: ABUngvd7jysrGBL3RpMnTqmdvsIpAWS4bZQ1TyXGCFVV35oZDZyT+PLJ4MsGkzERao1Oy7Td3IDkAW0SZHBnJw== X-Received: by 10.55.73.21 with SMTP id w21mr11293436qka.13.1477246889198; Sun, 23 Oct 2016 11:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Sun, 23 Oct 2016 11:21:28 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:db07:ffe3:95e5:2d3f] In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Kyle Rose Date: Sun, 23 Oct 2016 14:21:28 -0400 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114a980e139d34053f8c588e Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 18:21:32 -0000 --001a114a980e139d34053f8c588e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar wrote: > Tell me if you think differently, but I think the documents roughly > reflect some of the separation you suggest, but we've tried to keep the > number of docs from becoming too large (we already have 4). The stream > abstraction and the general protocol mechanisms for packet transmission are > described in the core protocol spec. Since streams and connection signaling > may require reliability, retransmissions and rebundling logic is described > in this doc. > Even though FEC implementations are out of scope for the current charter, it may make sense to structure the documents and the interfaces between layers such that loss detection and ECN are fully independent of correction and compensation mechanisms: these could be retransmits or FEC, but they could also be AQM or notifications to the application to, for example, reduce media quality. Kyle --001a114a980e139d34053f8c588e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 21, 2016 at 6:15 PM, Jana Iyengar <jri@google.com> wrot= e:
Tell me if you think = differently, but I think the documents roughly reflect some of the separati= on you suggest, but we've tried to keep the number of docs from becomin= g too large (we already have 4). The stream abstraction and the general pro= tocol mechanisms for packet transmission are described in the core protocol= spec. Since streams and connection signaling may require reliability, retr= ansmissions and rebundling logic is described in this doc.

Even though FEC implementations are out of scope for = the current charter, it may make sense to structure the documents and the i= nterfaces between layers such that loss detection and ECN are fully indepen= dent of correction and compensation mechanisms: these could be retransmits = or FEC, but they could also be AQM or notifications to the application to, = for example, reduce media quality.

Kyle
--001a114a980e139d34053f8c588e-- From nobody Sun Oct 23 16:55:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C825126CD8 for ; Sun, 23 Oct 2016 16:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD9Cdk14qYXS for ; Sun, 23 Oct 2016 16:55:42 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAC4129443 for ; Sun, 23 Oct 2016 16:55:42 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o68so215714343qkf.3 for ; Sun, 23 Oct 2016 16:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F1WHfzNd/d8lTJAgfAvqzhgK/5weX/r2fC4ed5qUqoM=; b=YScTT9oHmMIeFlSdfyVUDRv+RoU5GwZ6VpnOfKfZLoLSI0pih0p0nRU89hgr9L+GAW 5c10+xsBhQOfOweLN+y+L4+28fLq1nJ2CcHKyeIho4xRtFAXxJg0cNbkZ/ONf90hS6fM RXX81IAE1qUoOf9chjyv6sDISuspI+kLZwy9AUNrYLQSoV4yr/0u6P4ZWssC006u2142 Yw0JndhhZjTCNRCcQfGCLu92wFfh/Cm+Y5jiH+fkqPiUCnVRbt56G7OyivZp7flAHGZ5 ohK292zr60xGL4BpjRf/5MD23sSVOMIXUuAM0xFEJEP72+Em6HIaC22qyPTCORKoN7Kr H08g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F1WHfzNd/d8lTJAgfAvqzhgK/5weX/r2fC4ed5qUqoM=; b=W0R0N3VQ79BeLvPpderDXiscnnE3UY2gNm3xrM81hRw5fgDY0azuC5/AwldLCxIFuk dYWv0iCbnGiKcpMWIuNaRdHk0qt/+IlG0Tm+BThkvnC2WA7IWliecIMbyFSI7cRdGiSz QvK0N4KxFTGEMa0Qmsk2DtUhwIhiybN77ykoZDrbJLB4saF/WyK/4nRHSl/s6bT0DZ3+ dMlBWu+trgBPmnDalKq6HVX9ma7Y1w228U+q9jpNP5xNXIRtlnJpsFexNZOyEpVfzeXp 5ChL5qXe7cKazhoe3DUKLZdUFiewubyzWnnlSzFgf5ok+6vkqEfUYPAS5ln3LzTJqdSS 1p7g== X-Gm-Message-State: ABUngvdgJCv2rEmI2o44B/kTyiIaG4vYWDzZISLlOZNBZYuo0SKY4IBapIXX25zcmwa+qZQj+UF5tRqRUj6M4Q== X-Received: by 10.55.71.3 with SMTP id u3mr13483807qka.144.1477266941507; Sun, 23 Oct 2016 16:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 23 Oct 2016 16:55:40 -0700 (PDT) In-Reply-To: <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> From: Martin Thomson Date: Mon, 24 Oct 2016 10:55:40 +1100 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , Ian Swett , quic@ietf.org, "Eggert, Lars" , Joerg Ott Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 23:55:43 -0000 On 23 October 2016 at 05:06, Christian Huitema wrote: > I would be OK with something like "must not include the same frame type > related to the same stream more than once per packet, may drop connections > if encountering a packet that violates that rule." The point is that > compliance is easy, it is quite natural to only process a particular stream > once per packet, but enforcement is somewhat onerous. I would not want to > end up with some kind of compliance test in which the tester sends malformed > packets and flags the implementation as non-conforming because it did not > implement the verification code. Right, this is also my preference. Having the escape valve is particularly relevant in cases where your implementation is constrained in some way. From nobody Sun Oct 23 19:51:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4883412940E for ; Sun, 23 Oct 2016 19:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMIG5TBeBLYJ for ; Sun, 23 Oct 2016 19:50:59 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C551293E4 for ; Sun, 23 Oct 2016 19:50:59 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t193so163687330ywc.2 for ; Sun, 23 Oct 2016 19:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LyXgG3h17FmokfbU+vUAW/USY0wqnUnWkNRiW7u6k0Q=; b=fzOdnSuUg9dMBQKVA3VhIHsgh9j9JMjpUImqXWVFJCrezG9LsmhD/TxoTz39I/CNkV pExARSVmb+nxW0yYnp65P4oeX+lh83K1UtmONP0VAOz4yD46QStph6NCQ4nBC0av4Rm1 QEcecbGPr+rba2vmzUa+1y3TcTJcI0J5a6/LGuwCRTTWMmeTsVOcz9RoFQH0HfVsV8nB /nsBhu7YXM9WyWgDxmoBMxpxYRE5jFShSbfTO/+WPGgt9pbkObl04zu1qcr3BF4ceGEZ vxTv2Nikp1pil36WZi4AruS2OjqMFur3OYNUtXN6OFYk+c9F1eQRTxVDFWTQeskGh54V 7B6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LyXgG3h17FmokfbU+vUAW/USY0wqnUnWkNRiW7u6k0Q=; b=Z0s0GZToyHKdUYgGraA6T8Yn2rKpBQ13J/FKwnfy3Bh1bX3rrpO/ggWhOBMnBU9cd8 rhJpN18OemJdmfAYAfqurlKEYkbnKyzhCxYtKtzEBWo3JiDEL/75rOHgN0OsrlHqKxOH d6SU/2ZQ50bHYza0TVtXw3vF6sqVrLnrd4rFoxrVWWOWLG1W+catIjEM3K4l6siZxAhF 8txhiFnIe8xfODCWjg/E/rxQl1TADOFs0H2qBmKggqbTDkWyIBf9qh8qKlZiE8ZX9Fy4 NL3bgbWasLTq+uf2XBub6xuTKJgWZi6I4WpEyMOtqVhUgos2zPffFY1RdL/1951+mIM3 4z1Q== X-Gm-Message-State: ABUngvcYB3zWQ/gWXBTJkhmXSHNC+q0e7XtXi9WEHt24s0oqrrF9sV/m9wi/X+9WSlNz4WVo6Bau1BpPw48a4A== X-Received: by 10.13.209.1 with SMTP id t1mr15151934ywd.181.1477277458484; Sun, 23 Oct 2016 19:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.47.215 with HTTP; Sun, 23 Oct 2016 19:50:57 -0700 (PDT) Received: by 10.37.47.215 with HTTP; Sun, 23 Oct 2016 19:50:57 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Spencer Dawkins at IETF Date: Sun, 23 Oct 2016 21:50:57 -0500 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=001a114e519625ebcf053f9376bf Archived-At: Cc: marcelo bagnulo braun , Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:51:01 -0000 --001a114e519625ebcf053f9376bf Content-Type: text/plain; charset=UTF-8 Speaking as an AD who has been wrong before (references available on request), On Oct 23, 2016 13:21, "Kyle Rose" wrote: > > On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar wrote: >> >> Tell me if you think differently, but I think the documents roughly reflect some of the separation you suggest, but we've tried to keep the number of docs from becoming too large (we already have 4). The stream abstraction and the general protocol mechanisms for packet transmission are described in the core protocol spec. Since streams and connection signaling may require reliability, retransmissions and rebundling logic is described in this doc. > > > Even though FEC implementations are out of scope for the current charter, it may make sense to structure the documents and the interfaces between layers such that loss detection and ECN are fully independent of correction and compensation mechanisms: these could be retransmits or FEC, but they could also be AQM or notifications to the application to, for example, reduce media quality. > > Kyle > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > Whether or not the QUIC protocol ever does FEC, I'm thinking that the division between loss detection and loss recovery would be helpful. The observations that TCP ended up with the same split by accident that you folks are considering doing intentionally was helpful for me. Thanks, Spencer --001a114e519625ebcf053f9376bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Speaking as an AD who has been wrong before (references avai= lable on request),

On Oct 23, 2016 13:21, "Kyle Rose" <krose@krose.org> wrote:
>
> On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar <jri@google.com> wrote:
>>
>> Tell me if you think differently, but I think the documents roughl= y reflect some of the separation you suggest, but we've tried to keep t= he number of docs from becoming too large (we already have 4). The stream a= bstraction and the general protocol mechanisms for packet transmission are = described in the core protocol spec. Since streams and connection signaling= may require reliability, retransmissions and rebundling logic is described= in this doc.
>
>
> Even though FEC implementations are out of scope for the current chart= er, it may make sense to structure the documents and the interfaces between= layers such that loss detection and ECN are fully independent of correctio= n and compensation mechanisms: these could be retransmits or FEC, but they = could also be AQM or notifications to the application to, for example, redu= ce media quality.
>
> Kyle
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.iet= f.org/mailman/listinfo/quic
>

Whether or not the QUIC protocol ever does FEC, I'm thin= king that the division between loss detection and loss recovery would be he= lpful.

The observations that TCP ended up with the same split by ac= cident that you folks are considering doing intentionally was helpful for m= e.

Thanks,

Spencer

--001a114e519625ebcf053f9376bf-- From nobody Sun Oct 23 20:29:16 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9757112940D for ; Sun, 23 Oct 2016 20:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha9_a0fTZbOt for ; Sun, 23 Oct 2016 20:29:12 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5B51294C3 for ; Sun, 23 Oct 2016 20:29:12 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id f97so58123621ybi.1 for ; Sun, 23 Oct 2016 20:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FetvS8erT/cImQw9W89Rt0EDUCngzmVa+nvmVg8+JRw=; b=rMAUVwebON5n2RndvtOmigpvdMqLF+ynnVFBZQKAqFefxs9apbq0htLFatS9qc86P1 RvIX7KPLc8ubYowwuLNf0s3ZZnZwyrQL6zIkA6/KPYuJaEbS79b7m+/eE62vmfZbuaNj v5hbFcGiv/mkdExjENB/Bh/Pd+8GbuO7w2OpWjnCnZVg7Sf8MrFx74uBXoSpaLcgRBzj mMk1LrKp9NEvtRVOuAJzbf4aSoFDbXjNc3WYYEpWfuBf+RPJrblUmBh6qm0FbkGzI3lh H2MTEwGp6o2TJ742eHHykA376wJLoaSWEYakGerQCaOcFFbzUx37rHSrxnvWGiZu20Ql NVMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FetvS8erT/cImQw9W89Rt0EDUCngzmVa+nvmVg8+JRw=; b=Grz6lzLHWMw57Yu4MaQ/RUOom4vG9hhG4iuSR5fZ5PMlIIwJEE65ZiKBnStTOf0d06 7aYjYzAf48DxmYbn2rmrXmUVBAOiaKItLYbEgNGh80N7yXU1+aJruFG9NM9ckEdrl/z0 9mgX1HYeBVWRRxKfNRd9IYAbjbW0jlLzvRgoAd7GJKmAcK8SbOQ+0EdVf8ND909/yIIG acXpyMA62MpIaBcqdDaTREtQ+SaM6XpOPEgpJDNSqMjbXMEOEChRo7sGFku+IWXqmyMJ FQ8WhHApRDTUy7yJMYA1NGyGGbNpvRfeOyZJ5EAr+8HKL8MRz6Q8k4Q+vFnhPzswQ1VS Aolw== X-Gm-Message-State: ABUngvfTZMaGQuyZqAlk0zGYvhpQbE7c0w2RAbgC1HKm/ZWiZaq04Ew+dZ56qdrpp73shRPfP6IBONcSTgqy/A== X-Received: by 10.37.164.104 with SMTP id f95mr13876187ybi.49.1477279751343; Sun, 23 Oct 2016 20:29:11 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.51.137 with HTTP; Sun, 23 Oct 2016 20:29:10 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jim Roskind Date: Sun, 23 Oct 2016 20:29:10 -0700 X-Google-Sender-Auth: 532u6-LjizPPayTNRT-cj1Pk3-o Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=f403045c68e2d01557053f93feb3 Archived-At: Cc: marcelo bagnulo braun , Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 03:29:14 -0000 --f403045c68e2d01557053f93feb3 Content-Type: text/plain; charset=UTF-8 First off, it is super exciting to me personally to see QUIC progressing so well in the IETF!!! The Design and Rationale of QUIC stressed several things: a) The goal of QUIC was to reduce latency b) There were numerous gains to be made by integrating elements of highly evolved portions of traditional layered protocols. As a result, I'm hopefully to see fewer, rather than more, documents. I'm hoping to see tight and clear integration, rather than a layered protocol, with layered documentation, falling victim to the many latency losses of historical layers such HTTP over SPDY over TLS over TCP over IP. That cross layer integration has already shown remarkable gains in QUIC. For example, the integration of the crypto with awareness about packetization boundaries was a great boon for both connection establishment (low-latency handshakes; key change; etc.), as well as precluding of head of line blocking (induced at the level of IP packet loss, but historically surfacing in block encryption, if not TCP sequential streaming). A second example is the clarity of packet loss information provided by QUIC stream-content-rebundling (rather than packet re-transmission) has apparently enhanced even traditional TCP (RENO?) congestion control results. I'm very excited about the (finally published in ACM Queue) details of Google's Congestion Control algorithm entitled BBR (Buffer Bloat Reduction), which provides tremendous latency savings to TCP by minimizing buffer size, and hence buffer latency. I'm am filled with anticipation about the integrated benefits with QUIC (and its primary goal, to reduce latency), which should provide more precise transit-time information atop BBRs incredible published results, and hence still better monitoring of bottleneck buffer variations. With latency as a goal for QUIC, it is very desirable to tightly integrate such latency-enhancing advances. As a result, I'm hoping to see fewer, rather than more, independent documents. Each separate document will seemingly make it more difficult to discuss variations, and potential tight integration in the QUIC protocol. I do think it makes sense to separate discussion of packet loss detection (which serves as one of the signals to any congestion control algorithm) from stream-content restransmission (which is surely dependent on the application which QUIC serves), I don't see that such separation requires a separate document. I would however like some plugable API (for instance) to support unreliable transport (probably outside of standardization of existing practice). That said, I would like to see direct (status quo) discussion of how QUIC responds to retranmitted stream content, independent of cause/motivation (loss recovery? external IP packet replication due to transmission media events?). Bottom line: Hopefully fewer, well integrated documents. I'm certainly willing to help edit and work on any of these documents. Thanks, Jim Roskind (who is only an IETF noob, and could be getting confused by this discussion) On Sun, Oct 23, 2016 at 11:21 AM, Kyle Rose wrote: > On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar wrote: > >> Tell me if you think differently, but I think the documents roughly >> reflect some of the separation you suggest, but we've tried to keep the >> number of docs from becoming too large (we already have 4). The stream >> abstraction and the general protocol mechanisms for packet transmission are >> described in the core protocol spec. Since streams and connection signaling >> may require reliability, retransmissions and rebundling logic is described >> in this doc. >> > > Even though FEC implementations are out of scope for the current charter, > it may make sense to structure the documents and the interfaces between > layers such that loss detection and ECN are fully independent of correction > and compensation mechanisms: these could be retransmits or FEC, but they > could also be AQM or notifications to the application to, for example, > reduce media quality. > > Kyle > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --f403045c68e2d01557053f93feb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First off, it is super exciting to me personally to see QU= IC progressing so well in the IETF!!!

The Design and Rat= ionale of QUIC stressed several things:

a) The goal of Q= UIC was to reduce latency
b) There were numerous gains to be made= by integrating elements of highly evolved portions of traditional layered = protocols.

As a result, I'm hopefully to see f= ewer, rather than more, documents. I'm hoping to see tight and clear in= tegration, rather than a layered protocol, with layered documentation, fall= ing victim to the many latency losses of historical layers such HTTP over S= PDY over TLS over TCP over IP.

That cross layer in= tegration has already shown remarkable gains in QUIC. For example, the inte= gration of the crypto with awareness about packetization boundaries was a g= reat boon for both connection establishment (low-latency handshakes; key ch= ange; etc.), as well as precluding of head of line blocking (induced at the= level of IP packet loss, but historically surfacing in block encryption, i= f not TCP sequential streaming).

A second example = is the clarity of packet loss information provided by QUIC stream-content-r= ebundling (rather than packet re-transmission) has apparently enhanced even= traditional TCP (RENO?) congestion control results.

I'm very excited about the (finally published in ACM Queue) details = of Google's Congestion Control algorithm entitled BBR (Buffer Bloat Red= uction), which provides tremendous latency savings to TCP by minimizing buf= fer size, and hence buffer latency.=C2=A0 I'm am filled with anticipati= on about the integrated benefits with QUIC (and its primary goal, to reduce= latency), which should provide more precise transit-time information atop = BBRs incredible published results, and hence still better monitoring of bot= tleneck buffer variations. With latency as a goal for QUIC, it is very desi= rable to tightly integrate such latency-enhancing advances.

<= /div>
As a result, I'm hoping to see fewer, rather than more, indep= endent documents.=C2=A0 Each separate document will seemingly make it more = difficult to discuss variations, and potential tight integration in the QUI= C protocol.

I do think it makes sense to separate = discussion of packet loss detection (which serves as one of the signals to = any congestion control algorithm) =C2=A0from stream-content restransmission= (which is surely dependent on the application which QUIC serves), I don= 9;t see that such separation requires a separate document.=C2=A0 I would ho= wever like some plugable API (for instance) to support unreliable transport= (probably outside of standardization of existing practice).=C2=A0 That sai= d, I would like to see direct (status quo) discussion of how QUIC responds = to retranmitted stream content, independent of cause/motivation (loss recov= ery? =C2=A0external IP packet replication due to transmission media events?= ).

Bottom line: Hopefully fewer, well integrated d= ocuments.

I'm certainly willing to help edit a= nd work on any of these documents.

Thanks,

Jim Roskind (who is only an IETF noob, and could be getti= ng confused by this discussion)

On Sun, Oct 23, 2016 at 11:21 AM, Kyle Rose= <krose@krose.org> wrote:
On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar = <jri@google.com&= gt; wrote:
Tell m= e if you think differently, but I think the documents roughly reflect some = of the separation you suggest, but we've tried to keep the number of do= cs from becoming too large (we already have 4). The stream abstraction and = the general protocol mechanisms for packet transmission are described in th= e core protocol spec. Since streams and connection signaling may require re= liability, retransmissions and rebundling logic is described in this doc.

Even though FEC implementations= are out of scope for the current charter, it may make sense to structure t= he documents and the interfaces between layers such that loss detection and= ECN are fully independent of correction and compensation mechanisms: these= could be retransmits or FEC, but they could also be AQM or notifications t= o the application to, for example, reduce media quality.

Kyle

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--f403045c68e2d01557053f93feb3-- From nobody Mon Oct 24 07:24:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6891296DA for ; Mon, 24 Oct 2016 07:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqD3jmwz5Dnd for ; Mon, 24 Oct 2016 07:24:12 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E42129585 for ; Mon, 24 Oct 2016 07:24:11 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id i34so484877qkh.6 for ; Mon, 24 Oct 2016 07:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qKXFXDKh8pYIpO1YhjquCh1Mnni/9fO2yb37/8tMq80=; b=fVT+8aPm4Ja0joQOaD9XPzEvq7M/ph4JpeEuYABKXJAC26Y7d1O3GcBLxIRoMi2ppL t+ZtL4N3OM56o68w5UUSKhF4Db1xSVcHnsj3uaOtbwbjjFQ2Bx0yV/QQmF495ijCt/Ad nwdHD7TJ4iZ3br5nWPo+B50vMtpHq3jAKx/vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qKXFXDKh8pYIpO1YhjquCh1Mnni/9fO2yb37/8tMq80=; b=BMUaPICscbY1rSSvHedQ2AeB+NjfqARH/Tje6/7QjhUHpVXtOaT1zS7UyQxzG43vgD xxmF2GyuafuYaQyhBlReHhW5i2xk2xPP11gZCOblRmBFdJ7d/KcAWrF6DAkY4Iwwkbsm IOIiRtyiS6fyk7T7g6UajYbXb2Ro55YbcBwsvrVaEcCP5v3F8S1bpZlFx9IkmYurw9s9 X4HFb6JD28VFymGZrTGsA7F+hzKP/07JxYxj6jVsNMzEneZIuVls119uNzExXqyIlMru 2H9HXxFEgHDJtzOUI6NW11l0ROluXjrmLW/mw21MdgkfNUm6h2kwK8sAxP1Y97JgTopG iHaw== X-Gm-Message-State: ABUngvdbUPlui+uRI7jr7HrUshKnGSMEZX18m61j2bBM7ihmInYDsXVF71eT4/+MS4zSc8OyTaBPp6oYwpnXaQ== X-Received: by 10.55.32.195 with SMTP id g186mr15153438qkg.77.1477319050956; Mon, 24 Oct 2016 07:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Mon, 24 Oct 2016 07:24:10 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Kyle Rose Date: Mon, 24 Oct 2016 10:24:10 -0400 Message-ID: To: Jim Roskind Content-Type: multipart/alternative; boundary=001a11470c3a40bfef053f9d250c Archived-At: Cc: marcelo bagnulo braun , Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:24:13 -0000 --001a11470c3a40bfef053f9d250c Content-Type: text/plain; charset=UTF-8 On Sun, Oct 23, 2016 at 11:29 PM, Jim Roskind wrote: > As a result, I'm hopefully to see fewer, rather than more, documents. I'm > hoping to see tight and clear integration, rather than a layered protocol, > with layered documentation, falling victim to the many latency losses of > historical layers such HTTP over SPDY over TLS over TCP over IP. > Layering definitely requires more effort to get right (for some definition of "right": even the very wise cannot see all ends). Intentionally building a monolith creates a different set of problems. > For example, the integration of the crypto with awareness about > packetization boundaries was a great boon for both connection establishment > (low-latency handshakes; key change; etc.), as well as precluding of head > of line blocking (induced at the level of IP packet loss, but historically > surfacing in block encryption, if not TCP sequential streaming). > To get this right, one had to notice the tight interaction between the crypto and packetization in advance. No matter how the documents are structured, there are still two layers there and therefore still an interface between them: the question is whether to make the interface explicit and pluggable, or implicit and difficult to reuse. I don't think the number of documents actually matters all that much, but defining clear, bounded layers, along with appropriate information flow between them to enable current design goals (e.g., low latency) and foreseeable expanded functionality, does: putting effort in now will hopefully land the inevitable ossification in places that are easier for future protocol designers to deal with. Kyle --001a11470c3a40bfef053f9d250c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 23, 2016 at 11:29 PM, Jim Roskind <JimRoskind@gmail.com>= wrote:
As a resu= lt, I'm hopefully to see fewer, rather than more, documents. I'm ho= ping to see tight and clear integration, rather than a layered protocol, wi= th layered documentation, falling victim to the many latency losses of hist= orical layers such HTTP over SPDY over TLS over TCP over IP.

Layering definitely requires more effort to get rig= ht (for some definition of "right": even the very wise cannot see= all ends). Intentionally building a monolith creates a different set of pr= oblems.
=C2=A0
For example, the integration of the crypto wi= th awareness about packetization boundaries was a great boon for both conne= ction establishment (low-latency handshakes; key change; etc.), as well as = precluding of head of line blocking (induced at the level of IP packet loss= , but historically surfacing in block encryption, if not TCP sequential str= eaming).

To get this righ= t, one had to notice the tight interaction between the crypto and packetiza= tion in advance. No matter how the documents are structured, there are stil= l two layers there and therefore still an interface between them: the quest= ion is whether to make the interface explicit and pluggable, or implicit an= d difficult to reuse.

I don't think the number of do= cuments actually matters all that much, but defining clear, bounded layers,= along with appropriate information flow between them to enable current des= ign goals (e.g., low latency) and foreseeable expanded functionality, does:= putting effort in now will hopefully land the inevitable ossification in p= laces that are easier for future protocol designers to deal with.

Kyle

--001a11470c3a40bfef053f9d250c-- From nobody Mon Oct 24 16:07:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9F12960C for ; Mon, 24 Oct 2016 16:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC7WwJ9oF5k8 for ; Mon, 24 Oct 2016 16:06:59 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F18129476 for ; Mon, 24 Oct 2016 16:06:59 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id f133so20990305ybc.3 for ; Mon, 24 Oct 2016 16:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d6rvSVpP4GP1IORPVLFePtkXTkR7vJoElPQtq4bw5hE=; b=CtupTzbSRHqVXHwv6JqELiAfuLT0vhDM/v90E/6jlDBfusEY1EjaJnamCS/dlJohFi MGeGAUzGriUMGLcyZ0W1jyuWsqTLi9Ek6ngk43+W0jbWFrzmYDYH2UDUCLJBtOskdASP HRYTnM/vBssU1oCT9Etct120oXkP5zXYxD3n59dSyfzfGIeLhwjLvd35ZZ4I+5elIuq5 u1r4Mp47wSWA1S7/ME5L/cVM7KO3CFv5xn0cgRROyzJ0lpHOKSHg4rQ1n50XJXtyXez4 bYLmjRpv7jjYdlAjTYTKGq8CRV/cqso1Q3Ksu6c19nxTKzd4kFCRjjr9cB5kagQMLnz9 bkTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d6rvSVpP4GP1IORPVLFePtkXTkR7vJoElPQtq4bw5hE=; b=alwblM2Y++I6GFn3L2xAmJELP3yZPGluFZ4AyNHCTCpKF3j0rnaSiXWBZZR9Horf/M 7M/eDlrxfm7VkQzDidn79dRpbD97x1s8tdHoWksPoY1WNgkWG+F6x/cjZOgfoiDTaWrX BGDAjj1tfpvPH/M/ZXNmNAXNj2NF19RT8mc0l5YsaLq+FeN5YURC+fgdEj7fCVpo1/ZP aLMzBGfFTS2DwZrGu73Dms8fIBW80iAsZRD3W/ovItX+zStljwaLqmWvUBUb0TfhCDbh seA/g0F3JeAzu1sOsw3Yjrx1COcCHTcezN+oafk8G8bsXwKts+8DY+gUjx/MCXNnb6P9 FN9w== X-Gm-Message-State: ABUngvf6tqKBiKV74Rx3cdKgiP2T1Z1tNYJwK6UmPT5n3Ipiad8GJGDAukk5DjDw1nViocxteuKI7yld+gitJA== X-Received: by 10.37.86.130 with SMTP id k124mr6199572ybb.198.1477350418943; Mon, 24 Oct 2016 16:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.36.195 with HTTP; Mon, 24 Oct 2016 16:06:58 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Spencer Dawkins at IETF Date: Mon, 24 Oct 2016 18:06:58 -0500 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=001a1142cf12ee131b053fa4727e Archived-At: Cc: marcelo bagnulo braun , Jim Roskind , quic@ietf.org, Christian Huitema , Jana Iyengar Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 23:07:01 -0000 --001a1142cf12ee131b053fa4727e Content-Type: text/plain; charset=UTF-8 If I might offer an opinion, speaking as an individual ... On Mon, Oct 24, 2016 at 9:24 AM, Kyle Rose wrote: > On Sun, Oct 23, 2016 at 11:29 PM, Jim Roskind > wrote: > >> As a result, I'm hopefully to see fewer, rather than more, documents. I'm >> hoping to see tight and clear integration, rather than a layered protocol, >> with layered documentation, falling victim to the many latency losses of >> historical layers such HTTP over SPDY over TLS over TCP over IP. >> > > Layering definitely requires more effort to get right (for some definition > of "right": even the very wise cannot see all ends). Intentionally building > a monolith creates a different set of problems. > > >> For example, the integration of the crypto with awareness about >> packetization boundaries was a great boon for both connection establishment >> (low-latency handshakes; key change; etc.), as well as precluding of head >> of line blocking (induced at the level of IP packet loss, but historically >> surfacing in block encryption, if not TCP sequential streaming). >> > > To get this right, one had to notice the tight interaction between the > crypto and packetization in advance. No matter how the documents are > structured, there are still two layers there and therefore still an > interface between them: the question is whether to make the interface > explicit and pluggable, or implicit and difficult to reuse. > > I don't think the number of documents actually matters all that much, but > defining clear, bounded layers, along with appropriate information flow > between them to enable current design goals (e.g., low latency) and > foreseeable expanded functionality, does: putting effort in now will > hopefully land the inevitable ossification in places that are easier for > future protocol designers to deal with. > If people are expecting a loss recovery mechanism beyond the current version of BBR to ever appear in QUIC, what I would love is a plugable *document structure*, where the loss recovery text that is being updated, obsoleted, or will just be competing with existing mechanism(s) is clear, without opening parts of the spec that aren't changing. Thanks, Spencer, speaking as an individual --001a1142cf12ee131b053fa4727e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I might offer an opinion, speaking as an individual ...=

On Mon, Oct 24, 2= 016 at 9:24 AM, Kyle Rose <krose@krose.org> wrote:
On Sun, Oct 23, 2016 at 11:29 PM, Jim R= oskind <JimRoskind@gmail.com> wrote:
As a result, I'm hopefully to see fewer,= rather than more, documents. I'm hoping to see tight and clear integra= tion, rather than a layered protocol, with layered documentation, falling v= ictim to the many latency losses of historical layers such HTTP over SPDY o= ver TLS over TCP over IP.

Laye= ring definitely requires more effort to get right (for some definition of &= quot;right": even the very wise cannot see all ends). Intentionally bu= ilding a monolith creates a different set of problems.
=C2=A0
For example, the integration of the crypto with awareness = about packetization boundaries was a great boon for both connection establi= shment (low-latency handshakes; key change; etc.), as well as precluding of= head of line blocking (induced at the level of IP packet loss, but histori= cally surfacing in block encryption, if not TCP sequential streaming).

To get this right, one= had to notice the tight interaction between the crypto and packetization i= n advance. No matter how the documents are structured, there are still two = layers there and therefore still an interface between them: the question is= whether to make the interface explicit and pluggable, or implicit and diff= icult to reuse.

I don't think the number of document= s actually matters all that much, but defining clear, bounded layers, along= with appropriate information flow between them to enable current design go= als (e.g., low latency) and foreseeable expanded functionality, does: putti= ng effort in now will hopefully land the inevitable ossification in places = that are easier for future protocol designers to deal with.

If people are expecting a loss rec= overy mechanism beyond the current version of BBR to ever appear in QUIC, w= hat I would love is a plugable *document structure*, where the loss recover= y text that is being updated, obsoleted, or will just be competing with exi= sting mechanism(s) is clear, without opening parts of the spec that aren= 9;t changing.=C2=A0

Thanks,

Spencer, speaking as an individual=C2=A0
--001a1142cf12ee131b053fa4727e-- From nobody Mon Oct 24 16:16:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73D9129586 for ; Mon, 24 Oct 2016 16:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JesGR1mP83mi for ; Mon, 24 Oct 2016 16:16:01 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFDC129449 for ; Mon, 24 Oct 2016 16:16:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id w69so9936547qka.4 for ; Mon, 24 Oct 2016 16:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LGXIRpq/mUWncanulmg0XwQ0E3rN+FCklE1cNpsJu1E=; b=pbMqNYUEJ79J8n+hBf1t/b69MF4LDMmoFz46p7CNNgTfSZsb7ug7NG9sFrxbORYrz6 pxDvui1gpmb2LvB9OKNDMIsEaL7ka79OOTv2Se5kRmNtlrlkM61mFuRaqtJOQjxK64WK rdzjlxMxoXNtkS6Sd6VCMsbww+hLYCsL7//z1S7PrwTHn9u4uTh07H9IdqgCu9skUdAy xrobRaAh93Pku5uc3Cdz7nFFC2FcvJNPDpi4x09gT1qzzf2SsFaK+nxG+cSfH+0tcsQQ PBZHn9aUlp0o/ZG7CqKyEtd6acQZRvHaW/CQZ8zshUJRn54a/69Xg5p4kKUydGbeF3j+ wktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LGXIRpq/mUWncanulmg0XwQ0E3rN+FCklE1cNpsJu1E=; b=Q51YtO0SPjp/wyDIIz/Z4t/TuJDzcXR4s8KwlP3MtR/m5evBonRPqX98fhU2sTU/3y nMH1Ca5scphHf0Wvz02Agfxu4O4XE8t+Jg1gbpWgspxW1t1ePYK52bOAYA65Eqmrlx8S 0x5w168KYVogEUH1SR6VGI6mKY/3/NBCvQmVXsy8ceIll3o6eO1poi798UTOaDSMnBcp r+6htGEL1dm8ck4+4H4ln4+hR6o0i6j5+nb/lf2CGQah/DIGAepLo4S8xlD7phn/YqQt YiZ7A4hZXtSOfqb4TlqLoeK+FbebLMqFmhsGBSU9IooIEy73RwBDBT0DTkA63e8faszm Wk4w== X-Gm-Message-State: ABUngvdmiPb2tKmyOs8SBB5kHI6XaGQIMk1AumWcbwvgKACooUAGafzV0yxkSXjRxxoMSUanzh7OIwech1K8x2xa X-Received: by 10.55.0.65 with SMTP id 62mr7924259qka.106.1477350960119; Mon, 24 Oct 2016 16:16:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.98.134 with HTTP; Mon, 24 Oct 2016 16:15:59 -0700 (PDT) In-Reply-To: References: <900A1E2059ADB149B905E3C8FA0046A62D30CDBE1E@FHDP1LUMXC7V23.us.one.verizon.com> <88A0C673-2F84-470E-B118-6609EC07A682@trammell.ch> From: Victor Vasiliev Date: Mon, 24 Oct 2016 19:15:59 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114044603043b5053fa4939a Archived-At: Cc: Brian Trammell , "quic@ietf.org" Subject: Re: [QUIC] draft-trammell-plus-statefulness X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 23:16:03 -0000 --001a114044603043b5053fa4939a Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 6:43 AM, Martin Thomson wrote: > Lifting a choice piece. > > On 20 October 2016 at 21:19, Brian Trammell wrote: > > Right, but aren't all the QUIC header bits also integrity-protected? > > Let's quickly assess these: > 1. connection ID - routing critical, so I didn't see a need for > protection (though we would roll it into the handshake if it was > needed - most fall into this category) > 2. version - rolled into the handshake > 3. sequence number - forms the nonce (see TLS for analysis of this) > 4. public reset etc... - can't > > I realize now that I didn't write down the analysis of the first, so > that could be wrong. Cryptographically binding QUIC connection ID would be nice as an extra protection against possible confusion attacks. I agree with you that for the most of the values in the public header altering them would result in either routing or decryption failure. In the future, we might want to add values which we want everyone to read but want to authenticate between endpoints too (like the connection close signal). I feel like setting the AAD to the bytes of the public header is a fairly robust construction that solves this problem for any of the potential changes we make. It should be easy to implement, and most of the implementations already have to do AAD in TLS 1.2, so presumably there should not be any extra crypto code to write here. --001a114044603043b5053fa4939a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 20, 2016 at 6:43 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
Lifting a choice piece.

On 20 October 2016 at 21:19, Brian Trammell <ietf@trammell.ch> wrote:
> Right, but aren't all the QUIC header bits also integrity-protecte= d?

Let's quickly assess these:
1. connection ID - routing critical, so I didn't see a need for
protection (though we would roll it into the handshake if it was
needed - most fall into this category)
2. version - rolled into the handshake
3. sequence number - forms the nonce (see TLS for analysis of this)
4. public reset etc...=C2=A0 - can't

I realize now that I didn't write down the analysis of the first, so that could be wrong.

Cryptographically binding QUIC connection ID would be nice as an extra pro= tection
against possible confusion attacks.=

I agree with you that for the most of the values in t= he public header altering
them would result= in either routing or decryption failure.=C2=A0 In the future, we
might want to add values which we want everyone to r= ead but want to
authenticate between endpoi= nts too (like the connection close signal).=C2=A0 I feel
like setting the AAD to the bytes of the public header is a f= airly robust
construction that solves this = problem for any of the potential changes we make.
It should be easy to implement, and most of the implementations alre= ady have to
do AAD in TLS 1.2, so presumabl= y there should not be any extra crypto code to
write here.

--001a114044603043b5053fa4939a-- From nobody Mon Oct 24 17:31:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A99129525 for ; Mon, 24 Oct 2016 17:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO4asM0bCmrQ for ; Mon, 24 Oct 2016 17:31:29 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD6412943B for ; Mon, 24 Oct 2016 17:31:28 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u124so22487076ywg.3 for ; Mon, 24 Oct 2016 17:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcZldQxBH7uuoDp6Qk1V8pMN6b9B5z6HaDdc42sCq+o=; b=YUZDtzyPS84Od1/cI2v7SEhdVYUOiNaZ/Edlnx3Y+eJPXgUIWPikwJHB+1Icm3bQZs t/LWTBpPJ4Xf5Yz5ZYSn7A7yYlrkrT8ynu+jJlGTpj5WDX9NoTRuW9mxh9hadNiB/hki UcWp07oulaM7j/BKLHrEAIt4xYHtDOfbKgsgqsTCfKPmDmxGmPRJI0Nhl4HmDFz/YyJx joq9jmltgUoRjrjz6pN65VMffCVoOdOtFRl4clICGpVdtSs/UPz3zupkGZmWu08muu8j qBPDaDXYRhjG2MLAlkRS0giA0wRli0X6ipn8LGfL0eH1OMiDCgqESEOgysM/5avNNu2Y AWYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RcZldQxBH7uuoDp6Qk1V8pMN6b9B5z6HaDdc42sCq+o=; b=FHZTpcLT57Ams52RgPkRvNVRPjE5RC7tvCknxK+cDbahcqzrnh3MQ5R9gmBhcJGuuq PRy4RoWlF0PHMV3vb6Dxm1b7HVAJxgiBpes+d2DHz4huEW1+qeSxMZIAyQ/7xr4nnszh L06HQbrz7sU0uybLG8PqzmKXSrW4tkbQxIS0l4DkGzH9V7fjHYy6/NuEduo6ELZXRkw1 bukuVRnc4PVzwDO7iu5LA5VwKTa0SN7ZLEUSeicRz18t4z/Vz6OTK32auzbTJWflyWTJ WjZJmyTc/Yk+20gTV2HUfIXNpW/kCOGA1HofusMwQ9eopG44BzExX6pEZQQTggYCylzX j5gw== X-Gm-Message-State: ABUngvfeSzp/6uKTBUgf0CMRDwVvgaa3ZY1+YI4EYAyHlgIVvqzuAZKVLMqGb5LZ0e+vVDNwkfQqNk+o9ouVPB9y X-Received: by 10.129.117.134 with SMTP id q128mr20118962ywc.143.1477355487780; Mon, 24 Oct 2016 17:31:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.39.135 with HTTP; Mon, 24 Oct 2016 17:31:07 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Ian Swett Date: Mon, 24 Oct 2016 20:31:07 -0400 Message-ID: To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a1147eb280eb4fa053fa5a1ab Archived-At: Cc: Kyle Rose , Christian Huitema , Jana Iyengar , marcelo bagnulo braun , Jim Roskind , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 00:31:31 -0000 --001a1147eb280eb4fa053fa5a1ab Content-Type: text/plain; charset=UTF-8 Agreed, I think that structure makes sense, and as Kyle noted, makes experimentation with FEC more straightforward. One can easily imagine a loss recovery approach where a given stream frame is never retransmitted, but coded information is. It's worth noting that BBR is only a change to the congestion controller, and RACK is designed as a change the loss recovery. On Mon, Oct 24, 2016 at 7:06 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > If I might offer an opinion, speaking as an individual ... > > On Mon, Oct 24, 2016 at 9:24 AM, Kyle Rose wrote: > >> On Sun, Oct 23, 2016 at 11:29 PM, Jim Roskind >> wrote: >> >>> As a result, I'm hopefully to see fewer, rather than more, documents. >>> I'm hoping to see tight and clear integration, rather than a layered >>> protocol, with layered documentation, falling victim to the many latency >>> losses of historical layers such HTTP over SPDY over TLS over TCP over IP. >>> >> >> Layering definitely requires more effort to get right (for some >> definition of "right": even the very wise cannot see all ends). >> Intentionally building a monolith creates a different set of problems. >> >> >>> For example, the integration of the crypto with awareness about >>> packetization boundaries was a great boon for both connection establishment >>> (low-latency handshakes; key change; etc.), as well as precluding of head >>> of line blocking (induced at the level of IP packet loss, but historically >>> surfacing in block encryption, if not TCP sequential streaming). >>> >> >> To get this right, one had to notice the tight interaction between the >> crypto and packetization in advance. No matter how the documents are >> structured, there are still two layers there and therefore still an >> interface between them: the question is whether to make the interface >> explicit and pluggable, or implicit and difficult to reuse. >> >> I don't think the number of documents actually matters all that much, but >> defining clear, bounded layers, along with appropriate information flow >> between them to enable current design goals (e.g., low latency) and >> foreseeable expanded functionality, does: putting effort in now will >> hopefully land the inevitable ossification in places that are easier for >> future protocol designers to deal with. >> > > If people are expecting a loss recovery mechanism beyond the current > version of BBR to ever appear in QUIC, what I would love is a plugable > *document structure*, where the loss recovery text that is being updated, > obsoleted, or will just be competing with existing mechanism(s) is clear, > without opening parts of the spec that aren't changing. > > Thanks, > > Spencer, speaking as an individual > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a1147eb280eb4fa053fa5a1ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, I think that structure makes sense, and as Kyle no= ted, makes experimentation with FEC more straightforward.=C2=A0 One can eas= ily imagine a loss recovery approach where a given stream frame is never re= transmitted, but coded information is.

It's worth no= ting that BBR is only a change to the congestion controller, and RACK is de= signed as a change the loss recovery.

On Mon, Oct 24, 2016 at 7:06 PM, Spencer Da= wkins at IETF <spencerdawkins.ietf@gmail.com> wr= ote:
If I might offer an= opinion, speaking as an individual ...

On Mon, Oct 24, 2016 at 9:24 AM, Kyl= e Rose <krose@krose.org> wrote:
= On Sun, Oct 23, 2016 at 11:29 PM, Jim Roskind <<= a href=3D"mailto:JimRoskind@gmail.com" target=3D"_blank">JimRoskind@gmail.c= om> wrote:
As a result, I'm hopefully to see fewer, rather than more, documents. = I'm hoping to see tight and clear integration, rather than a layered pr= otocol, with layered documentation, falling victim to the many latency loss= es of historical layers such HTTP over SPDY over TLS over TCP over IP.

Layering definitely requires more = effort to get right (for some definition of "right": even the ver= y wise cannot see all ends). Intentionally building a monolith creates a di= fferent set of problems.
=C2=A0
For example, the integr= ation of the crypto with awareness about packetization boundaries was a gre= at boon for both connection establishment (low-latency handshakes; key chan= ge; etc.), as well as precluding of head of line blocking (induced at the l= evel of IP packet loss, but historically surfacing in block encryption, if = not TCP sequential streaming).

To get this right, one had to notice the tight interaction bet= ween the crypto and packetization in advance. No matter how the documents a= re structured, there are still two layers there and therefore still an inte= rface between them: the question is whether to make the interface explicit = and pluggable, or implicit and difficult to reuse.

I don&= #39;t think the number of documents actually matters all that much, but de= fining clear, bounded layers, along with appropriate information flow betwe= en them to enable current design goals (e.g., low latency) and foreseeable = expanded functionality, does: putting effort in now will hopefully land the= inevitable ossification in places that are easier for future protocol desi= gners to deal with.

If people are expecting a loss recovery mechanism beyond the curren= t version of BBR to ever appear in QUIC, what I would love is a plugable *d= ocument structure*, where the loss recovery text that is being updated, obs= oleted, or will just be competing with existing mechanism(s) is clear, with= out opening parts of the spec that aren't changing.=C2=A0
Thanks,

Spencer, speaking as an indivi= dual=C2=A0

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--001a1147eb280eb4fa053fa5a1ab-- From nobody Mon Oct 24 20:08:42 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEF9129526 for ; Mon, 24 Oct 2016 20:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1-_DPNHTPxT for ; Mon, 24 Oct 2016 20:08:39 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A97512950A for ; Mon, 24 Oct 2016 20:08:39 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id y123so4291048vka.3 for ; Mon, 24 Oct 2016 20:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fCE+NnZmVmBlogSGyFhBmvpGVpNYlEQ4ZBKOhoSWCrM=; b=mgKc/aA9Fl7MK3iA7Zu1QkUMmab7qWflZamrdjB9S/rT/3+icXbK6oGgQ0uwctoFxB tmuMVesUjz+Zq0LVIM2dQTGZXgJxez/QeKJX5RBtTKKOjOW99AhBCGqiRsoJaK7U9Fsu RsUVzwGo56ia5ynJ+og2QYPlVGjyWJHj85ZwaGH4sgleA7wIUwLlYqPzHZ4zdAgl1zlY B9RosOWRZgTmCdOv/4GL/UpPfaJQ3DCmVITfMbmfA5oZtJcVZL/2/pR05VKYS0ipO3X0 dQlm2hiqgLcRCbLhTG24ZVQ5lY4KSQrXGKDntV5rVUBKtwVGtBzQa4IKAPqA2YMraFcJ GcBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fCE+NnZmVmBlogSGyFhBmvpGVpNYlEQ4ZBKOhoSWCrM=; b=CLn/9N1gpLoCN6BYrNV8j8fSbJfJ+rUBhl4sZsA7mlLmsUo8saZkQsAh6ex2t8Tg/8 JbGPfnPyTj+wyaljPTFrjvMwPfnzDNQT4xdHAvNzvlt/VBq28ZnnimvH+vQXO4JEUDtz PDgd3E0T9/z4dQqTJwIXrHV4cEUh0E9ud7Y1CTFp2UgpZQdIOVHrWACB8r8LB3lJzzt6 thoo6gwtcZ2umbfek30IYRT+xzLDwfIYntE3uB5k2YjZ+hhCF8mX8julQdogrGUWlIEQ qiyUBM9LSYZCTjctxvm9ED5gD/pYp9OLqDhJ8goB/KkaVJAvHX1m3IDPTT0k7bCdeOVx 6REA== X-Gm-Message-State: ABUngveTOfrjZ5GKEzD9DBtFRd/Lne+/uvyjywsF/1aU63i5tqfgTOWfGD2iiNk9Io9ktGkdVgsPhgIcOqhX7Ct8 X-Received: by 10.31.7.147 with SMTP id 141mr13454624vkh.154.1477364918267; Mon, 24 Oct 2016 20:08:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Mon, 24 Oct 2016 20:08:37 -0700 (PDT) In-Reply-To: References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> From: Jana Iyengar Date: Mon, 24 Oct 2016 20:08:37 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1143d158287546053fa7d3b6 Archived-At: Cc: "Eggert, Lars" , Ian Swett , quic@ietf.org, Christian Huitema , Joerg Ott Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 03:08:41 -0000 --001a1143d158287546053fa7d3b6 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 23, 2016 at 4:55 PM, Martin Thomson wrote: > On 23 October 2016 at 05:06, Christian Huitema > wrote: > > I would be OK with something like "must not include the same frame type > > related to the same stream more than once per packet, may drop > connections > > if encountering a packet that violates that rule." The point is that > > compliance is easy, it is quite natural to only process a particular > stream > > once per packet, but enforcement is somewhat onerous. I would not want to > > end up with some kind of compliance test in which the tester sends > malformed > > packets and flags the implementation as non-conforming because it did not > > implement the verification code. > > Right, this is also my preference. Having the escape valve is > particularly relevant in cases where your implementation is > constrained in some way. > Two things are not clear to me: 1. Why are these checks necessary? I don't think they're necessary for correctness. 2. What's the incentive for a receiver to implement these checks? If it's work, and if _not implementing_ these checks allows for interop with more senders, why would a receiver implement these checks? As Christian said earlier, a natural sender would queue frames and packetize when deemed necessary. An inefficient sender may pack, for example, multiple stream frames belonging to the same stream in the same packet, but that's inefficient, not incorrect. A recommendation here can point to good practice. It seems reasonable to recommend that a sender SHOULD "not include the same frame type related to the same stream more than once per packet." Saying that a receiver MAY drop a connection that violates this agreement seems unnecessary. --001a1143d158287546053fa7d3b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 23, 2016 at 4:55 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 23 October 2016 at 05:06, Christian Huitema = <huitema@huitema.net> wrot= e:
> I would be OK with something like "must not include the same fram= e type
> related to the same stream more than once per packet, may drop connect= ions
> if encountering a packet that violates that rule." The point is t= hat
> compliance is easy, it is quite natural to only process a particular s= tream
> once per packet, but enforcement is somewhat onerous. I would not want= to
> end up with some kind of compliance test in which the tester sends mal= formed
> packets and flags the implementation as non-conforming because it did = not
> implement the verification code.

Right, this is also my preference.=C2=A0 Having the escape valve is<= br> particularly relevant in cases where your implementation is
constrained in some way.

Two things are not clear to me:
1. Why are these checks necessary? I don't think they're necessa= ry for correctness.
2. What's the incen= tive for a receiver to implement these checks? If it's work, and if _no= t implementing_ these checks allows for interop with more senders, why woul= d a receiver implement these checks?

As Christian said earlier, a natural sender = would queue frames and packetize when deemed necessary. An inefficient send= er may pack, for example, multiple stream frames belonging to the same stre= am in the same packet, but that's inefficient, not incorrect. A recomme= ndation here can point to good practice. It seems reasonable to recommend t= hat a sender SHOULD "not include the same frame type related to the sa= me stream more than once per packet." Saying that a receiver MAY drop = a connection that violates this agreement seems unnecessary.
--001a1143d158287546053fa7d3b6-- From nobody Mon Oct 24 20:30:53 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F971294AC for ; Mon, 24 Oct 2016 20:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlVLTIRWCfAy for ; Mon, 24 Oct 2016 20:30:50 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFC61293E4 for ; Mon, 24 Oct 2016 20:30:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,544,1473145200"; d="scan'208";a="153250821" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx144-out.netapp.com with ESMTP; 24 Oct 2016 20:29:56 -0700 Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Oct 2016 20:30:06 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 24 Oct 2016 20:30:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tCO//7rAry3a3xdpXU2sgGVd/1xotrD/frJdMHLwwSU=; b=RFoXSXlm4eSl2CJpQ28vWlbs147VFu3QK/SFXe2t5e5MdcrJMqfaSc0gEv0wAzWpgL5xDbrBQHwPwxI92za16Pt8zZ6ww64A45hKT6dgeBV5mqqPG3LTlTmPspqflKAu/pW9uU45wIh0pr6RpjQ1xZ3r1RBnxvGaFV67M5QPB0I= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Tue, 25 Oct 2016 03:30:06 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0659.025; Tue, 25 Oct 2016 03:30:06 +0000 From: "Eggert, Lars" To: Jana Iyengar Thread-Topic: [QUIC] Multiple frames of the same type per packet? Thread-Index: AQHSK5NB46aqx2eNAkiHgrZ6ErbJ5KCy62eAgAACNACAAT6xAIAAmn6AgAHz+QCAAcg+gIAABf4A Date: Tue, 25 Oct 2016 03:30:06 +0000 Message-ID: <302D7F50-B3F9-498C-900B-1953032E8053@netapp.com> References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3226) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31e3:fb01:f47f:3c91:4358:b648] x-ms-office365-filtering-correlation-id: 37053608-d7dc-4c48-d21d-08d3fc8736f3 x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:qoBwo0d9rwUk5ZBiqSW/2qJ4wwHTPjKYX716K9qmx7bAWVZMz5+mqrLzp+viKWz3H6D41eP+HCZJJCKMZDamluwH+JFTvSrOtsrrf4yVjiRWQs1NNP+dYN9p2xY04JIK2pLLjiAkJ1kh9wFZlo4Hv5NmdmLBxSxmMAdUHYAUUxL9kAUIz15Zaa2ZSHVK/QhlR8Xqy6RVaxorjoBgjUc+gD28KzPoILHTWnoy0a1imH57C0pdRiyVv9urv4F5EKdtk/AR91YRnGN8q55olcbm5Toi2b8+WTqIvM/zqrVWoVk16MgHiVh/vnLHdG2DGmFHFzIq8f5u4A27RKpQkUhKGhk1WlZW0hDilDPIFXPqGzk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(377424004)(189002)(10400500002)(76176999)(50986999)(8936002)(106116001)(7846002)(7736002)(101416001)(305945005)(50226002)(106356001)(5002640100001)(36756003)(2950100002)(122556002)(6916009)(19580405001)(68736007)(105586002)(33656002)(110136003)(8676002)(81156014)(2906002)(81166006)(4326007)(19580395003)(82746002)(3280700002)(93886004)(83716003)(57306001)(2900100001)(86362001)(77096005)(97736004)(5660300001)(586003)(189998001)(99286002)(6116002)(102836003)(92566002)(87936001)(3660700001)(4001150100001)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7BD53BB3A1EEA5478B20791A147D5EAC@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2016 03:30:06.0423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: Christian Huitema , Ian Swett , "quic@ietf.org" , Martin Thomson , =?iso-8859-1?Q?J=F6rg_Ott?= Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 03:30:52 -0000 On 2016-10-25, at 5:08, Jana Iyengar wrote: > Two things are not clear to me: > 1. Why are these checks necessary? I don't think they're necessary for co= rrectness. > 2. What's the incentive for a receiver to implement these checks? If it's= work, and if _not implementing_ these checks allows for interop with more = senders, why would a receiver implement these checks? >=20 > As Christian said earlier, a natural sender would queue frames and packet= ize when deemed necessary. An inefficient sender may pack, for example, mul= tiple stream frames belonging to the same stream in the same packet, but th= at's inefficient, not incorrect. A recommendation here can point to good pr= actice. It seems reasonable to recommend that a sender SHOULD "not include = the same frame type related to the same stream more than once per packet." = Saying that a receiver MAY drop a connection that violates this agreement s= eems unnecessary. That makes sense, and an uppercase SHOULD may not even be needed, i.e., the= explanation can be phrased in terms of the inefficiency you describe above= . (I raised the question, because when I read the text, I was wondering if my= code should throw a warning when it received such packets.) Lars= From nobody Mon Oct 24 20:33:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0165129542 for ; Mon, 24 Oct 2016 20:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsffBrF_odxe for ; Mon, 24 Oct 2016 20:33:46 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD1812952C for ; Mon, 24 Oct 2016 20:33:46 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 20so6617522uak.6 for ; Mon, 24 Oct 2016 20:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QOnlG/HlLo+e5L9IM17wQDnkbZYrIVO2GjmJ7Vu4sfY=; b=cgwNuJ+KQdzHA5X40pHNnGIiQIFTtae6VJ2DRCopW9cN6AC1IeP/Oyagh7yZXX1o3k k3dzQrfZr5DOE4EAFjo/1B88mstyaXP0upP4h1HXEGQaGXpL2tfRsajq3bU6lBEZdzwa Iaw0so+Otm3Vcpf7hiQ+w5F1HYhMSDgpUfeIw51xl6brDuzgKprP2ywLtL1MJyWBULSE FkE5FvWAcTlEiM8eqvbP5DShdNxJMxFntZ+Q+OZI6YEYSLu78Z1cRSetCNbfHw1Zo6Cx WErpCvnyEpWSe47rcb7MSmI8o0XTXxwMjxAAe2/1fizvtF90X9bZ/1wRKnKSIH3xgpxy 4mkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QOnlG/HlLo+e5L9IM17wQDnkbZYrIVO2GjmJ7Vu4sfY=; b=Lr3po4RCauJs9H9SV4g9lailnTMNXEwhcm7tP6D3pGxjh/Eqpc4Ah8aQK/GaT9Zh1n Qi4NghHOm9lZzn9iye23CYxm3Ce/YPH6s5gptUcPdbcQePrsBI+qTUdw+RW9MzLt+1MF 0mBTioysjHUDGf+E6D4tgZJ3OU+p2V6Q5cSg7vZYmldB0pfsWlcjyIS2XJ5s4533IoUG rdkRRoUTG3GtPBdsO32jW6Mk8Abru3NsVs7FTsYPacwZxbLcBJFVCMj00zNAYJsalcNa QrIGrpxZ81EKCNc8+JwskKhdVsjNQOnLMw/h9h+kDPR1+FOL/Vm9ZoTry4WmmEw1jX1a A16g== X-Gm-Message-State: ABUngvfumR3xYet+/gSF59ruB2+tupvMnYHe9a45jkkBFEq8vGr9oWNpG+GsBxUJPtJhO/1bOmnsqaNrXE+dsGs+ X-Received: by 10.176.6.194 with SMTP id g60mr7926174uag.103.1477366425079; Mon, 24 Oct 2016 20:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Mon, 24 Oct 2016 20:33:44 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jana Iyengar Date: Mon, 24 Oct 2016 20:33:44 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c122e78f8ddab053fa82cfa Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 03:33:48 -0000 --94eb2c122e78f8ddab053fa82cfa Content-Type: text/plain; charset=UTF-8 On Sun, Oct 23, 2016 at 11:21 AM, Kyle Rose wrote: > On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar wrote: > >> Tell me if you think differently, but I think the documents roughly >> reflect some of the separation you suggest, but we've tried to keep the >> number of docs from becoming too large (we already have 4). The stream >> abstraction and the general protocol mechanisms for packet transmission are >> described in the core protocol spec. Since streams and connection signaling >> may require reliability, retransmissions and rebundling logic is described >> in this doc. >> > > Even though FEC implementations are out of scope for the current charter, > it may make sense to structure the documents and the interfaces between > layers such that loss detection and ECN are fully independent of correction > and compensation mechanisms: these could be retransmits or FEC, but they > could also be AQM or notifications to the application to, for example, > reduce media quality. > Agreed, to detection vs. recovery. I think we could articulate this more explicitly in the core spec, so I'll give it a shot. I'll also ask you to remember this (and maybe suggest text if necessary) when reviewing the next rev of the document :-) On AQM/ECN, I expect that the signal will be passed to the congestion controller, and should therefore form part of the interface between the core protocol and the congestion controller. Any notificaitons to the application can be interactions with the congestion controller. Does that make sense? --94eb2c122e78f8ddab053fa82cfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 23, 2016 at 11:21 AM, Kyle Rose <krose@krose.org> wrot= e:
On Fri, Oct 21, 2016 at 6:15 PM, Jana Iyengar <= ;jri@google.com>= wrote:
Tell me i= f you think differently, but I think the documents roughly reflect some of = the separation you suggest, but we've tried to keep the number of docs = from becoming too large (we already have 4). The stream abstraction and the= general protocol mechanisms for packet transmission are described in the c= ore protocol spec. Since streams and connection signaling may require relia= bility, retransmissions and rebundling logic is described in this doc.

Even though FEC implementations ar= e out of scope for the current charter, it may make sense to structure the = documents and the interfaces between layers such that loss detection and EC= N are fully independent of correction and compensation mechanisms: these co= uld be retransmits or FEC, but they could also be AQM or notifications to t= he application to, for example, reduce media quality.

Agreed, to detection vs. recovery. I thi= nk we could articulate this more explicitly in the core spec, so I'll g= ive it a shot. I'll also ask you to remember this (and maybe suggest te= xt if necessary) when reviewing the next rev of the document :-)
=
On AQM/ECN, I expect that the signal will be passed to the c= ongestion controller, and should therefore form part of the interface betwe= en the core protocol and the congestion controller. Any notificaitons to th= e application can be interactions with the congestion controller. Does that= make sense?

--94eb2c122e78f8ddab053fa82cfa-- From nobody Mon Oct 24 21:55:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3C1296F9 for ; Mon, 24 Oct 2016 21:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxNJ6hH7116V for ; Mon, 24 Oct 2016 21:55:09 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3C2127735 for ; Mon, 24 Oct 2016 21:55:08 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id c126so6626480vkd.7 for ; Mon, 24 Oct 2016 21:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRcLO1LJd48KPFmlWvGiw2hPC8TiVas7JRswn0/wIxQ=; b=oViCB707BGMxr3XRoX/PFtaLf/siSuIvE+xwXuFr3/nvJ9aJZEsUY1gilDv3tGTtIM lzNMq9lzad+XPMRD/Ya7RXjOJ8s0olcGtC6/h0P76vuKyUQREWJHu+VtmPgPM+t+/b84 CYin8+XWGNmzlKvqrrSItMrv+/kFsQ+HLui+WB4xg4eoQM7BCFsa+kpj+vcfLQC1Rd7o +qg+m1rDfR3cC4chHfOqg348JgigEGhliGCgr5q1umBtWfOxt4LB220x0V/jpTlr3gGq DJhNU2WA6LYVUAc6WtbLBmqAb7wUouOwOYS5M5rr21GPww2V71K+egNGiHuySpWZQrjB 3uVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uRcLO1LJd48KPFmlWvGiw2hPC8TiVas7JRswn0/wIxQ=; b=DIWOIZ6HzI1yYnxThBC7OlfP7oO5OBeBTxybQBfVniIPJAhnSuqPSGuQdPuFFKrcvT BbjSTi1yuak93umIOLp4qHjCnzwk1BnNnaMp02jdVJ3ece2I/e4esQe4pGKMEP9yYerk anp+idc/QB6zu8Zkqo1E75RnSeVB8RYoIdvG/kLTKLZn5PHoXsbSooHmiZNeeyVwwfYb Utd/vgnQ1mbbY8TCA17Rw4FGwBjNm9PyMhk4LmEE5iBwvEEKOO5naJ6Ml1bzx64J0L1x ViykIHEZRgh6DEleb89AVW1e/iHuZFgNUKc7ObX4+lVFpFHPRpS1U+fllK1mF0B+opBl M0+w== X-Gm-Message-State: ABUngvfbOIZvPcaLb17q9s0a9MnQntjrJ5Dw3im6ze2HDYz09nM7SnVBkBTEdoIV1iDTfuTLKocg4yDmyNufqazs X-Received: by 10.31.84.130 with SMTP id i124mr12196425vkb.66.1477371307957; Mon, 24 Oct 2016 21:55:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Mon, 24 Oct 2016 21:55:07 -0700 (PDT) In-Reply-To: <302D7F50-B3F9-498C-900B-1953032E8053@netapp.com> References: <37752c0c-ff3b-934c-fd7c-2a8c46fd2a98@in.tum.de> <01b301d22c8e$fb1bd890$f15389b0$@huitema.net> <302D7F50-B3F9-498C-900B-1953032E8053@netapp.com> From: Jana Iyengar Date: Mon, 24 Oct 2016 21:55:07 -0700 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a114e5bfc0361eb053fa9504f Archived-At: Cc: Christian Huitema , Ian Swett , "quic@ietf.org" , Martin Thomson , =?UTF-8?B?SsO2cmcgT3R0?= Subject: Re: [QUIC] Multiple frames of the same type per packet? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 04:55:11 -0000 --001a114e5bfc0361eb053fa9504f Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2016 at 8:30 PM, Eggert, Lars wrote: > On 2016-10-25, at 5:08, Jana Iyengar wrote: > > Two things are not clear to me: > > 1. Why are these checks necessary? I don't think they're necessary for > correctness. > > 2. What's the incentive for a receiver to implement these checks? If > it's work, and if _not implementing_ these checks allows for interop with > more senders, why would a receiver implement these checks? > > > > As Christian said earlier, a natural sender would queue frames and > packetize when deemed necessary. An inefficient sender may pack, for > example, multiple stream frames belonging to the same stream in the same > packet, but that's inefficient, not incorrect. A recommendation here can > point to good practice. It seems reasonable to recommend that a sender > SHOULD "not include the same frame type related to the same stream more > than once per packet." Saying that a receiver MAY drop a connection that > violates this agreement seems unnecessary. > > That makes sense, and an uppercase SHOULD may not even be needed, i.e., > the explanation can be phrased in terms of the inefficiency you describe > above. > That seems reasonable to me. - jana > (I raised the question, because when I read the text, I was wondering if > my code should throw a warning when it received such packets.) > > Lars --001a114e5bfc0361eb053fa9504f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 24, 2016 at 8:30 PM, Eggert, Lars <lars@netapp.com> wrote:
On 2016-10-= 25, at 5:08, Jana Iyengar <jri@google.= com> wrote:
> Two things are not clear to me:
> 1. Why are these checks necessary? I don't think they're neces= sary for correctness.
> 2. What's the incentive for a receiver to implement these checks? = If it's work, and if _not implementing_ these checks allows for interop= with more senders, why would a receiver implement these checks?
>
> As Christian said earlier, a natural sender would queue frames and pac= ketize when deemed necessary. An inefficient sender may pack, for example, = multiple stream frames belonging to the same stream in the same packet, but= that's inefficient, not incorrect. A recommendation here can point to = good practice. It seems reasonable to recommend that a sender SHOULD "= not include the same frame type related to the same stream more than once p= er packet." Saying that a receiver MAY drop a connection that violates= this agreement seems unnecessary.

That makes sense, and an uppercase SHOULD may not even be needed, i.= e., the explanation can be phrased in terms of the inefficiency you describ= e above.

That seems reasonable to me.

- jana
=C2=A0
(I raised the question, because when I read the text, I was wondering if my= code should throw a warning when it received such packets.)

Lars

--001a114e5bfc0361eb053fa9504f-- From nobody Tue Oct 25 12:07:55 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5212998D for ; Tue, 25 Oct 2016 12:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71W26bbkPOSW for ; Tue, 25 Oct 2016 12:07:52 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210FB12998A for ; Tue, 25 Oct 2016 12:07:52 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id i34so27067564qkh.6 for ; Tue, 25 Oct 2016 12:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7rLREaxYvIMNoXbhrD0D6PgLaLyZrPHmVfVVJ9gBu/E=; b=OmGtYeYt1RPBbd/N/L7GOpNZfMWY+jX9ojOKIOYkpd281xFXl6Jz6HLxsHGJL+ypFO 4IOD4ADToctaSMFgsJOzl10IB9roi+FE/tpKoyQILiV/HiFb1RbgT2dqAIJY4lQF2Gxw a4weTE6YJwvMjzrUnzmVyQlN9XXnWSbdork4g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7rLREaxYvIMNoXbhrD0D6PgLaLyZrPHmVfVVJ9gBu/E=; b=g4jxF+Rzx+4nNwHqqWGK1Ui4eyg/f56M1+TqFl+Yeo8whZKRzA5VjueIS73u86m+SN zuyrk0UjZgHjpxQkUjS94KcZJMAdUnNuIty+hD4sOl09vd1Uoz5QxqW+2eXYhj5xchnn MUTUMqFUvjj21yxoRXY6a1EpUYvuB2QOTwXe485QfxwsJZ96idm64dF49Nq1moCJmNSi gpaHEh6EHmU+ozv+PGHiTd7o7sF5EHFj/lM2yUYzTzsy57ui3QtCxjRaD79dx6ObP38B QmdRCDqXZoBaqg2IChDi5VkQ0HhrogCbz8yG4S00LfPhdqeuPT/Eo41gFgr1vi0zL3U7 bHpw== X-Gm-Message-State: ABUngvdb89wV1nv509vDMPlegT6ZvOH5ufI59Sf4C7f1F3+hVJTn0U0pk8Z2WMToFP0j9TCUKs2bJaFVP7XXUg== X-Received: by 10.55.158.4 with SMTP id h4mr4752184qke.41.1477422471261; Tue, 25 Oct 2016 12:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Tue, 25 Oct 2016 12:07:50 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Kyle Rose Date: Tue, 25 Oct 2016 15:07:50 -0400 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c06f542955545053fb53984 Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:07:54 -0000 --94eb2c06f542955545053fb53984 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2016 at 11:33 PM, Jana Iyengar wrote: > Agreed, to detection vs. recovery. I think we could articulate this more > explicitly in the core spec, so I'll give it a shot. I'll also ask you to > remember this (and maybe suggest text if necessary) when reviewing the next > rev of the document :-) > Will do. > On AQM/ECN, I expect that the signal will be passed to the congestion > controller, and should therefore form part of the interface between the > core protocol and the congestion controller. Any notificaitons to the > application can be interactions with the congestion controller. Does that > make sense? > Some applications might care only about loss or preventing future loss ("does/will the client have enough information to reconstruct the stream, or do I need to retransmit/send more ECC?"), while others might care about congestion separately from loss (the previous question vs. "do I need to reduce the bitrate?"), so having separate signaling for the two cases makes a lot of sense. Kyle --94eb2c06f542955545053fb53984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 24, 2016 at 11:33 PM, Jana Iyengar <jri@google.com> wro= te:
Agreed, to dete= ction vs. recovery. I think we could articulate this more explicitly in the= core spec, so I'll give it a shot. I'll also ask you to remember t= his (and maybe suggest text if necessary) when reviewing the next rev of th= e document :-)

Will do.=C2=A0
On AQM/ECN, I expect that the signal will= be passed to the congestion controller, and should therefore form part of = the interface between the core protocol and the congestion controller. Any = notificaitons to the application can be interactions with the congestion co= ntroller. Does that make sense?

Some applications m= ight care only about loss or preventing future loss ("does/will the cl= ient have enough information to reconstruct the stream, or do I need to ret= ransmit/send more ECC?"), while others might care about congestion sep= arately from loss (the previous question vs. "do I need to reduce the = bitrate?"), so having separate signaling for the two cases makes a lot= of sense.

Kyle

--94eb2c06f542955545053fb53984-- From nobody Tue Oct 25 12:37:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597331295B8 for ; Tue, 25 Oct 2016 12:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epNj3nJE4FIo for ; Tue, 25 Oct 2016 12:37:11 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AD21299A9 for ; Tue, 25 Oct 2016 12:37:11 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id q126so182871813vkd.2 for ; Tue, 25 Oct 2016 12:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V/kXbK/4maxFPPQmazbNsL+RDQJOk1A2deDiepgAdeo=; b=TJiJERDSwqPfTkrkIneMu30Y0u+WNs94LR141WFiKK4ZEZOhEy3vyc/NW7i4uLrl08 3zOmaouw/19VQ0awdHYPE1jjSgbpt4Req+2LGHKjRDVIT6M+Tw4jjgrTwlDXhZOX91t8 UMMyCtqkeuH/u+qePdo3TAG5rD60d6CwPsRTrL8YMUoXR55WdryWJCkmwSzD9Ojlu42M DYZbm3tbUMN0BR3bSs9MTsWtjJnxFxoy5FtHGRFAcZ6MBeo2MRIHkoNl1pFJyFmqSwc+ GTp7geTA+BTjlql5utgI2pBwhNLE9jB9/wMezVGy3K/sV3lUL7fmASY2aZdbN74er5BW SL0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V/kXbK/4maxFPPQmazbNsL+RDQJOk1A2deDiepgAdeo=; b=SXUzUuxEHLBdt29ssz67agKaIlddKBhc/E5F4k1jUu3HMx3kyO3Ejas/u7Dh78gic+ TFUPtAg7ucKyv+oqEsKsEoRlv3YrQk+SJfjZ7Uu/g733kEICDpwvnDy5feeA8ilIfplL sxRUOnkRoylZfcGquHa43K4LJBF188wohOXnYeA0W/8rR2AsYsG5xtwv9Jcg+7pGWvpv cyv485XyBYZeSYJkwQ4zJtTWE8cxYFqIFtgfF704T8LYezNnGjB5hPC0jeaafAfy8RpD 2PznnqdDA6u57LC0GtO/MzXX1VOQZzCwqopJZBJaMFTTsGwijJRQgKyM1tIz2t3cQGi/ wN6g== X-Gm-Message-State: ABUngvcCbsIj2Hdn2aLrtG/B+HhDsa8EmSHWrsxR4xZE/1S35Gltiuk/lzpoZ+xyqqJk4TOtALmOe98k4Kl/go8J X-Received: by 10.31.186.195 with SMTP id k186mr15526093vkf.23.1477424230069; Tue, 25 Oct 2016 12:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Tue, 25 Oct 2016 12:37:09 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jana Iyengar Date: Tue, 25 Oct 2016 12:37:09 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=001a114410886aea79053fb5a28b Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:37:13 -0000 --001a114410886aea79053fb5a28b Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 12:07 PM, Kyle Rose wrote: > On Mon, Oct 24, 2016 at 11:33 PM, Jana Iyengar wrote: > >> Agreed, to detection vs. recovery. I think we could articulate this more >> explicitly in the core spec, so I'll give it a shot. I'll also ask you to >> remember this (and maybe suggest text if necessary) when reviewing the next >> rev of the document :-) >> > > Will do. > > >> On AQM/ECN, I expect that the signal will be passed to the congestion >> controller, and should therefore form part of the interface between the >> core protocol and the congestion controller. Any notificaitons to the >> application can be interactions with the congestion controller. Does that >> make sense? >> > > Some applications might care only about loss or preventing future loss > ("does/will the client have enough information to reconstruct the stream, > or do I need to retransmit/send more ECC?"), while others might care about > congestion separately from loss (the previous question vs. "do I need to > reduce the bitrate?"), so having separate signaling for the two cases makes > a lot of sense. > ECN signals indicate only congestion, not loss. My point was that congestion signals - explicit ones via ECN or implicit ones via loss/delay -- are all fed to the congestion controller. I agree that loss recovery is an entirely different matter, and that's a signal that comes out of the Loss Detection component. Make sense? If you're pointing out that congestion control and loss detection are separable, I agree. Perhaps this separation could be made explicit in the Loss Detection and Congestion Control doc? Or would you want to separate the two out? My earlier inclination was to keep fewer documents until they become large enough to need separation, but I can see arguments for document pluggability too. - jana > > Kyle > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a114410886aea79053fb5a28b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 25, 2016 at 12:07 PM, Kyle Rose <krose@krose.org> wrot= e:
On Mon, Oct 24, 2016 at 1= 1:33 PM, Jana Iyengar <jri@google.com> wrote:
<= span>
Agreed, to detection vs. recovery. I think we could articu= late this more explicitly in the core spec, so I'll give it a shot. I&#= 39;ll also ask you to remember this (and maybe suggest text if necessary) w= hen reviewing the next rev of the document :-)

Will do.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div>
On AQM/ECN, I expect that the signal will be passed to the c= ongestion controller, and should therefore form part of the interface betwe= en the core protocol and the congestion controller. Any notificaitons to th= e application can be interactions with the congestion controller. Does that= make sense?

Some applica= tions might care only about loss or preventing future loss ("does/will= the client have enough information to reconstruct the stream, or do I need= to retransmit/send more ECC?"), while others might care about congest= ion separately from loss (the previous question vs. "do I need to redu= ce the bitrate?"), so having separate signaling for the two cases make= s a lot of sense.

ECN signals i= ndicate only congestion, not loss. My point was that congestion signals - e= xplicit ones via ECN or implicit ones via loss/delay -- are all fed to the = congestion controller. I agree that loss recovery is an entirely different = matter, and that's a signal that comes out of the Loss Detection compon= ent. Make sense?

If you're pointing out that c= ongestion control and loss detection are separable, I agree. Perhaps this s= eparation could be made explicit in the Loss Detection and Congestion Contr= ol doc? Or would you want to separate the two out? My earlier inclination w= as to keep fewer documents until they become large enough to need separatio= n, but I can see arguments for document pluggability too.

- jana

=C2=A0
=
Kyle


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--001a114410886aea79053fb5a28b-- From nobody Tue Oct 25 14:34:35 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A855E129645 for ; Tue, 25 Oct 2016 14:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcnXd2ZuW12J for ; Tue, 25 Oct 2016 14:34:33 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D5B1294D0 for ; Tue, 25 Oct 2016 14:34:32 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id i34so29573120qkh.6 for ; Tue, 25 Oct 2016 14:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dAD2Ja+KadYkU3Nkql0J8zTQNjiOrncB3ALE1g3o6zM=; b=SG3L3/ajIGNCK2sW2yJAgJfKbvbXRp2yzXf/4fQDIJm+O28TawRnoOGRBURhN/2439 QP1eLlL6K2syVdtrrEHKodpSdzP9EgIaVmoAxwwNS1vHMRSP8y7aBts5kQgVqwJz5gM/ vaUK1gFd70g3vz6hcfwq7PS8lGr6xpkcWMmXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dAD2Ja+KadYkU3Nkql0J8zTQNjiOrncB3ALE1g3o6zM=; b=FvtJbrpjcU4hMsT1cLtYOuxNvTao6HDYzgUBOqmYHzZU821/RnCnHvAH0MpWQP0qyq /iLTG5p1LO/qSN4FvVaN/2K35jCIPIFdIyKXcP/b+9AnSWyR/4B2891jv2uV9HsGFK8K QDrP1CI9u016J/15uXuyteAT5WQOtkdPz/VgAMCH6VWLodZTHTyU91mKprhMlfSrOFNp RKkd1fzUzHMcpTUInFEwBAmY2Yd2MzodM9r1MMeAVMxOnfLEsRzHsaQfc60QPHN9rrnb FwY0wIGTaM2xhVUXgQuusAPeH9CKaJ2rVJp9hnoJsXyflfxF2FFoKn78IEMwWVa/UWDu tALw== X-Gm-Message-State: ABUngveRbJQsiY4kD5Kh2tpUQNkrH0eQqfcgVpSA88NJZTY73mTh60hqGl5EAeFxMdZSh2o6paaFxjTNfxQKrQ== X-Received: by 10.55.24.36 with SMTP id j36mr23371160qkh.268.1477431271826; Tue, 25 Oct 2016 14:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.45.68 with HTTP; Tue, 25 Oct 2016 14:34:30 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Kyle Rose Date: Tue, 25 Oct 2016 17:34:30 -0400 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a11429ba22346d5053fb7463b Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 21:34:35 -0000 --001a11429ba22346d5053fb7463b Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 3:37 PM, Jana Iyengar wrote: > ECN signals indicate only congestion, not loss. My point was that > congestion signals - explicit ones via ECN or implicit ones via loss/delay > -- are all fed to the congestion controller. I agree that loss recovery is > an entirely different matter, and that's a signal that comes out of the > Loss Detection component. Make sense? > Yep, I agree completely. I think maybe what I meant was more clearly stated as "Applications may (will?) want to react differently to loss or prospective loss from congestion, versus loss for other reasons (like poor wifi signal)." We may currently have difficulty distinguishing the former from the latter when ECN isn't a universal congestion signal, but having the proper interface in place allowing applications to tailor behavior based on improved future telemetry could be useful. > If you're pointing out that congestion control and loss detection are > separable, I agree. Perhaps this separation could be made explicit in the > Loss Detection and Congestion Control doc? Or would you want to separate > the two out? My earlier inclination was to keep fewer documents until they > become large enough to need separation, but I can see arguments for > document pluggability too. > I agree with Spencer's point about document pluggability: it's less important how many documents the WG produces than that they use encapsulation to make it easy to swap out or replace components later without having to individually update sentences from 17 different sections. Kyle --001a11429ba22346d5053fb7463b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 25, 2016 at 3:37 PM, Jana Iyengar <jri@google.co= m> wrote:
ECN signals indicate only con= gestion, not loss. My point was that congestion signals - explicit ones via= ECN or implicit ones via loss/delay -- are all fed to the congestion contr= oller. I agree that loss recovery is an entirely different matter, and that= 's a signal that comes out of the Loss Detection component. Make sense?=

Yep, I agree completely.= I think maybe what I meant was more clearly stated as "Applications m= ay (will?) want to react differently to loss or prospective loss from conge= stion, versus loss for other reasons (like poor wifi signal)." We may = currently have difficulty distinguishing the former from the latter when EC= N isn't a universal congestion signal, but having the proper interface = in place allowing applications to tailor behavior based on improved future = telemetry could be useful.
=C2=A0
If you're pointing out that congestion control and loss detection ar= e separable, I agree. Perhaps this separation could be made explicit in the= Loss Detection and Congestion Control doc? Or would you want to separate t= he two out? My earlier inclination was to keep fewer documents until they b= ecome large enough to need separation, but I can see arguments for document= pluggability too.

I agree with Spencer's point about document pluggabili= ty: it's less important how many documents the WG produces than that th= ey use encapsulation to make it easy to swap out or replace components late= r without having to individually update sentences from 17 different section= s.

Kyle

--001a11429ba22346d5053fb7463b-- From nobody Tue Oct 25 18:18:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862CD1299E4 for ; Tue, 25 Oct 2016 18:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUutRF8Ec2kN for ; Tue, 25 Oct 2016 18:18:42 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F8C1294DA for ; Tue, 25 Oct 2016 18:18:42 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 6so40266666uat.0 for ; Tue, 25 Oct 2016 18:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jny4cFmfTutZfZmH/7CH4bXH3lGsUtTRV3EnxzSpuNg=; b=HIFUKMt6jY6gz0d7BEPIE87/bQHxfTXgvxcWKh6mHyEfVZtFf/wHzXMB/IfV197Egn Fv9fhv0nCWAAHBXqanJLrcgDAy7YDyI0PlN3RKmHUdSMvIFeSQsHhPxzYjc3/hY8yK3U kws3fG7vxlUh+aIg3pe7V3P01bawt6LkWfpQB40uSdIMLN4yd84DXbCOQL5nV/NxbipH +o3Ybr/hEVOSz403VimlLV4PIwW1D0idoiPMzwiQ2YH7px0LvewyqNb1jUY3GvpqmQE2 KE/opA+y8sWTigOL4ga28sjY0Ev/rfVbtJX4nTqpPuj+UUBweNEGGR4H835P02RHeZss mTvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jny4cFmfTutZfZmH/7CH4bXH3lGsUtTRV3EnxzSpuNg=; b=CEQRylW3iqj044ACTD/bWThIXBDv/QHDQuT16wuLet/b3AlbIJ+lECrz/lrxfvpCZd IQetumjLasZAci8cr4bNi7GbjqoCckhH+e6qBcN7TopI9TFMNJ/T/cHZM/7y+fNKzVU2 klKZyMnU2HLOvUBgi3qH/LNcd6qOlhMhtKZWL8ZREn4oZlUlTvYsKznhW50fiC1xcs98 sm+xpQjDP+rR0sZOmth8eULUY+2RMbT86/fcmMUUrBn/4dnLEpFKIb4ZY6xx6xBcK6xA Rcc64fFHl7Ag8Ld1s1MYC/PPqvmjNyEHRIsaoddK+AgFgYYdmiJiVCmb/1r8x02sbfQJ LXDA== X-Gm-Message-State: ABUngvftObMJB/i/SPOZNYvC5knm9NgmeaU+laiBhngo2eOXU0fkdgNNeov9edn4gmvzuJsMf2Saka+yVV1rQ+sg X-Received: by 10.176.6.194 with SMTP id g60mr13084444uag.103.1477444721344; Tue, 25 Oct 2016 18:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Tue, 25 Oct 2016 18:18:40 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jana Iyengar Date: Tue, 25 Oct 2016 18:18:40 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c122e78cb1951053fba6736 Archived-At: Cc: marcelo bagnulo braun , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 01:18:44 -0000 --94eb2c122e78cb1951053fba6736 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 2:34 PM, Kyle Rose wrote: > On Tue, Oct 25, 2016 at 3:37 PM, Jana Iyengar wrote: > >> ECN signals indicate only congestion, not loss. My point was that >> congestion signals - explicit ones via ECN or implicit ones via loss/delay >> -- are all fed to the congestion controller. I agree that loss recovery is >> an entirely different matter, and that's a signal that comes out of the >> Loss Detection component. Make sense? >> > > Yep, I agree completely. I think maybe what I meant was more clearly > stated as "Applications may (will?) want to react differently to loss or > prospective loss from congestion, versus loss for other reasons (like poor > wifi signal)." We may currently have difficulty distinguishing the former > from the latter when ECN isn't a universal congestion signal, but having > the proper interface in place allowing applications to tailor behavior > based on improved future telemetry could be useful. > > >> If you're pointing out that congestion control and loss detection are >> separable, I agree. Perhaps this separation could be made explicit in the >> Loss Detection and Congestion Control doc? Or would you want to separate >> the two out? My earlier inclination was to keep fewer documents until they >> become large enough to need separation, but I can see arguments for >> document pluggability too. >> > > I agree with Spencer's point about document pluggability: it's less > important how many documents the WG produces than that they use > encapsulation to make it easy to swap out or replace components later > without having to individually update sentences from 17 different sections. > Sounds good to me. - jana > > Kyle > > --94eb2c122e78cb1951053fba6736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 25, 2016 at 2:34 PM, Kyle Rose <krose@krose.org> wrote= :
On Tu= e, Oct 25, 2016 at 3:37 PM, Jana Iyengar <jri@google.com> wrote= :
ECN signals indicate only c= ongestion, not loss. My point was that congestion signals - explicit ones v= ia ECN or implicit ones via loss/delay -- are all fed to the congestion con= troller. I agree that loss recovery is an entirely different matter, and th= at's a signal that comes out of the Loss Detection component. Make sens= e?

Yep, I agree co= mpletely. I think maybe what I meant was more clearly stated as "Appli= cations may (will?) want to react differently to loss or prospective loss f= rom congestion, versus loss for other reasons (like poor wifi signal)."= ; We may currently have difficulty distinguishing the former from the latte= r when ECN isn't a universal congestion signal, but having the proper i= nterface in place allowing applications to tailor behavior based on improve= d future telemetry could be useful.
=C2=A0
If you're pointing out that congestion con= trol and loss detection are separable, I agree. Perhaps this separation cou= ld be made explicit in the Loss Detection and Congestion Control doc? Or wo= uld you want to separate the two out? My earlier inclination was to keep fe= wer documents until they become large enough to need separation, but I can = see arguments for document pluggability too.

I agree with Spencer'= s point about document pluggability: it's less important how many docum= ents the WG produces than that they use encapsulation to make it easy to sw= ap out or replace components later without having to individually update se= ntences from 17 different sections.

=
Sounds good to me.

- jana
=C2= =A0

Kyle


--94eb2c122e78cb1951053fba6736-- From nobody Tue Oct 25 19:13:17 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6018E1297CE for ; Tue, 25 Oct 2016 19:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxCeTTfwryjb for ; Tue, 25 Oct 2016 19:13:14 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443EA129618 for ; Tue, 25 Oct 2016 19:13:13 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 205so7042158ybz.5 for ; Tue, 25 Oct 2016 19:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wmdMNqMEKpMNRERcgEnfCOGwIL+SRGTE/tEL64I6P5M=; b=ezIv2ZEZcQM8DE1IEsu/XXDZr+V8P/8ypzt2fPXWqdOAkw/YzCxM7dPNkLHUy11c4A uK1xxgSZgxQqbSlfQkWmcAI74mDv+x6Sgb9YZN7IbuFGm/pH/oc5WYJl5pDv3g8TG3tx QlwEf4fOFQhUfVCOUIBZYVjCc7FD3ZKP/o1RnUtpD7CC/i6kb+Z0NdoSZbuSXHqmSSO+ 62Hmx3bBvzYHX6S47Lep8HpUlmqCBc0Upw/DQlBe8LHHqAVgSpL5BE132i9kLTiHFce+ L0htNyQC9yLn6VGgu26HhtS9fD8TskhUD5grPg8sGTGuE4NKkSN2vYdUEw3QnL6iJMeV mI/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wmdMNqMEKpMNRERcgEnfCOGwIL+SRGTE/tEL64I6P5M=; b=PI/iByxwb415MBV42ikHXJkqmCHHEnooa6LO+Pr6W6Qip9ux1m3r7Y+e92jMn6fur2 vxILgEkjQk76H1g4UcpxG4yDhbz/xU1x3vXljeTU8pveNku70AR7xfiBKRfsN7VkzzMo eiZ7Y8aynjbkhX2aLGpMw0W43pLxrhwE/DpwqkpPrK9v+rGCdLdARNfblWw2epc6OaPF TGL8kPCYczy0DtS6kMZg6UfhQ07V4MW43fhq/+iaNNe4RtuPR8XDxqu7+TB8s9Dnp+Jb +Y82rUz0wJ/XMva8kACReYPB0LkSVSCqQb4YmLlFQfEqPS07T012JwWIa2uYZ5zEJN3P CIyw== X-Gm-Message-State: ABUngvepD7MhdZKwxMNCGMJLIqyfxubj7XPK8Iq/Mwarx+UuqbwgdtUwbby0zCFYhIeHOllOmX2F3bBWPRIOsg== X-Received: by 10.37.212.144 with SMTP id m138mr26010923ybf.129.1477447992246; Tue, 25 Oct 2016 19:13:12 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.51.137 with HTTP; Tue, 25 Oct 2016 19:13:11 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jim Roskind Date: Tue, 25 Oct 2016 19:13:11 -0700 X-Google-Sender-Auth: XKfDGfJgoCbSoqx14mIcYDYH-BA Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c07c916c086e0053fbb2a55 Archived-At: Cc: Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , marcelo bagnulo braun , Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 02:13:15 -0000 --94eb2c07c916c086e0053fbb2a55 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett wrote: > ... > It's worth noting that BBR is only a change to the congestion controller, > .... > > > BBR relies on getting estimates of transit time, so as to estimate variations in buffer sizes. As a relatively rough estimate, I believe BBR in TCP relies on traditional-TCP RTT calculations, which includes the round trip sum of transit times in both directions. I expect that better one-way transit time estimates can be harvested in QUIC, by changing the data included in ACK frames to better illuminate transit times in each directions (or more precisely, illuminate changes, from one packet to the next, in one-way transit times). Such modifications appear at first blush to be notably larger than just a change to the congestion controller. Similarly, I'd expect modifications to support ECN in QUIC to run much deeper than a congestion controller. Jim --94eb2c07c916c086e0053fbb2a55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 24, 2016 at 5:31 PM, Ian Swett <ianswett@google.com> wrote:
...
=
It's worth noting that BBR is only a change to the congestion cont= roller, ....



BBR relies on getting estimates of transit time, so as to e= stimate variations in buffer sizes.=C2=A0 As a relatively rough estimate, I= believe BBR in TCP relies on traditional-TCP RTT calculations, which inclu= des the round trip sum of transit times in both directions.=C2=A0 I expect = that better one-way transit time estimates can be harvested in QUIC, by cha= nging the data included in ACK frames to better illuminate transit times in= each directions (or more precisely, illuminate changes, from one packet to= the next, in one-way transit times).

Such modific= ations appear at first blush to be notably larger than just a change to the= congestion controller.

Similarly, I'd expect = modifications to support ECN in QUIC to run much deeper than a congestion c= ontroller.

Jim=C2=A0
--94eb2c07c916c086e0053fbb2a55-- From nobody Tue Oct 25 21:09:34 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D412945C for ; Tue, 25 Oct 2016 21:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0efRtGjYB3Bg for ; Tue, 25 Oct 2016 21:09:31 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A6D12945A for ; Tue, 25 Oct 2016 21:09:31 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id b80so200288380wme.1 for ; Tue, 25 Oct 2016 21:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eL6gdiAymnQibp3KJADEueMPbKkXsrkMHU1kMQ822pg=; b=lQYL4ASaf9mZ0/Bw33VZ4OBdtZKiiWETv3ESYyIoxDyXgZ4bwPgWVJPh+2DzxPoy7d sb8rNwhiQsk2mY+3wAGjT8OVn9BE+yaNndba2/TYVxwYMS+8OPu9HFyveKHpkURLx1XC o1BdIIF9lKMR/HHwAIkG0CUYsBAYqp9U/uB6Q0IPJIZC3HGT8JRsOelSiN6oqyk+4YZq 4xTVY4FWXueGNnFF2PXD91Wow0EK8c6dbVxY24ibV+dZkoZsCNnIz/i16rZqXv4yN6Wi 8D91Auz7mBZxH7yPwC0QJQ/zox6O9RUhXrIIia7l2LKYxtxCnoomzQHs0PBXRriRBCWa b6Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eL6gdiAymnQibp3KJADEueMPbKkXsrkMHU1kMQ822pg=; b=g568yoxedClIbH0UkByu7Cf6c2dMQuSu0jhyZ49f7mKcy97/8T+vhjuF9JpRtbQOFT 7eN5FBvYMPQeZKzvH0aKtSDcETjzevzfEV85rVBqwLtf9xz0IlaVw9qTu7+V2WLkgWCZ 0DGJwTKHUzWhxcu1+Xvprej5ViBZsWv65qqPeK7OmB5a4n5EwKSBBcL1yA9Ht1mtFgpB nh4r9+fOrRJsye/wwJt/9V3Hz8I++2pkj3t8dnJAUf9TqBt1EqzyNIsDX7cwxztwuJ1T gOEEfZZCbO1K77mNBvMMzVDDIuJGUUL5q+0MZmjnv9Yk65nUfIPPC+GS1payXtBmZMcN 2a2Q== X-Gm-Message-State: ABUngvcslOKivJNxSr2Ulr/YXpEPDIahHKgjWPATgGCx1YKZ8zRfLZiRmL9H/wq1ra7mWiNUs/JxgPhU12iSCD+9 X-Received: by 10.194.191.136 with SMTP id gy8mr88942wjc.117.1477454969530; Tue, 25 Oct 2016 21:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.199 with HTTP; Tue, 25 Oct 2016 21:09:28 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Ryan Hamilton Date: Tue, 25 Oct 2016 21:09:28 -0700 Message-ID: To: Jim Roskind Content-Type: multipart/alternative; boundary=047d7b873864a1c4b5053fbcca4d Archived-At: Cc: Ian Swett , Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , marcelo bagnulo braun , Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 04:09:33 -0000 --047d7b873864a1c4b5053fbcca4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind wrote: > On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett wrote: > >> ... >> It's worth noting that BBR is only a change to the congestion controller= , >> .... >> >> >> > BBR relies on getting estimates of transit time, so as to estimate > variations in buffer sizes. As a relatively rough estimate, I believe BB= R > in TCP relies on traditional-TCP RTT calculations, which includes the rou= nd > trip sum of transit times in both directions. I expect that better one-w= ay > transit time estimates can be harvested in QUIC, by changing the data > included in ACK frames to better illuminate transit times in each > directions (or more precisely, illuminate changes, from one packet to the > next, in one-way transit times). > =E2=80=8BCorrect me if I'm wrong, but QUIC ACK frames already have this information. The contain the arrival time of each packet at the peer, which provides the one-way transfer time. =E2=80=8B > Such modifications appear at first blush to be notably larger than just = a > change to the congestion controller. > > Similarly, I'd expect modifications to support ECN in QUIC to run much > deeper than a congestion controller. > > Jim > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --047d7b873864a1c4b5053fbcca4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind &l= t;JimRoskind@gmail.com> wrote:
= On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett <ianswett@go= ogle.com> wrote:
...
It's worth noting that BBR is only a change= to the congestion controller, ....
<= br>
=

BBR relies on = getting estimates of transit time, so as to estimate variations in buffer s= izes.=C2=A0 As a relatively rough estimate, I believe BBR in TCP relies on = traditional-TCP RTT calculations, which includes the round trip sum of tran= sit times in both directions.=C2=A0 I expect that better one-way transit ti= me estimates can be harvested in QUIC, by changing the data included in ACK= frames to better illuminate transit times in each directions (or more prec= isely, illuminate changes, from one packet to the next, in one-way transit = times).

=E2=80=8BCorrect me if I'm wrong, but QUIC ACK frames = already have this information. The contain the arrival time of each packet = at the peer, which provides the one-way transfer time.
=E2=80=8B
=C2=A0
=C2=A0Such modifications appear at first blush to be notably larger = than just a change to the congestion controller.

Similarly, I'd= expect modifications to support ECN in QUIC to run much deeper than a cong= estion controller.

Jim=C2=A0

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinf= o/quic


--047d7b873864a1c4b5053fbcca4d-- From nobody Tue Oct 25 23:57:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01312946E for ; Tue, 25 Oct 2016 23:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h445uaTUC4ni for ; Tue, 25 Oct 2016 23:57:52 -0700 (PDT) Received: from mx61.netapp.com (mx61.netapp.com [216.240.31.181]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAAA1293F8 for ; Tue, 25 Oct 2016 23:57:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,549,1473145200"; d="scan'208";a="6406789" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx61-out.netapp.com with ESMTP; 25 Oct 2016 23:49:25 -0700 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Oct 2016 23:56:45 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 25 Oct 2016 23:56:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gQlCIUHVNS/zXCsOZGeP08uio1x4Lsd+F02qWldLhwo=; b=bIMYT5AEjA9znOtGU8hg/e+AQotFUNJ2e7dIRFa1u9irXdzwrY2HUAW0InPMl9Oq3oILgb1sYWzCBoFZcQjOykTgcZLPSV/+tsTJwBhECW3iAnYBBaujxf2YXaHaGkayY3Be0lZQRC7U99qIf2z9AidApzKfPCepejhRI7+qZqc= Received: from BY1PR0601MB1158.namprd06.prod.outlook.com (10.160.196.21) by BY1PR0601MB1157.namprd06.prod.outlook.com (10.160.196.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Wed, 26 Oct 2016 06:56:45 +0000 Received: from BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) by BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) with mapi id 15.01.0679.015; Wed, 26 Oct 2016 06:56:45 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: IETF-97 agenda planning Thread-Index: AQHSL1YdS4wzU7VlpEachx0IL7Acvw== Date: Wed, 26 Oct 2016 06:56:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:311d:eb01:99c:4547:1344:4196] x-ms-office365-filtering-correlation-id: a12837d3-95f6-466b-eeca-08d3fd6d4013 x-microsoft-exchange-diagnostics: 1; BY1PR0601MB1157; 7:YSOoV1bx1ooEpjNWeuoSnf2DTkUOW2/2/ItJ8meK1giza8AGp4H7UZ9CeLNCaXh/H4bXieioVLjOU+Y8M8tiMt+HbLqtnXRLCjaVV2bmt98a9j1mNc+zJ6FOLMKqUXVesYu8dWCE5emB44ny9+hZJ1KTP+jDsDEAdGVa6ZJjbG9Q5AKf4N8MjC11OKEVCzbSsW4EoHKDu/QOBVckKq8k2N/c80mXKqPX8AVjDqujWvjHDtAftX8vF2Aa/iWpxzkNM40qei3Mthjxy+jRKFJI67NE6R2sZ24bX2pX5tDUHRBs98X7B8t6esWJU3ddW2VmbT3ZlhVot0DvMPvLRIb6sjXXyUrxfzR0KZvVEVUdwBM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0601MB1157; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:BY1PR0601MB1157; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0601MB1157; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(199003)(105586002)(106116001)(99286002)(106356001)(189998001)(87936001)(102836003)(586003)(2906002)(33656002)(2351001)(229853001)(6916009)(5660300001)(101416001)(2501003)(19580395003)(110136003)(50986999)(6116002)(92566002)(36756003)(5002640100001)(57306001)(83716003)(19580405001)(8676002)(97736004)(3280700002)(8936002)(68736007)(15975445007)(77096005)(11100500001)(7736002)(122556002)(7846002)(10400500002)(450100001)(305945005)(50226002)(81166006)(107886002)(2900100001)(3660700001)(1730700003)(5640700001)(81156014)(82746002)(86362001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0601MB1157; H:BY1PR0601MB1158.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <99BF76982FADA94191E6DA6CA188390B@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2016 06:56:45.6571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0601MB1157 X-OriginatorOrg: netapp.com Archived-At: Subject: [QUIC] IETF-97 agenda planning X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 06:57:53 -0000 Hi, we are TENTATIVELY scheduled for Tuesday, November 15, 2016 in the 9:30-12:= 00 "Tuesday Morning session I" slot. =20 Our current agenda is evolving on https://github.com/quicwg/wg-materials/bl= ob/master/ietf97/agenda.md. If you would like to present during the session, please send an email to qu= ic-chairs@ietf.org, include a few sentences outlining your talk and give us= an estimate for how much presentation + discussion time you think is neede= d. Lars PS: ID authors, please note the upcoming ID submission deadline: 2016-07-08= (Friday): Internet Draft submission cut-off (for all drafts, including -00= ) by UTC 23:59, upload using IETF ID Submission Tool.= From nobody Wed Oct 26 00:43:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D951C129A26 for ; Wed, 26 Oct 2016 00:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tBX5Myrr9nt for ; Wed, 26 Oct 2016 00:43:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F212129412 for ; Wed, 26 Oct 2016 00:43:37 -0700 (PDT) Received: from [192.168.3.101] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B0C9E22E25C; Wed, 26 Oct 2016 03:43:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) X-Apple-Base-Url: x-msg://16/ X-Universally-Unique-Identifier: 15643DEE-D110-43AE-A7FE-18C317920C44 X-Apple-Mail-Remote-Attachments: NO X-Apple-Mail-Plain-Text-Draft: yes From: Mark Nottingham X-Mailer: iPhone Mail (14B72) X-Apple-Windows-Friendly: 1 Date: Wed, 26 Oct 2016 18:43:15 +1100 Content-Transfer-Encoding: quoted-printable X-Apple-Mail-Signature: 5286B7EE-6EBB-4066-8C47-3951E4B6F28F Message-Id: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> X-Uniform-Type-Identifier: com.apple.mail-draft To: quic@ietf.org Archived-At: Cc: Lars Eggert Subject: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 07:43:40 -0000 Everyone, We'd like to get our first interim meeting nailed down soon. We have a host w= ith with what we believe to be a suitable space in Tokyo, Japan on 24-26 Jan= uary. To make sure that it's suitable for a good portion of the WG, as well as to a= ssist planning, please fill out this poll to indicate your availability: http://doodle.com/poll/ams8q39eecud4zih In particular, if you'd like to actively participate but the cannot make tho= se dates, please indicate that with "Cannot make it." We'll have more details soon. Cheers, -- Mark Nottingham https://www.mnot.net/ Sent from my iPhone= From nobody Wed Oct 26 03:17:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E7129A6D for ; Wed, 26 Oct 2016 03:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEQY1AvbahMO for ; Wed, 26 Oct 2016 03:17:22 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297B3129A5C for ; Wed, 26 Oct 2016 03:17:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,550,1473145200"; d="scan'208";a="151859926" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 26 Oct 2016 03:12:10 -0700 Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 03:12:17 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 26 Oct 2016 03:12:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y+t7uCNSEtXdlZEfADq4wJhx8VZx4Q5+NefaeXuskLA=; b=nzp7rY7WS3RYEso7pJY1zGgEcvmnlrwKSCYWAPHn8pyOitg+Gv6z0HdbRN6z2DwNcIKQtSQwkVgkUyEdPO3bhmucGtvyj9lMgc11JdXqb21nV3B3whRzQuV3yiBIaU1Mz4NvHQeQgp+vO4X2sdxYHdHqMvofyzB4XI5MBFib3sk= Received: from BY1PR0601MB1158.namprd06.prod.outlook.com (10.160.196.21) by BY1PR0601MB1160.namprd06.prod.outlook.com (10.160.196.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Wed, 26 Oct 2016 10:12:16 +0000 Received: from BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) by BY1PR0601MB1158.namprd06.prod.outlook.com ([10.160.196.21]) with mapi id 15.01.0679.015; Wed, 26 Oct 2016 10:12:16 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: [QUIC] IETF-97 agenda planning Thread-Index: AQHSL1YdvpyKL/ttVkit4iWauChkWKC6hC2A Date: Wed, 26 Oct 2016 10:12:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:311d:eb01:50c1:f351:f54d:99eb] x-ms-office365-filtering-correlation-id: 6eb7aab6-fb64-4873-26dd-08d3fd889054 x-microsoft-exchange-diagnostics: 1; BY1PR0601MB1160; 7:pqPlxgY/8pFsDHl5iLr0/Jbd4HclkaO8op1LO3X87BgkcTjVe0o0NdFQ4+8KfHRnx5LUyL2lLOykCBCl5uqwfc5lhJ9BRqxTt6QfypmZtfNkY5BAK9zePmxT8E3s3MSi3+pQBOA8Ej3qFYIiVX0n82YONo29kiZVgmKNTPuz0JBfETWJxDMIodq6TZ5K9p/ZlOe8pkGE+ZW8x5dovhauXjywhYld6xJAxSFOcl3E8L3ixjW+l+UO43ux6CpmOff901GNex2JR5ixaq+o2HVYkFY99aZGhdKxRIR1pW4soUOVKAaV3VdLAIEbyCa/e1o3h+movI2UN98slF06F7pA1Tuchp36b5gbzFPbtURTc8s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0601MB1160; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:BY1PR0601MB1160; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0601MB1160; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(199003)(24454002)(189002)(86362001)(76176999)(19580395003)(19580405001)(4001150100001)(99286002)(305945005)(2351001)(11100500001)(50986999)(106116001)(106356001)(50226002)(10400500002)(33656002)(105586002)(7846002)(83716003)(5002640100001)(122556002)(87936001)(92566002)(7736002)(2501003)(6916009)(6116002)(2950100002)(57306001)(97736004)(110136003)(586003)(2906002)(102836003)(68736007)(3280700002)(5640700001)(36756003)(2900100001)(5660300001)(189998001)(82746002)(450100001)(81156014)(1730700003)(77096005)(3660700001)(81166006)(101416001)(8676002)(107886002)(8936002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0601MB1160; H:BY1PR0601MB1158.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <173BA0AED27F384CBF44E422AF503440@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2016 10:12:16.6534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0601MB1160 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [QUIC] IETF-97 agenda planning X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 10:17:24 -0000 On 2016-10-26, at 8:56, Eggert, Lars wrote: > PS: ID authors, please note the upcoming ID submission deadline: 2016-07-= 08 (Friday): Internet Draft submission cut-off (for all drafts, including -= 00) by UTC 23:59, upload using IETF ID Submission Tool. Eagle-eyed participants (or some that can actually read, rather than appare= ntly your co-chair) have spotted that the date above is wrong and should be= : 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, i= ncluding -00) by UTC 23:59, upload using IETF ID Submission Tool. Sorry, Lars= From nobody Wed Oct 26 04:07:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD6F129A85 for ; Wed, 26 Oct 2016 04:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aPL1rYRJGkb for ; Wed, 26 Oct 2016 04:07:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF3C129A7B for ; Wed, 26 Oct 2016 04:07:10 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-b9-58108e5c2fa9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 62.15.31035.C5E80185; Wed, 26 Oct 2016 13:07:08 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 26 Oct 2016 13:07:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkHK2J5+5DrLT6oNho2YQCpsMfym0ZSzEIEwH1IbETs=; b=mNifoMXasfNUq+zezFtfWSWXJa32sLL9mUOCDg/FCeRMQrFpmCiIxi6I0Nt0/iPAVW86TO++5LX3bUdkddqipB8mONEyavBvNxVTYbOSXCillujpA7pOvE+NWEQi9fm0sgZIa0YDmFeMoP4UauPP9Z1yro2cN7xivaeXQvN7z1I= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB349.eurprd07.prod.outlook.com (10.141.12.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Wed, 26 Oct 2016 11:06:59 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) by DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) with mapi id 15.01.0649.027; Wed, 26 Oct 2016 11:06:59 +0000 From: Ingemar Johansson S To: Ryan Hamilton , Jim Roskind Thread-Topic: QUIC ACK frames and one-way transfer time (was RE: [QUIC] Drafts structure and split) Thread-Index: AdIveFEogtlDgWK4THqaxk5+qo7AYg== Date: Wed, 26 Oct 2016 11:06:59 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-microsoft-exchange-diagnostics: 1; DBXPR07MB349; 6:g36fdUgb3g1bGvGLxdcgD0tDBJEnpJxY+5ReDl7BDjvAbKEK4NXIaPQEwtfrEoIUQEWvbzEAKJwQPwRJ7TWJu3Q4OK9wAt5WYQ86mCGFb0pla9CD35sGQaMISR/VrNGwt9bZGc6bZ794g+9yewurm2kJP9FrBvNW+snuaeMcj/bFvfzxPB3UYz1jFtT65c8U5ZT5QedKyyntrRRpt88MA24MhL29HscbkFDZuW8Tmwoce5c2ubcfrMNqhdG80Fxn9sRhx8Jb7lbJxQk38smqICFY5ApudKt1Ow2Ty95UMrkUblbRXI+fKSv3IPg08l2O; 5:BOR7QrRqCpUyEeQBdPlBEm4LSLWq/n+jnA8vTjJYumTXo/UxfQXFLPmE5N4v7aAUElXHuBw1e1PWQ+2xQ6tl8i60b1OOiyvfmVj98gw3h9lt2H9klyu8EmV9TgMdC3DVtYxSQHa6jZbCkQ2cPdDLRjKZFRPDqJu/1vvCQu3NwDw=; 24:qMlLFYXHn19k6B5fuCnWulDzqDAf+oL8AVjvQ4HNaROC0UCj7imgLPkb4jjhemNMXVCZWB9BiVfuMWc6zO+eTFRiV1k10fqNx/XF+HDk2eY=; 7:fadHe4nBWE5yK/Zd+LC8fl+gfSHso998kocJobAGjwL4YKUXL1RNsW4lbZQByOB0oxSs+jh4Ve5TSxCUyiwDudU2unwntJSNtplcxe/2RT9RhAKabOxiqKqy0cOhFOjXIWhXNvAfCe8F2+N4ktJ4tnKEtkZ1jxUoof3vXMYktRw7ABlTf4M4rESboqO+kaqeq5mW2zN54TqoiHi0tEcvIJJ2fjPxg5+V1vCD/f3tczyLweRWuhOvYo2u/Dn4WMB6dBlF258F1uQEF2ysPD7EFjqogGnEm3HupM8+vg7hpIGZzaRP5PRR9qBro+eM+xEA04QzGDLkyLyZTOhRmf2fRskPrRojfcCmMNOHapNnyUU= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(199003)(377454003)(24454002)(189002)(3846002)(5002640100001)(3280700002)(790700001)(217423001)(102836003)(81166006)(8676002)(4326007)(19300405004)(74316002)(586003)(50986999)(54356999)(3660700001)(66066001)(16236675004)(33656002)(7736002)(10400500002)(5001770100001)(81156014)(229853001)(101416001)(7906003)(6116002)(2906002)(19625215002)(7846002)(87936001)(97736004)(106356001)(105586002)(5660300001)(92566002)(19609705001)(19617315012)(77096005)(76576001)(8936002)(189998001)(11100500001)(7696004)(9686002)(15975445007)(9326002)(2900100001)(68736007)(19580405001)(19580395003)(122556002)(86362001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB349; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 2c1df358-6f54-45df-8c00-08d3fd9034fb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB349; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB349; x-forefront-prvs: 0107098B6C received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB35198069351E83CC0BE9014C2AB0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2016 11:06:59.3671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB349 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3cuO1qrt6X0YAY1sBtoFyMO0VIza9GFqKihRlt10JWXOEdD K6MsP7QyzCR1S9xkmnZhJV3UUptkpQZmaqE2R7SkxBXm3Ujadgz89nue/3P7v7wMIe+lAhhd UgrHJ2kTFLQvWah+tjz48HWsXtNCszcvGqXsRG81xZYN3afZ3EYzyVq/59Js1re7NHvNNJst Hswm2bK8F0S4j6raYJeqTJWpqu6CZlJlsUxIVKOfHlEqfduYZC8d7bvpOJegO83xqzdrfOM/ /qqXnnqYljZSd4+6gHJS9ciHAbwe9FO1Ej3yZeTYiqDvbyMpBm8RXJ20exUSZxMwYW6nROWm BKzlNbQYvEJgLDATnmE03gQVDWPIw354G7RU9HiLCHxLAqX6dtojLMAayMv/QItFHOQ4O6c5 BEy9NygPkzgIhvWtXpbhaCh59Nq7AOHF4BjrJT1M4IXQ7SyWiC4wWF60EiL7w4+vU5RYfwx+ d2VTYn4JvCl3eQ8CfImBycmXpBhU0mAz57snMe5gN3RVRooNUeAa6pOKrIPu8Z7pBbHQ3/hU IvY+RVA63jl9RSDUudq82+RuZ3ceZCHRcQDYO65McyB8/1xLiQ6SwTLsonLQcsMMQ4YZksH7 APOhqdBJGtznEXglWGtWiyVLIe/qF6nIKyDrdpF0Zt6EpHeRv8AJRxPj1oWGcLzumCAkJ4Uk cSmVyP3rbI//BFWh9oGIBoQZpJgjMxXNU8sp7WkhPbEBAUMo/GRl17BaLjuuTT/D8clH+NQE TmhAixhSsVC2ocJxSI7jtCncSY47xfH/VQnjE3ABHXj3PMLYF7TiXPgy/+EIZfnX+uas6q2y XbGhDrtj1HDZNnLOsnPPjrDtd3hn2kY+WAhIb60/en7AaNvXoiIzYzLih57YdYqHjmpNzPOw LZl4P4zOyujQJJzdXKJ88s3vZ+xB12DUvPy5kVXvS82anYk1auWJH8ovf+w7psLb+psUpBCv XbuK4AXtP8hN56JxAwAA Archived-At: Cc: Ian Swett , Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , marcelo bagnulo braun , Jana Iyengar , "quic@ietf.org" Subject: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 11:07:16 -0000 --_000_DBXPR07MB35198069351E83CC0BE9014C2AB0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KUnlhbi4gWW91IGFyZSByaWdodCB0aGF0IHRoZSBRVUlDIEFDSyBmcmFtZXMgYWxyZWFk eSBjb250YWlucyB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIHRvIGNvbXB1dGUgdGhlIG9uZSB3 YXkgZGVsYXkuIEl0IGlzIG9mIGNvdXJzZSBub3QgcG9zc2libGUgdG8gZGVkdWNlIHRoZSB0cnVl IG9uZSB3YXkgZGVsYXkgdW5sZXNzIHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIGNsb2NrcyBhcmUg c3luY2hyb25pemVkLiBXaGF0IGlzIGVhc3kgdG8gZGV0ZXJtaW5lIGlzIHRoZSBxdWV1ZSBkZWxh eSB0aGF0IGNhbiBiZSB1c2VkIGluIGEgd2F5IHNpbWlsYXIgdG8gaG93IExFREJBVCBkb2VzIGl0 LCB0aGVyZSBhcmUgc29tZSBwcm9zIGFuZCBjb25zIHdpdGggdGhhdCBhcHByb2FjaC4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWcv IGRlc2NyaWJlcyBhIG1vZGlmaWNhdGlvbiB0byBDdWJpYyB0aGF0IGlzIGJhc2VkIG9uIHRoaXMg cHJpbmNpcGxlLg0KDQovSW5nZW1hcg0KDQoNCkZyb206IFJ5YW4gSGFtaWx0b24gW21haWx0bzpy Y2hAZ29vZ2xlLmNvbV0NClNlbnQ6IGRlbiAyNiBva3RvYmVyIDIwMTYgMDY6MDkNClRvOiBKaW0g Um9za2luZCA8SmltUm9za2luZEBnbWFpbC5jb20+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBn b29nbGUuY29tPjsgS3lsZSBSb3NlIDxrcm9zZUBrcm9zZS5vcmc+OyBDaHJpc3RpYW4gSHVpdGVt YSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbT47IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0Bp dC51YzNtLmVzPjsgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IHF1aWNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbUVVJQ10gRHJhZnRzIHN0cnVjdHVyZSBhbmQgc3BsaXQNCg0KDQoNCk9u IFR1ZSwgT2N0IDI1LCAyMDE2IGF0IDc6MTMgUE0sIEppbSBSb3NraW5kIDxKaW1Sb3NraW5kQGdt YWlsLmNvbTxtYWlsdG86SmltUm9za2luZEBnbWFpbC5jb20+PiB3cm90ZToNCk9uIE1vbiwgT2N0 IDI0LCAyMDE2IGF0IDU6MzEgUE0sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KLi4uDQpJdCdzIHdvcnRoIG5vdGluZyB0 aGF0IEJCUiBpcyBvbmx5IGEgY2hhbmdlIHRvIHRoZSBjb25nZXN0aW9uIGNvbnRyb2xsZXIsIC4u Li4NCg0KDQoNCkJCUiByZWxpZXMgb24gZ2V0dGluZyBlc3RpbWF0ZXMgb2YgdHJhbnNpdCB0aW1l LCBzbyBhcyB0byBlc3RpbWF0ZSB2YXJpYXRpb25zIGluIGJ1ZmZlciBzaXplcy4gIEFzIGEgcmVs YXRpdmVseSByb3VnaCBlc3RpbWF0ZSwgSSBiZWxpZXZlIEJCUiBpbiBUQ1AgcmVsaWVzIG9uIHRy YWRpdGlvbmFsLVRDUCBSVFQgY2FsY3VsYXRpb25zLCB3aGljaCBpbmNsdWRlcyB0aGUgcm91bmQg dHJpcCBzdW0gb2YgdHJhbnNpdCB0aW1lcyBpbiBib3RoIGRpcmVjdGlvbnMuICBJIGV4cGVjdCB0 aGF0IGJldHRlciBvbmUtd2F5IHRyYW5zaXQgdGltZSBlc3RpbWF0ZXMgY2FuIGJlIGhhcnZlc3Rl ZCBpbiBRVUlDLCBieSBjaGFuZ2luZyB0aGUgZGF0YSBpbmNsdWRlZCBpbiBBQ0sgZnJhbWVzIHRv IGJldHRlciBpbGx1bWluYXRlIHRyYW5zaXQgdGltZXMgaW4gZWFjaCBkaXJlY3Rpb25zIChvciBt b3JlIHByZWNpc2VseSwgaWxsdW1pbmF0ZSBjaGFuZ2VzLCBmcm9tIG9uZSBwYWNrZXQgdG8gdGhl IG5leHQsIGluIG9uZS13YXkgdHJhbnNpdCB0aW1lcykuDQoNCuKAi0NvcnJlY3QgbWUgaWYgSSdt IHdyb25nLCBidXQgUVVJQyBBQ0sgZnJhbWVzIGFscmVhZHkgaGF2ZSB0aGlzIGluZm9ybWF0aW9u LiBUaGUgY29udGFpbiB0aGUgYXJyaXZhbCB0aW1lIG9mIGVhY2ggcGFja2V0IGF0IHRoZSBwZWVy LCB3aGljaCBwcm92aWRlcyB0aGUgb25lLXdheSB0cmFuc2ZlciB0aW1lLg0K4oCLDQoNCiBTdWNo IG1vZGlmaWNhdGlvbnMgYXBwZWFyIGF0IGZpcnN0IGJsdXNoIHRvIGJlIG5vdGFibHkgbGFyZ2Vy IHRoYW4ganVzdCBhIGNoYW5nZSB0byB0aGUgY29uZ2VzdGlvbiBjb250cm9sbGVyLg0KDQpTaW1p bGFybHksIEknZCBleHBlY3QgbW9kaWZpY2F0aW9ucyB0byBzdXBwb3J0IEVDTiBpbiBRVUlDIHRv IHJ1biBtdWNoIGRlZXBlciB0aGFuIGEgY29uZ2VzdGlvbiBjb250cm9sbGVyLg0KDQpKaW0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFp bGluZyBsaXN0DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQoNCg== --_000_DBXPR07MB35198069351E83CC0BE9014C2AB0DBXPR07MB351eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Unlhbi4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PllvdSBhcmUgcmlnaHQgdGhhdCB0aGUgUVVJQyBBQ0sgZnJhbWVzIGFscmVhZHkgY29udGFpbnMg dGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiB0byBjb21wdXRlIHRoZSBvbmUgd2F5IGRlbGF5LiBJ dCBpcyBvZiBjb3Vyc2Ugbm90IHBvc3NpYmxlIHRvIGRlZHVjZSB0aGUgdHJ1ZSBvbmUgd2F5IGRl bGF5IHVubGVzcyB0aGUgc2VuZGVyDQogYW5kIHJlY2VpdmVyIGNsb2NrcyBhcmUgc3luY2hyb25p emVkLiBXaGF0IGlzIGVhc3kgdG8gZGV0ZXJtaW5lIGlzIHRoZSBxdWV1ZSBkZWxheSB0aGF0IGNh biBiZSB1c2VkIGluIGEgd2F5IHNpbWlsYXIgdG8gaG93IExFREJBVCBkb2VzIGl0LCB0aGVyZSBh cmUgc29tZSBwcm9zIGFuZCBjb25zIHdpdGggdGhhdCBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGct NWcvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2hhbnNzb24tY2Mt Zm9yLTRnLTVnLzwvYT4gZGVzY3JpYmVzIGEgbW9kaWZpY2F0aW9uIHRvIEN1YmljDQogdGhhdCBp cyBiYXNlZCBvbiB0aGlzIHByaW5jaXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFJ5YW4gSGFtaWx0b24gW21haWx0bzpyY2hAZ29vZ2xlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjYgb2t0b2JlciAyMDE2IDA2OjA5PGJyPg0KPGI+ VG86PC9iPiBKaW0gUm9za2luZCAmbHQ7SmltUm9za2luZEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdv b2dsZS5jb20mZ3Q7OyBLeWxlIFJvc2UgJmx0O2tyb3NlQGtyb3NlLm9yZyZndDs7IENocmlzdGlh biBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgU3BlbmNlciBEYXdraW5zIGF0 IElFVEYgJmx0O3NwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tJmd0OzsgbWFyY2VsbyBiYWdu dWxvDQogYnJhdW4gJmx0O21hcmNlbG9AaXQudWMzbS5lcyZndDs7IEphbmEgSXllbmdhciAmbHQ7 anJpQGdvb2dsZS5jb20mZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUVVJQ10gRHJhZnRzIHN0cnVjdHVyZSBhbmQgc3BsaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBP Y3QgMjUsIDIwMTYgYXQgNzoxMyBQTSwgSmltIFJvc2tpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpK aW1Sb3NraW5kQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkppbVJvc2tpbmRAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMjQsIDIwMTYgYXQgNToz MSBQTSwgSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQncyB3b3J0aCBub3RpbmcgdGhhdCBCQlIgaXMgb25seSBhIGNoYW5nZSB0byB0aGUgY29uZ2Vz dGlvbiBjb250cm9sbGVyLCAuLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJCUiByZWxpZXMgb24gZ2V0dGluZyBlc3RpbWF0ZXMgb2YgdHJh bnNpdCB0aW1lLCBzbyBhcyB0byBlc3RpbWF0ZSB2YXJpYXRpb25zIGluIGJ1ZmZlciBzaXplcy4m bmJzcDsgQXMgYSByZWxhdGl2ZWx5IHJvdWdoIGVzdGltYXRlLCBJIGJlbGlldmUgQkJSIGluIFRD UCByZWxpZXMgb24gdHJhZGl0aW9uYWwtVENQIFJUVCBjYWxjdWxhdGlvbnMsIHdoaWNoIGluY2x1 ZGVzIHRoZSByb3VuZCB0cmlwIHN1bSBvZiB0cmFuc2l0DQogdGltZXMgaW4gYm90aCBkaXJlY3Rp b25zLiZuYnNwOyBJIGV4cGVjdCB0aGF0IGJldHRlciBvbmUtd2F5IHRyYW5zaXQgdGltZSBlc3Rp bWF0ZXMgY2FuIGJlIGhhcnZlc3RlZCBpbiBRVUlDLCBieSBjaGFuZ2luZyB0aGUgZGF0YSBpbmNs dWRlZCBpbiBBQ0sgZnJhbWVzIHRvIGJldHRlciBpbGx1bWluYXRlIHRyYW5zaXQgdGltZXMgaW4g ZWFjaCBkaXJlY3Rpb25zIChvciBtb3JlIHByZWNpc2VseSwgaWxsdW1pbmF0ZSBjaGFuZ2VzLCBm cm9tIG9uZSBwYWNrZXQNCiB0byB0aGUgbmV4dCwgaW4gb25lLXdheSB0cmFuc2l0IHRpbWVzKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igIs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5D b3JyZWN0IG1lIGlmIEknbSB3cm9uZywgYnV0IFFVSUMgQUNLIGZyYW1lcyBhbHJlYWR5IGhhdmUg dGhpcyBpbmZvcm1hdGlvbi4gVGhlIGNvbnRhaW4gdGhlIGFycml2YWwgdGltZSBvZiBlYWNoIHBh Y2tldCBhdCB0aGUgcGVlciwNCiB3aGljaCBwcm92aWRlcyB0aGUgb25lLXdheSB0cmFuc2ZlciB0 aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj7igIs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwO1N1Y2ggbW9kaWZpY2F0aW9ucyBhcHBlYXIgYXQgZmlyc3QgYmx1c2gg dG8gYmUgbm90YWJseSBsYXJnZXIgdGhhbiBqdXN0IGEgY2hhbmdlIHRvIHRoZSBjb25nZXN0aW9u IGNvbnRyb2xsZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1pbGFybHksIEknZCBleHBlY3QgbW9kaWZpY2F0 aW9ucyB0byBzdXBwb3J0IEVDTiBpbiBRVUlDIHRvIHJ1biBtdWNoIGRlZXBlciB0aGFuIGEgY29u Z2VzdGlvbiBjb250cm9sbGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5KaW0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpRVUlDIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpRVUlDQGlldGYub3JnIj5RVUlDQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYzwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DBXPR07MB35198069351E83CC0BE9014C2AB0DBXPR07MB351eurprd_-- From nobody Wed Oct 26 06:47:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24182129498 for ; Wed, 26 Oct 2016 06:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M94Jxn8-H6LZ for ; Wed, 26 Oct 2016 06:46:54 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B755612967A for ; Wed, 26 Oct 2016 06:46:53 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id 140so20183998wmv.0 for ; Wed, 26 Oct 2016 06:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pmhgxFeRlJc3mb/GQDVpIVezlxl2jDzCqhAno+zSy34=; b=HEWmfu1l/w/+u8Z4a+K9qzbFnH27B4H4hCkowGpB/is/H6uxOqk1jDrJdYjBPrIts4 nfM9x4FoQjHG0ZYo7jjHkjjV5DnsV/QJx/8s+iaHJqEJBbKFVXfXF26P7xfgP3rzcGzR 4rPzqygVeeB13Dcw4EgT9Tx6RLtFqwiIm4O5MdzlEi0kGhGkNxhEB7vAy2Bl9lO3g9WF gXoUR6eOnYIcS5GNYsnk2zq+FelaUuf7hhyKko2gTqXg60wH8CqLtbBOq3LYygIYRBvM V7fF7mDASs+Lwn7QYfhY6AvsDptgu3fjBnfFtRRfBm1G3pboBQ22pcq5GnvNUrS6RCNw 9aGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pmhgxFeRlJc3mb/GQDVpIVezlxl2jDzCqhAno+zSy34=; b=Js2QxNxC0GL7OUPb+EoHeqDHiPqJp3yBDApuW4NVbJD+ExaYja0c3egVAHXLKUjVxs 34lGlr4IdhYlkIRZjXu1LBohmPgacs2spMVE5+ahU5+HIk8MYgtlOPKEdpGUQ8Zc6Grv k3o7VzJzvSgPErVDFNhnFxR+7THY/x1oxkPe/Pqu47QDW7b1py2Bpk88WbfaChYEc8bn i484uzXIE0JwSbRLdvbcPhxhoxpuf3w9YP7d/ujPFWaCahgCc7bCkn8A22k1yLzlxip4 PeJ3YQ+WfBG0EJ3itkvrNJrdtZsZbBGuz4fpT74eNl1R4okn0YQYm6UUzAhSgQ774YOZ Zo+g== X-Gm-Message-State: ABUngvegO60CgZUC2JT7gUiQD3i7el+e0F2vWy85sDamB0MvO2gGd0cKHSOJ21+C0CoWV0vYUOHIFlcKErHWaOyX X-Received: by 10.194.189.198 with SMTP id gk6mr2322999wjc.167.1477489612064; Wed, 26 Oct 2016 06:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.199 with HTTP; Wed, 26 Oct 2016 06:46:51 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Wed, 26 Oct 2016 06:46:51 -0700 Message-ID: To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=047d7bb70e2e7cc845053fc4db16 Archived-At: Cc: Ian Swett , Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , Jana Iyengar , marcelo bagnulo braun , Jim Roskind , "quic@ietf.org" Subject: Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 13:46:58 -0000 --047d7bb70e2e7cc845053fc4db16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, clock synchronization is an issue, but QUIC makes an attempt to deal with it. The receipt "time" in the ACK frame is not an actual wall time, but is instead a time delta since the connection is established. Assuming that the clocks are moving forward at roughly the same rate, this means that the relative skew in these deltas is the time it took for the CHLO to reach the server, and the peers can account for this in subsequent calculations. On Wed, Oct 26, 2016 at 4:06 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > Ryan. You are right that the QUIC ACK frames already contains the > necessary information to compute the one way delay. It is of course not > possible to deduce the true one way delay unless the sender and receiver > clocks are synchronized. What is easy to determine is the queue delay tha= t > can be used in a way similar to how LEDBAT does it, there are some pros a= nd > cons with that approach. > > https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/ describes > a modification to Cubic that is based on this principle. > > > > /Ingemar > > > > > > *From:* Ryan Hamilton [mailto:rch@google.com] > *Sent:* den 26 oktober 2016 06:09 > *To:* Jim Roskind > *Cc:* Ian Swett ; Kyle Rose ; > Christian Huitema ; Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com>; marcelo bagnulo braun ; > Jana Iyengar ; quic@ietf.org > *Subject:* Re: [QUIC] Drafts structure and split > > > > > > > > On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind wrote= : > > On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett wrote: > > ... > > It's worth noting that BBR is only a change to the congestion controller, > .... > > > > > > > > BBR relies on getting estimates of transit time, so as to estimate > variations in buffer sizes. As a relatively rough estimate, I believe BB= R > in TCP relies on traditional-TCP RTT calculations, which includes the rou= nd > trip sum of transit times in both directions. I expect that better one-w= ay > transit time estimates can be harvested in QUIC, by changing the data > included in ACK frames to better illuminate transit times in each > directions (or more precisely, illuminate changes, from one packet to the > next, in one-way transit times). > > > > =E2=80=8BCorrect me if I'm wrong, but QUIC ACK frames already have this > information. The contain the arrival time of each packet at the peer, whi= ch > provides the one-way transfer time. > > =E2=80=8B > > > > Such modifications appear at first blush to be notably larger than just = a > change to the congestion controller. > > > > Similarly, I'd expect modifications to support ECN in QUIC to run much > deeper than a congestion controller. > > > > Jim > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --047d7bb70e2e7cc845053fc4db16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, clock synchronization is an issue, but QUIC makes an = attempt to deal with it. The receipt "time" in the ACK frame is n= ot an actual wall time, but is instead a time delta since the connection is= established. Assuming that the clocks are moving forward at roughly the sa= me rate, this means that the relative skew in these deltas is the time it t= ook for the CHLO to reach the server, and the peers can account for this in= subsequent calculations.

<= br>
On Wed, Oct 26, 2016 at 4:06 AM, Ingemar Joha= nsson S <ingemar.s.johansson@ericsson.com> wr= ote:

Hi

=C2=A0

Ryan. You are right that the QUIC ACK frames already contains the necessa= ry information to compute the one way delay. It is of course not possible t= o deduce the true one way delay unless the sender and receiver clocks are synchronized. What is easy to determine is the que= ue delay that can be used in a way similar to how LEDBAT does it, there are= some pros and cons with that approach.

https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/ describes a modification to Cub= ic that is based on this principle.

=C2=A0

/Ingemar

=C2=A0

=C2=A0

From: Ryan H= amilton [mailto:rch@goo= gle.com]
Sent: den 26 oktober 2016 06:09
To: Jim Roskind <JimRoskind@gmail.com>
Cc: Ian Swett <ianswett@google.com>; Kyle Rose <krose@krose.org>; Christian Huit= ema <huitema@hu= itema.net>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; marcelo bagnulo braun <marcelo@= it.uc3m.es>; Jana Iyengar <jri@google.com>; quic@ietf.org
Subject: Re: [QUIC] Drafts structure and split<= /p>

=C2=A0

=C2=A0

=C2=A0

On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind <JimRoskind@gmail.com= > wrote:

On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett <ianswett@google.com= > wrote:

...

It's worth noting that BBR is only a change to t= he congestion controller, ....

=C2=A0

=C2=A0

=C2=A0

BBR relies on getting estimates of transit time, so = as to estimate variations in buffer sizes.=C2=A0 As a relatively rough esti= mate, I believe BBR in TCP relies on traditional-TCP RTT calculations, whic= h includes the round trip sum of transit times in both directions.=C2=A0 I expect that better one-way transit time = estimates can be harvested in QUIC, by changing the data included in ACK fr= ames to better illuminate transit times in each directions (or more precise= ly, illuminate changes, from one packet to the next, in one-way transit times).

=C2=A0

=E2=80=8BCorrect me if I'm wrong, but QUIC ACK frames already have thi= s information. The contain the arrival time of each packet at the peer, which provides the one-way transfer time.

=E2=80=8B

=C2=A0

=C2=A0Such modifications appear at first blush to be= notably larger than just a change to the congestion controller.<= /u>

=C2=A0

Similarly, I'd expect modifications to support E= CN in QUIC to run much deeper than a congestion controller.

=C2=A0

Jim=C2=A0


_______________________________________________
QUIC mailing list
QUIC@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/quic

=C2=A0


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--047d7bb70e2e7cc845053fc4db16-- From nobody Wed Oct 26 06:52:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74C129B6E for ; Wed, 26 Oct 2016 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id razdiYR2Z942 for ; Wed, 26 Oct 2016 06:52:39 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4B129BA5 for ; Wed, 26 Oct 2016 06:52:39 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q7so3854577qtq.1 for ; Wed, 26 Oct 2016 06:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OBOanv64m58xv8lOSpC632uOMOl/dE/OjCVNzOWr1uU=; b=E67J5me1vrHZiMIdmb10q5DN4lWUVNEF99PtntvmuoyfVfvNbU3EI+uPObQRpBvTYf WYgmQFpQwzBGE4VBgFi5eineIrPukO2NatnjjS+PzUosFmawKdGmxKrEeGrmMj3I047d CBQbsmLKPBHqfhOEZnKanjLCIuSu6C0fK0pTVTgsH3TaeY0T5v5eu0Njw/DQppujL/tG 6lVzhgvPnP9jERJUW9Zb0zuolAa/VQFd2HLto1hzlT6mZLyrWyJfQLXya6475Vu7YfOo Rest9EgVyL21p5AiAwTbZxB7+6aqqbmm+3Zl7KhZSTSdafeja6wQ0nK+TXNrwzKt1eom 4iCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OBOanv64m58xv8lOSpC632uOMOl/dE/OjCVNzOWr1uU=; b=EWA9MgwfRHys3Z33kXSLU0ckAuKXelRbXK5cDlx8MoBUNDbtkQbclc4x5V9vJNgR1Y DUZMbnj97A3ysUge7HT4/xC8SX1drxmkiJvDdhxIZ9r9xXeNRix2xdZ4OE4Mxi3OiJWN lzNzqKnCxG1Y0LHpKdvvBYGkM4AWf5t7MiJsv9kWQDkkAnsUQ1N9XGfhRw8vIWTSiZYr f6c5wm98mFWYGEbIp1RmhCoiW5/VDji/7RX5O/zK6UgQAD/DL5HawiT8IxzuKQnbf2kJ l+e9dXEIaQ5dGLtWmuu85aM2OK1eyVgx5d54V24nMz9Q+5c3w3J3BhJNIWWNrtH4lNCQ OkMQ== X-Gm-Message-State: ABUngvd2UT0gS7Deu2C17D1qlzaFHTedRQeK0kYmWLnkfzPoD1avljrvJAK93ANlmlzRA22gpfe4KnZhsrlVaQ== X-Received: by 10.200.51.152 with SMTP id c24mr1795441qtb.74.1477489958394; Wed, 26 Oct 2016 06:52:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Wed, 26 Oct 2016 06:52:08 -0700 (PDT) In-Reply-To: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> From: Ted Hardie Date: Wed, 26 Oct 2016 06:52:08 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a114242ae2120ae053fc4f095 Archived-At: Cc: quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 13:52:43 -0000 --001a114242ae2120ae053fc4f095 Content-Type: text/plain; charset=UTF-8 Howdy, Two thoughts: our first working group meeting will be in Asia and our second in the U.S.--would you like a space in Europe for the interim? For remote attendees, will we use meetecho or something else? best, Ted On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham wrote: > Everyone, > > We'd like to get our first interim meeting nailed down soon. We have a > host with with what we believe to be a suitable space in Tokyo, Japan on > 24-26 January. > > To make sure that it's suitable for a good portion of the WG, as well as > to assist planning, please fill out this poll to indicate your availability: > http://doodle.com/poll/ams8q39eecud4zih > > In particular, if you'd like to actively participate but the cannot make > those dates, please indicate that with "Cannot make it." > > We'll have more details soon. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > > > Sent from my iPhone > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114242ae2120ae053fc4f095 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Two thoughts:=C2=A0 our= first working group meeting will be in Asia and our second in the U.S.--wo= uld you like a space in Europe for the interim?=C2=A0=C2=A0 For remote atte= ndees, will we use meetecho or something else?

best,
=

Ted

On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham <mnot@mnot.net> wrote:
Everyone,

We'd like to get our first interim meeting nailed down soon. We have a = host with with what we believe to be a suitable space in Tokyo, Japan on 24= -26 January.

To make sure that it's suitable for a good portion of the WG, as well a= s to assist planning, please fill out this poll to indicate your availabili= ty:
=C2=A0 http://doodle.com/poll/ams8q39eecud4zih

In particular, if you'd like to actively participate but the cannot mak= e those dates, please indicate that with "Cannot make it."

We'll have more details soon.

Cheers,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



Sent from my iPhone
_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a114242ae2120ae053fc4f095-- From nobody Wed Oct 26 06:56:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FDD129B9D for ; Wed, 26 Oct 2016 06:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixs0eo0MsIjG for ; Wed, 26 Oct 2016 06:56:17 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 67C55129BA4 for ; Wed, 26 Oct 2016 06:56:05 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id BC24C1A114D; Wed, 26 Oct 2016 15:55:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CED706D0-905D-4883-A1F9-CA3F91860B9C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Wed, 26 Oct 2016 15:55:34 +0200 Message-Id: <42C7E4D4-823B-43DD-AFB7-A239198FE6C7@trammell.ch> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mark Nottingham , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 13:56:21 -0000 --Apple-Mail=_CED706D0-905D-4883-A1F9-CA3F91860B9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And another half-thought: the poll seems to provide no way to indicate = availability/preference for in-person versus remote attendance. I'd = think that would be a useful piece of input for the chairs to have. Cheers, Brian > On 26 Oct 2016, at 15:52, Ted Hardie wrote: >=20 > Howdy, >=20 > Two thoughts: our first working group meeting will be in Asia and our = second in the U.S.--would you like a space in Europe for the interim? = For remote attendees, will we use meetecho or something else? >=20 > best, >=20 > Ted >=20 > On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham = wrote: > Everyone, >=20 > We'd like to get our first interim meeting nailed down soon. We have a = host with with what we believe to be a suitable space in Tokyo, Japan on = 24-26 January. >=20 > To make sure that it's suitable for a good portion of the WG, as well = as to assist planning, please fill out this poll to indicate your = availability: > http://doodle.com/poll/ams8q39eecud4zih >=20 > In particular, if you'd like to actively participate but the cannot = make those dates, please indicate that with "Cannot make it." >=20 > We'll have more details soon. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 > Sent from my iPhone > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_CED706D0-905D-4883-A1F9-CA3F91860B9C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYELXWAAoJEIoSt78L6kajQsAP/2EY4CjPlIYdGjOXC9RuqcSq iL3prPfPsdsZWJ07Pwdh7n6X/C5mIw8UwRl/J1/CxNwDg1qBs32usklVAbF70DHu VFdUf54BDAke9b66awYU8XedYVxgjqELgY3CxfDF5EPl0q6VhbthXQ4Tpyt5dyf4 zC/dAEZ7kEvns+NoyjpTIdDCJVG+xdWI9D9Dt1kigq/k1OB3mBTPVjd8N8wa0stL X3SzUiS3HhiuAFsF43q5yIAWxHQPu7oD1q5bgtqV3o08yyE0k8MojeUEY0fDQBn1 tPGYjWvibHr3lwK+NmmUGxN5xJi/zTr8Pt+RxSm6ZJGYLjMvb7j0ZGzkLJe6utwz 9WHCOQbzOxjqn/8VF3jZY3R7YpP/25MFbXKMRiMcpS9UFbpFnc8ZG87kgUzrfoD8 2WapkZrhZp5td2soX8m/pYerXgY7AFnqlHpLyqO4VeSYV+c1klFJccvhyhnG4rjl 8HQ3MKzQcQzXZdYV8Y1HxrrGj4X2jv3n5m0IhDOq1uWQaiDQYbyB0TfT5ojjYSyy r077NskxjslXumZJN7zyx2Y9bGFZxUhH0x8073xiR1bn+COpKFps1gd1pFuBaxsy 8HN9FoT4VKRxQ4HFzpx7ksciXDzLI1Qgm8/084jLVSixdlY4tfZ044ERWAvM7qAJ IXb09RFrK5VXKuVu+FqP =r1y3 -----END PGP SIGNATURE----- --Apple-Mail=_CED706D0-905D-4883-A1F9-CA3F91860B9C-- From nobody Wed Oct 26 07:11:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9F1294FE for ; Wed, 26 Oct 2016 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVFDc7_dW77y for ; Wed, 26 Oct 2016 07:11:26 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82B9129467 for ; Wed, 26 Oct 2016 07:11:26 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id f133so2136513ybc.3 for ; Wed, 26 Oct 2016 07:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iX4XUIW3rkj4ea5J54pcaN97jWUHOaHX43iOrBrgZTk=; b=FNMQqScE4Yn/VAQSLeNMUY6SPi5cSIJgfzWw0+1Ayu1rzjTNkv51z5y7axkFGW0yJb iVkfX+jnQNKcEti963YIgDFjs+z0B3hiwqkwpgIKuVM4Uab3viZtHJQ05XmXjyITjJDb /QViYSVsxBsSvEj5wos4LH7U8nd8aSJwm5srYni1qX7VMEAjkht1vgtGDX5zuO9VO1vC jj+6WGEuMTcSTY8brO3sjJ/TE5kkNd7dU6hPFsQZwceGl8veCjkYEX9gV+fJKZjlcP5d 4qNL8AV6aJ02FwsMIkWeBfAYIE/D2h5Bd3IReJ8TeSfvJFjMFhWEByj6ra+iMwO7MNLr YNbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iX4XUIW3rkj4ea5J54pcaN97jWUHOaHX43iOrBrgZTk=; b=OdewRge8KNrBLxes5oIO2fa7oIRM/ZUku0F4tMxhop1xvOjsBwXV18bEQYM3AMOLfD 8yot1zNc8AyWk8U+g5gwz9Wzcz1+6qj58OXDzzNSvw85AZWLo9undYCXJrIUhxXGiQgt MNC5Rxn9BECSsGTtUvzsixEc2db9457EXReuOMoS/6gcffdOViTM9YDqF628H2IiE2xd ls+h88Plre+L/eo3Tq8vIHKNmDqSn5g049DW5cluyXS9G/P2bQ/E4RTlq/Kml06xmvMH ZbQ1JJIAGuTwrFS8TGkrzcTCsMBYTZ3vYjSOa7H56M+HWKofmtyfQhaUh24YDX4cgLVi C7oA== X-Gm-Message-State: ABUngvcLc5VEYmMJTyUPZRuJChAckw4/sFFkQk/hPR7Hz/YpgitwnXhgkrqp7wBYNquT9nY0rJ0bLMqOMhjpvMjU X-Received: by 10.37.173.1 with SMTP id y1mr670714ybi.88.1477491085837; Wed, 26 Oct 2016 07:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.39.135 with HTTP; Wed, 26 Oct 2016 07:11:05 -0700 (PDT) In-Reply-To: <42C7E4D4-823B-43DD-AFB7-A239198FE6C7@trammell.ch> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <42C7E4D4-823B-43DD-AFB7-A239198FE6C7@trammell.ch> From: Ian Swett Date: Wed, 26 Oct 2016 10:11:05 -0400 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=f403045dc5d254dde0053fc533d9 Archived-At: Cc: Ted Hardie , quic@ietf.org, Lars Eggert , Mark Nottingham Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 14:11:31 -0000 --f403045dc5d254dde0053fc533d9 Content-Type: text/plain; charset=UTF-8 I would second both Ted and Brian's comments. On Wed, Oct 26, 2016 at 9:55 AM, Brian Trammell wrote: > And another half-thought: the poll seems to provide no way to indicate > availability/preference for in-person versus remote attendance. I'd think > that would be a useful piece of input for the chairs to have. > > Cheers, > > Brian > > > > On 26 Oct 2016, at 15:52, Ted Hardie wrote: > > > > Howdy, > > > > Two thoughts: our first working group meeting will be in Asia and our > second in the U.S.--would you like a space in Europe for the interim? For > remote attendees, will we use meetecho or something else? > > > > best, > > > > Ted > > > > On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham wrote: > > Everyone, > > > > We'd like to get our first interim meeting nailed down soon. We have a > host with with what we believe to be a suitable space in Tokyo, Japan on > 24-26 January. > > > > To make sure that it's suitable for a good portion of the WG, as well as > to assist planning, please fill out this poll to indicate your availability: > > http://doodle.com/poll/ams8q39eecud4zih > > > > In particular, if you'd like to actively participate but the cannot make > those dates, please indicate that with "Cannot make it." > > > > We'll have more details soon. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > > Sent from my iPhone > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > > > _______________________________________________ > > QUIC mailing list > > QUIC@ietf.org > > https://www.ietf.org/mailman/listinfo/quic > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --f403045dc5d254dde0053fc533d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would second both Ted and Brian's comments.

On Wed, Oct 26, 2016= at 9:55 AM, Brian Trammell <ietf@trammell.ch> wrote:
And another half-thought: the poll seems to prov= ide no way to indicate availability/preference for in-person versus remote = attendance. I'd think that would be a useful piece of input for the cha= irs to have.

Cheers,

Brian


> On 26 Oct 2016, at 15:52, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> Two thoughts:=C2=A0 our first working group meeting will be in Asia an= d our second in the U.S.--would you like a space in Europe for the interim?= =C2=A0 =C2=A0For remote attendees, will we use meetecho or something else?<= br> >
> best,
>
> Ted
>
> On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Everyone,
>
> We'd like to get our first interim meeting nailed down soon. We ha= ve a host with with what we believe to be a suitable space in Tokyo, Japan = on 24-26 January.
>
> To make sure that it's suitable for a good portion of the WG, as w= ell as to assist planning, please fill out this poll to indicate your avail= ability:
>=C2=A0 =C2=A0http://doodle.com/poll/ams8q39eecud4zih=
>
> In particular, if you'd like to actively participate but the canno= t make those dates, please indicate that with "Cannot make it." >
> We'll have more details soon.
>
> Cheers,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
>
>
> Sent from my iPhone
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic >
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--f403045dc5d254dde0053fc533d9-- From nobody Wed Oct 26 08:39:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00BE12967B for ; Wed, 26 Oct 2016 08:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Trcm_fD3Te for ; Wed, 26 Oct 2016 08:39:34 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7CD129672 for ; Wed, 26 Oct 2016 08:39:34 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id g68so2657774ybi.0 for ; Wed, 26 Oct 2016 08:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rzaPSPVw0fhQF5PaCgCsSCa1+CW8Mo/83tLSrGdeoNA=; b=JRaYlMwFSV6MFOjXmphk96kdRb12WG/BS6hpEQ6dtMWItoHZG1fEpJjtqxw/rrjggw maqVFrA9FiHmNvvBrljgL4lwRgQgSZgRadMMRFBxpjrJFRs/Cpokmzgl9E+Pa+ZFzQTN vzQ68mmdZI8+rk79WYQShtbKGgjPT1wKLLZXCeEvOjhFCFcuHey4l/Vpixw5GlnXOXhP nNUuvuFU9G3j8FDVG7RCAnhlzh+L8/8ZRfnLwZ12T5tR+N5+DYPl6F3FabOzphfiCtB4 dCzbyILSjNjLY4EhXheLE8EJy3/iM9jp2mBEYlBW9ZsnR5OkdqX1ih6LKMS9pFyz4ZRJ KjWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rzaPSPVw0fhQF5PaCgCsSCa1+CW8Mo/83tLSrGdeoNA=; b=NG17nof/qNVjybcVy1jbJ/N5evdlucyHAmqDOrROVSnxciblSRwLXfXgxw42nwLNMZ VFAMugsX4rwwJ5Qm4yqtuLJtyzgJFjGGN6OxWbZkQ4aJuZ6SZM8+sKHtFZRPmYwNyEM2 4xyT5RWXH6FFC2fAH3iATSNFzGwEOJpqV5NixhgCeXq+FMIUV2sU+cJC6bIdOE0ty1A+ U3dz8dU8MXBt0bXryXOJX1xz12FBJuAZ5SNQnjzzpkAzW60nbN4cAoFd57m1Vjx3cyEW 3zX4FoI6pwG8FwLbpdX+wfbK1OKz4mUQUvVofs/V64xnzlajw4Ihvz4PLQASkVLD2mTs t3LQ== X-Gm-Message-State: ABUngvd8mdLwCS5C6I75KuTq0oko4mUbZl7Uiig40km+DZThSWoVGyGhqpWr701cj0MGBNk5aaxp4GTxK2jJZA== X-Received: by 10.37.105.67 with SMTP id e64mr2317105ybc.102.1477496373841; Wed, 26 Oct 2016 08:39:33 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.51.137 with HTTP; Wed, 26 Oct 2016 08:39:32 -0700 (PDT) In-Reply-To: References: <9c410dde-69f6-ed95-c7ef-805512b9f2de@it.uc3m.es> <8F65FCBF-1701-4025-8D9C-9819D040E206@huitema.net> From: Jim Roskind Date: Wed, 26 Oct 2016 08:39:32 -0700 X-Google-Sender-Auth: aTv3qlrr-3Ue5ws0P_dSDZTKqzQ Message-ID: To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c14ea2c853103053fc66e7b Archived-At: Cc: Ian Swett , Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , marcelo bagnulo braun , Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] Drafts structure and split X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 15:39:37 -0000 --94eb2c14ea2c853103053fc66e7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2016 at 9:09 PM, Ryan Hamilton wrote: > > > On Tue, Oct 25, 2016 at 7:13 PM, Jim Roskind wrote= : > >> On Mon, Oct 24, 2016 at 5:31 PM, Ian Swett wrote: >> >>> ... >>> It's worth noting that BBR is only a change to the congestion >>> controller, .... >>> >>> >>> >> BBR relies on getting estimates of transit time, so as to estimate >> variations in buffer sizes. As a relatively rough estimate, I believe B= BR >> in TCP relies on traditional-TCP RTT calculations, which includes the ro= und >> trip sum of transit times in both directions. I expect that better one-= way >> transit time estimates can be harvested in QUIC, by changing the data >> included in ACK frames to better illuminate transit times in each >> directions (or more precisely, illuminate changes, from one packet to th= e >> next, in one-way transit times). >> > > =E2=80=8BCorrect me if I'm wrong, but QUIC ACK frames already have this > information. The contain the arrival time of each packet at the peer, whi= ch > provides the one-way transfer time. > Absolutely (and since you implemented and are probably maintaining this in the Google implementation, you'd know if there was any change in that status quo). The cross-stack requirements in the QUIC Rationale and Design Doc motivated the placement and use of timestamps in ACK frames for evaluating bottleneck bandwidth back in 2012. All that "frame level" design was part of congestion control design, even though at the time we were only using traditional TCP-style congestion control (which did not call for the time extra timestamps). All of this is indeed a reflection of the tight integration between the elements, and across the stack. That is why I'd argue that it is difficult to divide a QUIC standard (into a multitude of separate docs) across layers, when delicate details in one layer are heavily depended upon, and perchance varied greatly, to better suit needs of would-be "other layers." For instance, consideration may be given to adjust the resolution, range, or coding of those ACK-frame timestamps specifically for congestion algorithms like BBR, but such a change would sadly not be confined to otherwise isolated docs about congestion avoidance. :-( As other folks look at, and experiment with, other variants of congestion control, such as ECN, it becomes plausible that different metrics will be needed at different levels of the protocol. It would be a shame if standardization in one "layer" made it more difficult to rapidly evolve broader advances for QUIC. I guess on the other side, it sure would be nice if we were all brilliant enough to standardize ALL required hooks...but that seems more than hard. If we can find nice partitioning points, that would be great, but I was hard pressed to expect much more than the crypto separation, and still allow for rapid ongoing evolution. Even with crypto, there were interesting cross-stack requirements, but getting crypto right is soooo hard, that separation seemed very prudent (along with somewhat freezing supporting issues elsewhere in the protocol). Jim [Opinions expressed are my own, and not that of my employer] --94eb2c14ea2c853103053fc66e7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 25, 2016 at 9:09 PM, Ryan Hamilton <rch@google.com>= wrote:

On Tue, Oct 25, 2016 at 7:13 P= M, Jim Roskind <JimRoskind@gmail.= com> wrote:
On Mon, Oct 24, 201= 6 at 5:31 PM, Ian Swett <ianswett@= google.com> wrote:
...
It's worth noting that BBR is only a change= to the congestion controller, ....
<= br>


BBR relies on getting estimates of transit time, so as to estimate v= ariations in buffer sizes.=C2=A0 As a relatively rough estimate, I believe = BBR in TCP relies on traditional-TCP RTT calculations, which includes the r= ound trip sum of transit times in both directions.=C2=A0 I expect that bett= er one-way transit time estimates can be harvested in QUIC, by changing the= data included in ACK frames to better illuminate transit times in each dir= ections (or more precisely, illuminate changes, from one packet to the next= , in one-way transit times).

<= /div>
=E2=80=8BCorrect me if I'm wrong, but QUIC ACK fram= es already have this information. The contain the arrival time of each pack= et at the peer, which provides the one-way transfer time.
=

Absolutely (and since you impl= emented and are probably maintaining this in the Google implementation, you= 'd know if there was any change in that status quo). The cross-stack re= quirements in the QUIC Rationale and Design Doc motivated the placement and= use of timestamps in ACK frames for evaluating bottleneck bandwidth back i= n 2012. All that "frame level" design was part of congestion cont= rol design, even though at the time we were only using traditional TCP-styl= e congestion control (which did not call for the time extra timestamps).

All of this is indeed a reflection of the tight inte= gration between the elements, and across the stack. That is why I'd arg= ue that it is difficult to divide a QUIC standard (into a multitude of sepa= rate docs) across layers, when delicate details in one layer are heavily de= pended upon, and perchance varied greatly, to better suit needs of would-be= "other layers." =C2=A0

For instance, co= nsideration may be given to adjust the resolution, range, or coding of thos= e ACK-frame timestamps specifically for congestion algorithms like BBR, but= such a change would sadly not be confined to otherwise isolated docs about= congestion avoidance. :-( =C2=A0As other folks look at, and experiment wit= h, other variants of congestion control, such as ECN, it becomes plausible = that different metrics will be needed at different levels of the protocol. = =C2=A0

It would be a shame if standardization in o= ne "layer" made it more difficult to rapidly evolve broader advan= ces for QUIC.

I guess on the other side, it sure w= ould be nice if we were all brilliant enough to standardize ALL required ho= oks...but that seems more than hard.

If we can fin= d nice partitioning points, that would be great, but I was hard pressed to = expect much more than the crypto separation, and still allow for rapid ongo= ing evolution. Even with crypto, there were interesting cross-stack require= ments, but getting crypto right is soooo hard, that separation seemed very = prudent (along with somewhat freezing supporting issues elsewhere in the pr= otocol).

Jim

[Opinions ex= pressed are my own, and not that of my employer]

=
--94eb2c14ea2c853103053fc66e7b-- From nobody Wed Oct 26 10:10:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9FD129721 for ; Wed, 26 Oct 2016 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1FNsLl_xqRb for ; Wed, 26 Oct 2016 10:10:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2066012969C for ; Wed, 26 Oct 2016 10:10:20 -0700 (PDT) X-AuditID: c1b4fb25-14bff7000000793b-38-5810e37a7247 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id B0.1D.31035.B73E0185; Wed, 26 Oct 2016 19:10:19 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 26 Oct 2016 19:10:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jBPMu46Ds+nzg6dc93rXR8b1uZK187HEk/gnC/iYmzc=; b=gzVWABhy1b1p747rZe244K02AX1tA3AVxbHNhW2rhCz8jI0duy0I+nb1Riugnrsckv74sDQV4JNtCK+fhyep+8yx9VwGGAI3g2l941S3sMwmwv29mgy2edDjIiee1BcAbv8RFwy8eds+zdrdI6yEGepo3Fb/I1X9qbq76Co7Hls= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB350.eurprd07.prod.outlook.com (10.141.12.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Wed, 26 Oct 2016 17:10:17 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) by DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) with mapi id 15.01.0649.027; Wed, 26 Oct 2016 17:10:17 +0000 From: Ingemar Johansson S To: Ryan Hamilton Thread-Topic: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) Thread-Index: AQHSL499mWSd+VhNgk+Qp+hFPjBxkaC69qZw Date: Wed, 26 Oct 2016 17:10:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [213.113.27.92] x-microsoft-exchange-diagnostics: 1; DBXPR07MB350; 7:qYXXTUbQGM9n2TzPGil9UcfWL7mtY/oACn/he8Z/YGRMMtcTAWUL2998Ih0hSvemgJWv0abvp/LG7YVwGEgAlD5nMEXvpGEKIjIXGT0aPMGw8rel8v6/HR5/C7REvvsIbohcb/Y461FA9owfVPH2MNYk+FYcj1Ob8IvJsN+SbxXe1FNYeNQcTEb2B6A+QLudIaC8NdCTGJxiFcVlfRq++DKClERLY9FqLn0hM91aKs9jDJzHzkoYHk3SgofXnCN+2xAvwvb1xStnMyM9rCtq7Qm9l6zQU3aTl2fEOf17B+/NdlW2yCjbf+dgTISFaaFRMzqMxYVOLZNWst4XkrZK/7ewpkZyJJUCto02jwflw6k= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(377454003)(189002)(199003)(24454002)(87936001)(86362001)(7736002)(7906003)(10400500002)(189998001)(6116002)(102836003)(790700001)(2906002)(19580395003)(11100500001)(19580405001)(74316002)(7846002)(3846002)(81156014)(8676002)(3280700002)(81166006)(586003)(19300405004)(97736004)(19609705001)(8936002)(19617315012)(5002640100001)(3660700001)(2950100002)(6916009)(19625215002)(7696004)(5660300001)(76576001)(68736007)(110136003)(9686002)(66066001)(92566002)(16236675004)(76176999)(122556002)(33656002)(101416001)(77096005)(106356001)(106116001)(50986999)(2900100001)(54356999)(105586002)(15975445007)(217423001)(4326007)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB350; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: f4801a9a-e3cd-40eb-a66d-08d3fdc2f5c7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(120809045254105)(211936372134217)(176510541525296)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB350; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB350; x-forefront-prvs: 0107098B6C received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB351274DBBCBD2FA7655D83BC2AB0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2016 17:10:17.7106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB350 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3bv7u6sxePUPJhSjoYvpJaFXMLUqGxBhUqU2IecektJp2xq Wl9SW+XLtHSSL9VmzYZZqSG+hIqKRS+KSZZZvqdhYh/KSqaobbsL/PY/5/zO/5zz8NCEeILv QicoUlmlQp4ooezI8sjmHT6Xv+LIXbk/tjElWZUCxjTWymceLjymmOIXVSRTN1tMMeqZRxRT oN/I6H5qSOahto0IEcpaK0YFMv2zNNnnsjekzGAw8WR/hxr4sryBRV4YFWUXGMcmJqSzSr+g aLv4uupCKiW7F2Vcvz9DXUHvXqI8JKQB74WR+V4qD9nRYlyHoEn9EXHBKwTD5XesAYk1BNTX rtiwEh7kFMzZgh4EHwpLCYsZhQOhpnvRauyIJdCfr+FZIAJ38KDyVoO14IDj4OnykLmbNkMs FGRt5Hh/+PbpBmnRJJbC1BejFRHhKChbZbhZVQjmGrKss4Q4HIaHlvgWjbAbjC+OWXsJ7Ayf p3U87jgMhrZ+gtNO8P3rqo2PhV/DGr7FH7A79GgvWvwB6wgYG6nnc0EPBUVTxQQHHYc/zeGc z2GoNLwhOZ0AKx1qHscXIqjW99mamxAUVS3ZKFfo+DFgnSw2H2x8orY9hAuMDuaim8irYt3i nE4G9WwfYdEibA+vy6fJCvMeBPaCuud+HOIO2vxJAac9QX3nrmB9Xo8Ej5CTilXFJJ333+PL KhNiVapkha+CTX2GzP+uq3FZ2oLezx/oRphGkk2iiSYcKebL01WZSd0IaELiKDJOmlOiOHnm JVaZfFaZlsiqutFWmpQ4iwJqxk+L8Xl5KnuBZVNY5f8qjxa6XEGZ+HbOaPq9sert1ODMzq6o k+76tZgeV4+JLadqrjWdic0IDpl4O3LUO9hhocIQHbVPpzkREHHGN9THGFB7LNLPfiW4tNHj kKO2UWJKXLP3LMapYUFl+rDSllDjYPbvZi3TfjDnweJCTfs56X7pkQ2mTntqc+dVN7FwS8HP dHYqQkKq4uW7vQmlSv4PgTqSCHMDAAA= Archived-At: Cc: Ian Swett , Kyle Rose , Christian Huitema , Spencer Dawkins at IETF , Jana Iyengar , marcelo bagnulo braun , Jim Roskind , "quic@ietf.org" Subject: Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:10:24 -0000 --_000_DBXPR07MB351274DBBCBD2FA7655D83BC2AB0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3YXMgaW50ZXJlc3RpbmcuDQpJIHByb2JhYmx5IG5lZWQgc29tZSBwZW4gYW5kIHBhcGVy IGV4ZXJjaXNlIHRvIGZpZ3VyZSBvdXQgaG93IGdvb2Qgc3luY2hyb25pemF0aW9uIG9uZSBjYW4g Z2V0IHRoaXMuIElmIGl0IGlzIHdpdGhpbiAyMC0zMG1zIChyb3VnaCBmaWd1cmUpIHRoZW4gaXQg Y2FuIGJlIHVzZWZ1bC4gT3RoZXJ3aXNlIGl0IGNhbiBzdGlsbCBiZSB1c2VmdWwgYXMgaXQgY2Fu IGhlbHAgdG8gcmVtZWR5IGZvciBpbnN0YW5jZSBsYXRlIGNvbWVycyBhZHZhbnRhZ2UgYW5kIGJh c2UtZGVsYXkgaW5mbGF0aW9uIGlzc3VlcyB0aGF0IGlzIGEga25vd24gcHJvYmxlbSBmb3IgTEVE QkFULg0KDQovSW5nZW1hcg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9uIFttYWlsdG86cmNoQGdvb2ds ZS5jb21dDQpTZW50OiBkZW4gMjYgb2t0b2JlciAyMDE2IDE1OjQ3DQpUbzogSW5nZW1hciBKb2hh bnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogSmltIFJvc2tp bmQgPEppbVJvc2tpbmRAZ21haWwuY29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29t PjsgS3lsZSBSb3NlIDxrcm9zZUBrcm9zZS5vcmc+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVt YUBodWl0ZW1hLm5ldD47IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5p ZXRmQGdtYWlsLmNvbT47IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0BpdC51YzNtLmVz PjsgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbUVVJQ10gUVVJQyBBQ0sgZnJhbWVzIGFuZCBvbmUtd2F5IHRyYW5zZmVyIHRpbWUgKHdh cyBSRTogRHJhZnRzIHN0cnVjdHVyZSBhbmQgc3BsaXQpDQoNClllcywgY2xvY2sgc3luY2hyb25p emF0aW9uIGlzIGFuIGlzc3VlLCBidXQgUVVJQyBtYWtlcyBhbiBhdHRlbXB0IHRvIGRlYWwgd2l0 aCBpdC4gVGhlIHJlY2VpcHQgInRpbWUiIGluIHRoZSBBQ0sgZnJhbWUgaXMgbm90IGFuIGFjdHVh bCB3YWxsIHRpbWUsIGJ1dCBpcyBpbnN0ZWFkIGEgdGltZSBkZWx0YSBzaW5jZSB0aGUgY29ubmVj dGlvbiBpcyBlc3RhYmxpc2hlZC4gQXNzdW1pbmcgdGhhdCB0aGUgY2xvY2tzIGFyZSBtb3Zpbmcg Zm9yd2FyZCBhdCByb3VnaGx5IHRoZSBzYW1lIHJhdGUsIHRoaXMgbWVhbnMgdGhhdCB0aGUgcmVs YXRpdmUgc2tldyBpbiB0aGVzZSBkZWx0YXMgaXMgdGhlIHRpbWUgaXQgdG9vayBmb3IgdGhlIENI TE8gdG8gcmVhY2ggdGhlIHNlcnZlciwgYW5kIHRoZSBwZWVycyBjYW4gYWNjb3VudCBmb3IgdGhp cyBpbiBzdWJzZXF1ZW50IGNhbGN1bGF0aW9ucy4NCg0KDQpPbiBXZWQsIE9jdCAyNiwgMjAxNiBh dCA0OjA2IEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToN CkhpDQoNClJ5YW4uIFlvdSBhcmUgcmlnaHQgdGhhdCB0aGUgUVVJQyBBQ0sgZnJhbWVzIGFscmVh ZHkgY29udGFpbnMgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiB0byBjb21wdXRlIHRoZSBvbmUg d2F5IGRlbGF5LiBJdCBpcyBvZiBjb3Vyc2Ugbm90IHBvc3NpYmxlIHRvIGRlZHVjZSB0aGUgdHJ1 ZSBvbmUgd2F5IGRlbGF5IHVubGVzcyB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciBjbG9ja3MgYXJl IHN5bmNocm9uaXplZC4gV2hhdCBpcyBlYXN5IHRvIGRldGVybWluZSBpcyB0aGUgcXVldWUgZGVs YXkgdGhhdCBjYW4gYmUgdXNlZCBpbiBhIHdheSBzaW1pbGFyIHRvIGhvdyBMRURCQVQgZG9lcyBp dCwgdGhlcmUgYXJlIHNvbWUgcHJvcyBhbmQgY29ucyB3aXRoIHRoYXQgYXBwcm9hY2guDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVn LyBkZXNjcmliZXMgYSBtb2RpZmljYXRpb24gdG8gQ3ViaWMgdGhhdCBpcyBiYXNlZCBvbiB0aGlz IHByaW5jaXBsZS4NCg0KL0luZ2VtYXINCg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9uIFttYWlsdG86 cmNoQGdvb2dsZS5jb208bWFpbHRvOnJjaEBnb29nbGUuY29tPl0NClNlbnQ6IGRlbiAyNiBva3Rv YmVyIDIwMTYgMDY6MDkNClRvOiBKaW0gUm9za2luZCA8SmltUm9za2luZEBnbWFpbC5jb208bWFp bHRvOkppbVJvc2tpbmRAZ21haWwuY29tPj4NCkNjOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2ds ZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsgS3lsZSBSb3NlIDxrcm9zZUBrcm9z ZS5vcmc8bWFpbHRvOmtyb3NlQGtyb3NlLm9yZz4+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVt YUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBTcGVuY2VyIERhd2tp bnMgYXQgSUVURiA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNwZW5jZXJk YXdraW5zLmlldGZAZ21haWwuY29tPj47IG1hcmNlbG8gYmFnbnVsbyBicmF1biA8bWFyY2Vsb0Bp dC51YzNtLmVzPG1haWx0bzptYXJjZWxvQGl0LnVjM20uZXM+PjsgSmFuYSBJeWVuZ2FyIDxqcmlA Z29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUVVJQ10gRHJhZnRzIHN0cnVjdHVyZSBhbmQg c3BsaXQNCg0KDQoNCk9uIFR1ZSwgT2N0IDI1LCAyMDE2IGF0IDc6MTMgUE0sIEppbSBSb3NraW5k IDxKaW1Sb3NraW5kQGdtYWlsLmNvbTxtYWlsdG86SmltUm9za2luZEBnbWFpbC5jb20+PiB3cm90 ZToNCk9uIE1vbiwgT2N0IDI0LCAyMDE2IGF0IDU6MzEgUE0sIElhbiBTd2V0dCA8aWFuc3dldHRA Z29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KLi4uDQpJdCdz IHdvcnRoIG5vdGluZyB0aGF0IEJCUiBpcyBvbmx5IGEgY2hhbmdlIHRvIHRoZSBjb25nZXN0aW9u IGNvbnRyb2xsZXIsIC4uLi4NCg0KDQoNCkJCUiByZWxpZXMgb24gZ2V0dGluZyBlc3RpbWF0ZXMg b2YgdHJhbnNpdCB0aW1lLCBzbyBhcyB0byBlc3RpbWF0ZSB2YXJpYXRpb25zIGluIGJ1ZmZlciBz aXplcy4gIEFzIGEgcmVsYXRpdmVseSByb3VnaCBlc3RpbWF0ZSwgSSBiZWxpZXZlIEJCUiBpbiBU Q1AgcmVsaWVzIG9uIHRyYWRpdGlvbmFsLVRDUCBSVFQgY2FsY3VsYXRpb25zLCB3aGljaCBpbmNs dWRlcyB0aGUgcm91bmQgdHJpcCBzdW0gb2YgdHJhbnNpdCB0aW1lcyBpbiBib3RoIGRpcmVjdGlv bnMuICBJIGV4cGVjdCB0aGF0IGJldHRlciBvbmUtd2F5IHRyYW5zaXQgdGltZSBlc3RpbWF0ZXMg Y2FuIGJlIGhhcnZlc3RlZCBpbiBRVUlDLCBieSBjaGFuZ2luZyB0aGUgZGF0YSBpbmNsdWRlZCBp biBBQ0sgZnJhbWVzIHRvIGJldHRlciBpbGx1bWluYXRlIHRyYW5zaXQgdGltZXMgaW4gZWFjaCBk aXJlY3Rpb25zIChvciBtb3JlIHByZWNpc2VseSwgaWxsdW1pbmF0ZSBjaGFuZ2VzLCBmcm9tIG9u ZSBwYWNrZXQgdG8gdGhlIG5leHQsIGluIG9uZS13YXkgdHJhbnNpdCB0aW1lcykuDQoNCuKAi0Nv cnJlY3QgbWUgaWYgSSdtIHdyb25nLCBidXQgUVVJQyBBQ0sgZnJhbWVzIGFscmVhZHkgaGF2ZSB0 aGlzIGluZm9ybWF0aW9uLiBUaGUgY29udGFpbiB0aGUgYXJyaXZhbCB0aW1lIG9mIGVhY2ggcGFj a2V0IGF0IHRoZSBwZWVyLCB3aGljaCBwcm92aWRlcyB0aGUgb25lLXdheSB0cmFuc2ZlciB0aW1l Lg0K4oCLDQoNCiBTdWNoIG1vZGlmaWNhdGlvbnMgYXBwZWFyIGF0IGZpcnN0IGJsdXNoIHRvIGJl IG5vdGFibHkgbGFyZ2VyIHRoYW4ganVzdCBhIGNoYW5nZSB0byB0aGUgY29uZ2VzdGlvbiBjb250 cm9sbGVyLg0KDQpTaW1pbGFybHksIEknZCBleHBlY3QgbW9kaWZpY2F0aW9ucyB0byBzdXBwb3J0 IEVDTiBpbiBRVUlDIHRvIHJ1biBtdWNoIGRlZXBlciB0aGFuIGEgY29uZ2VzdGlvbiBjb250cm9s bGVyLg0KDQpKaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClFVSUMgbWFpbGluZyBsaXN0DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFpbGlu ZyBsaXN0DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQoNCg== --_000_DBXPR07MB351274DBBCBD2FA7655D83BC2AB0DBXPR07MB351eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0 IHdhcyBpbnRlcmVzdGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBwcm9iYWJseSBuZWVkIHNvbWUgcGVuIGFuZCBwYXBl ciBleGVyY2lzZSB0byBmaWd1cmUgb3V0IGhvdyBnb29kIHN5bmNocm9uaXphdGlvbiBvbmUgY2Fu IGdldCB0aGlzLiBJZiBpdCBpcyB3aXRoaW4gMjAtMzBtcyAocm91Z2ggZmlndXJlKSB0aGVuIGl0 IGNhbiBiZSB1c2VmdWwuIE90aGVyd2lzZQ0KIGl0IGNhbiBzdGlsbCBiZSB1c2VmdWwgYXMgaXQg Y2FuIGhlbHAgdG8gcmVtZWR5IGZvciBpbnN0YW5jZSBsYXRlIGNvbWVycyBhZHZhbnRhZ2UgYW5k IGJhc2UtZGVsYXkgaW5mbGF0aW9uIGlzc3VlcyB0aGF0IGlzIGEga25vd24gcHJvYmxlbSBmb3Ig TEVEQkFULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSeWFuIEhhbWlsdG9uIFttYWlsdG86cmNoQGdv b2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDI2IG9rdG9iZXIgMjAxNiAxNTo0Nzxi cj4NCjxiPlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKaW0gUm9za2luZCAmbHQ7SmltUm9z a2luZEBnbWFpbC5jb20mZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7 OyBLeWxlIFJvc2UgJmx0O2tyb3NlQGtyb3NlLm9yZyZndDs7IENocmlzdGlhbiBIdWl0ZW1hICZs dDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgJmx0O3Nw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tJmd0OzsgbWFyY2VsbyBiYWdudWxvIGJyYXVuICZs dDttYXJjZWxvQGl0LnVjM20uZXMmZ3Q7OyBKYW5hIEl5ZW5nYXINCiAmbHQ7anJpQGdvb2dsZS5j b20mZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUVVJQ10gUVVJ QyBBQ0sgZnJhbWVzIGFuZCBvbmUtd2F5IHRyYW5zZmVyIHRpbWUgKHdhcyBSRTogRHJhZnRzIHN0 cnVjdHVyZSBhbmQgc3BsaXQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgY2xvY2sgc3luY2hyb25pemF0aW9uIGlz IGFuIGlzc3VlLCBidXQgUVVJQyBtYWtlcyBhbiBhdHRlbXB0IHRvIGRlYWwgd2l0aCBpdC4gVGhl IHJlY2VpcHQgJnF1b3Q7dGltZSZxdW90OyBpbiB0aGUgQUNLIGZyYW1lIGlzIG5vdCBhbiBhY3R1 YWwgd2FsbCB0aW1lLCBidXQgaXMgaW5zdGVhZCBhIHRpbWUgZGVsdGEgc2luY2UgdGhlDQogY29u bmVjdGlvbiBpcyBlc3RhYmxpc2hlZC4gQXNzdW1pbmcgdGhhdCB0aGUgY2xvY2tzIGFyZSBtb3Zp bmcgZm9yd2FyZCBhdCByb3VnaGx5IHRoZSBzYW1lIHJhdGUsIHRoaXMgbWVhbnMgdGhhdCB0aGUg cmVsYXRpdmUgc2tldyBpbiB0aGVzZSBkZWx0YXMgaXMgdGhlIHRpbWUgaXQgdG9vayBmb3IgdGhl IENITE8gdG8gcmVhY2ggdGhlIHNlcnZlciwgYW5kIHRoZSBwZWVycyBjYW4gYWNjb3VudCBmb3Ig dGhpcyBpbiBzdWJzZXF1ZW50IGNhbGN1bGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBPY3QgMjYsIDIwMTYgYXQgNDowNiBBTSwgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Unlhbi4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllvdSBhcmUgcmln aHQgdGhhdCB0aGUgUVVJQyBBQ0sgZnJhbWVzIGFscmVhZHkgY29udGFpbnMgdGhlIG5lY2Vzc2Fy eSBpbmZvcm1hdGlvbiB0byBjb21wdXRlIHRoZSBvbmUgd2F5IGRlbGF5LiBJdCBpcyBvZiBjb3Vy c2Ugbm90IHBvc3NpYmxlIHRvIGRlZHVjZSB0aGUgdHJ1ZSBvbmUgd2F5IGRlbGF5IHVubGVzcyB0 aGUgc2VuZGVyDQogYW5kIHJlY2VpdmVyIGNsb2NrcyBhcmUgc3luY2hyb25pemVkLiBXaGF0IGlz IGVhc3kgdG8gZGV0ZXJtaW5lIGlzIHRoZSBxdWV1ZSBkZWxheSB0aGF0IGNhbiBiZSB1c2VkIGlu IGEgd2F5IHNpbWlsYXIgdG8gaG93IExFREJBVCBkb2VzIGl0LCB0aGVyZSBhcmUgc29tZSBwcm9z IGFuZCBjb25zIHdpdGggdGhhdCBhcHByb2FjaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01Zy8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2hhbnNz b24tY2MtZm9yLTRnLTVnLzwvYT4NCiBkZXNjcmliZXMgYSBtb2RpZmljYXRpb24gdG8gQ3ViaWMg dGhhdCBpcyBiYXNlZCBvbiB0aGlzIHByaW5jaXBsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi9Jbmdl bWFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSeWFuIEhhbWlsdG9uDQogW21h aWx0bzo8YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5yY2hA Z29vZ2xlLmNvbTwvYT5dIDxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjYgb2t0b2JlciAyMDE2IDA2 OjA5PGJyPg0KPGI+VG86PC9iPiBKaW0gUm9za2luZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkppbVJv c2tpbmRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmltUm9za2luZEBnbWFpbC5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWFuIFN3ZXR0ICZs dDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlh bnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgS3lsZSBSb3NlICZsdDs8YSBocmVmPSJtYWlsdG86 a3Jvc2VAa3Jvc2Uub3JnIiB0YXJnZXQ9Il9ibGFuayI+a3Jvc2VAa3Jvc2Uub3JnPC9hPiZndDs7 IENocmlzdGlhbg0KIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEu bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7OyBTcGVuY2Vy IERhd2tpbnMgYXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OzsgbWFyY2VsbyBiYWdudWxvIGJyYXVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFyY2Vs b0BpdC51YzNtLmVzIiB0YXJnZXQ9Il9ibGFuayI+bWFyY2Vsb0BpdC51YzNtLmVzPC9hPiZndDs7 DQogSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1FVSUNdIERyYWZ0cyBzdHJ1Y3R1cmUgYW5kIHNwbGl0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVHVlLCBPY3QgMjUsIDIwMTYgYXQgNzoxMyBQTSwgSmltIFJvc2tpbmQgJmx0 OzxhIGhyZWY9Im1haWx0bzpKaW1Sb3NraW5kQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkpp bVJvc2tpbmRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBPY3QgMjQsIDIwMTYgYXQgNToz MSBQTSwgSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCdzIHdvcnRoIG5vdGlu ZyB0aGF0IEJCUiBpcyBvbmx5IGEgY2hhbmdlIHRvIHRoZSBjb25nZXN0aW9uIGNvbnRyb2xsZXIs IC4uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5CQlIgcmVsaWVzIG9uIGdldHRpbmcgZXN0aW1hdGVzIG9mIHRyYW5zaXQgdGlt ZSwgc28gYXMgdG8gZXN0aW1hdGUgdmFyaWF0aW9ucyBpbiBidWZmZXIgc2l6ZXMuJm5ic3A7IEFz IGEgcmVsYXRpdmVseSByb3VnaCBlc3RpbWF0ZSwgSSBiZWxpZXZlIEJCUiBpbiBUQ1AgcmVsaWVz IG9uIHRyYWRpdGlvbmFsLVRDUCBSVFQNCiBjYWxjdWxhdGlvbnMsIHdoaWNoIGluY2x1ZGVzIHRo ZSByb3VuZCB0cmlwIHN1bSBvZiB0cmFuc2l0IHRpbWVzIGluIGJvdGggZGlyZWN0aW9ucy4mbmJz cDsgSSBleHBlY3QgdGhhdCBiZXR0ZXIgb25lLXdheSB0cmFuc2l0IHRpbWUgZXN0aW1hdGVzIGNh biBiZSBoYXJ2ZXN0ZWQgaW4gUVVJQywgYnkgY2hhbmdpbmcgdGhlIGRhdGEgaW5jbHVkZWQgaW4g QUNLIGZyYW1lcyB0byBiZXR0ZXIgaWxsdW1pbmF0ZSB0cmFuc2l0IHRpbWVzIGluIGVhY2ggZGly ZWN0aW9ucw0KIChvciBtb3JlIHByZWNpc2VseSwgaWxsdW1pbmF0ZSBjaGFuZ2VzLCBmcm9tIG9u ZSBwYWNrZXQgdG8gdGhlIG5leHQsIGluIG9uZS13YXkgdHJhbnNpdCB0aW1lcykuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAizwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkNvcnJl Y3QgbWUgaWYgSSdtIHdyb25nLCBidXQgUVVJQyBBQ0sgZnJhbWVzIGFscmVhZHkgaGF2ZSB0aGlz IGluZm9ybWF0aW9uLg0KIFRoZSBjb250YWluIHRoZSBhcnJpdmFsIHRpbWUgb2YgZWFjaCBwYWNr ZXQgYXQgdGhlIHBlZXIsIHdoaWNoIHByb3ZpZGVzIHRoZSBvbmUtd2F5IHRyYW5zZmVyIHRpbWUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+4oCLPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1N1Y2ggbW9kaWZpY2F0 aW9ucyBhcHBlYXIgYXQgZmlyc3QgYmx1c2ggdG8gYmUgbm90YWJseSBsYXJnZXIgdGhhbiBqdXN0 IGEgY2hhbmdlIHRvIHRoZSBjb25nZXN0aW9uIGNvbnRyb2xsZXIuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNpbWlsYXJseSwgSSdkIGV4cGVj dCBtb2RpZmljYXRpb25zIHRvIHN1cHBvcnQgRUNOIGluIFFVSUMgdG8gcnVuIG11Y2ggZGVlcGVy IHRoYW4gYSBjb25nZXN0aW9uIGNvbnRyb2xsZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5KaW0mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpRVUlDIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpRVUlDQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+UVVJQ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWM8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClFVSUMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlFVSUNAaWV0Zi5vcmciPlFVSUNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9xdWljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9xdWljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBXPR07MB351274DBBCBD2FA7655D83BC2AB0DBXPR07MB351eurprd_-- From nobody Wed Oct 26 10:31:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2399B129BF4 for ; Wed, 26 Oct 2016 10:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVe0zy41SbYA for ; Wed, 26 Oct 2016 10:31:00 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1D8129BF0 for ; Wed, 26 Oct 2016 10:31:00 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bzS2U-0007Zw-Ti for quic@ietf.org; Wed, 26 Oct 2016 19:30:59 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bzS2E-0000ww-49 for quic@ietf.org; Wed, 26 Oct 2016 13:30:57 -0400 Received: (qmail 31471 invoked from network); 26 Oct 2016 17:30:40 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Oct 2016 17:30:40 -0000 From: "Christian Huitema" To: "'Ingemar Johansson S'" , "'Ryan Hamilton'" References: In-Reply-To: Date: Wed, 26 Oct 2016 10:30:32 -0700 Message-ID: <01de01d22fae$aae5fd60$00b1f820$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJTvvtNddwsWfPUrqYmx9pI+hNh5gHR9U4MAdLzP4afmrOQMA== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD7uZ KMJk9LiVgPPkshSRLnLde0HWylRewVJRNXBiyUOcdcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdbNYJZHmTztvoh1m9SAwL4/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokd0uMbDf1yoqZkUeJni0+RQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept Archived-At: Cc: 'Ian Swett' , 'Kyle Rose' , 'Spencer Dawkins at IETF' , 'Jim Roskind' , 'marcelo bagnulo braun' , 'Jana Iyengar' , quic@ietf.org Subject: Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 17:31:02 -0000 On Wednesday, October 26, 2016 10:10 AM, Ingemar Johansson wrote: > That was interesting.=20 > I probably need some pen and paper exercise to figure out how good = synchronization > one can get this. If it is within 20-30ms (rough figure) then it can = be useful. Otherwise > it can still be useful as it can help to remedy for instance late = comers advantage and=20 > base-delay inflation issues that is a known problem for LEDBAT. If an implementer really feels ambitious, there is enough information in = the ACK to run an NTP style algorithm and compute skew and lag. That = will drive the precision in the millisecond range. Of course, that's not = really necessary for any practical purpose. The receiver measured ACK = delay is quite sufficient. -- Christian Huitema From nobody Wed Oct 26 13:58:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01080129B27 for ; Wed, 26 Oct 2016 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKSLNkHHGSa3 for ; Wed, 26 Oct 2016 13:58:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913C0129B25 for ; Wed, 26 Oct 2016 13:58:29 -0700 (PDT) Received: from [192.168.3.100] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 92CA822E1FA; Wed, 26 Oct 2016 16:58:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: Date: Thu, 27 Oct 2016 07:58:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> To: Ted Hardie , Brian Trammell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 20:58:32 -0000 Hi Ted, > On 27 Oct. 2016, at 12:52 am, Ted Hardie wrote: >=20 > Howdy, >=20 > Two thoughts: our first working group meeting will be in Asia and our = second in the U.S.--would you like a space in Europe for the interim?=20 We're going to have a broad spread of locations, so we'll get there (and = Jana made the same offer ;) > For remote attendees, will we use meetecho or something else? We don't have details for this yet, but we'll have some way for people = to follow the meeting remotely. Note that actively participating remotely is difficult, and while we'll = try to accommodate it, if you want to actively participate, we strongly = encourage you to be there in person.=20 To Brian's question - the poll is just to give us a rough idea of = people's availability, to make sure that the dates we've got are = reasonable (and to give people some dates to pencil in). We'll do a more = formal registration to get exact numbers and in-person vs. remote later. Cheers, >=20 > best, >=20 > Ted >=20 > On Wed, Oct 26, 2016 at 12:43 AM, Mark Nottingham = wrote: > Everyone, >=20 > We'd like to get our first interim meeting nailed down soon. We have a = host with with what we believe to be a suitable space in Tokyo, Japan on = 24-26 January. >=20 > To make sure that it's suitable for a good portion of the WG, as well = as to assist planning, please fill out this poll to indicate your = availability: > http://doodle.com/poll/ams8q39eecud4zih >=20 > In particular, if you'd like to actively participate but the cannot = make those dates, please indicate that with "Cannot make it." >=20 > We'll have more details soon. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 > Sent from my iPhone > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 26 14:48:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2255129A30 for ; Wed, 26 Oct 2016 14:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvEUSPXXNyOQ for ; Wed, 26 Oct 2016 14:48:20 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3546F1294C4 for ; Wed, 26 Oct 2016 14:48:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 426BAD9316; Wed, 26 Oct 2016 23:48:18 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I1+2vEcmr3Pk; Wed, 26 Oct 2016 23:48:18 +0200 (MEST) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4B597D9314; Wed, 26 Oct 2016 23:48:12 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> Date: Wed, 26 Oct 2016 23:48:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14ADE7BC-E84D-4310-87F0-055096B057E6@tik.ee.ethz.ch> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Brian Trammell , Ted Hardie , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 21:48:22 -0000 Hi Mark, > Am 26.10.2016 um 22:58 schrieb Mark Nottingham : >=20 >> For remote attendees, will we use meetecho or something else? >=20 > We don't have details for this yet, but we'll have some way for people = to follow the meeting remotely. >=20 > Note that actively participating remotely is difficult, and while = we'll try to accommodate it, if you want to actively participate, we = strongly encourage you to be there in person.=20 There is always an IETF Webex or Meetecho available to use, so all you = need is Internet, speakers and a mic or just a phone! Mirja From nobody Wed Oct 26 14:56:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDFE1294AB for ; Wed, 26 Oct 2016 14:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lclllidSp3xg for ; Wed, 26 Oct 2016 14:56:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FA4126D74 for ; Wed, 26 Oct 2016 14:56:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 14AC8D9316; Wed, 26 Oct 2016 23:56:46 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ex8BHvML+avW; Wed, 26 Oct 2016 23:56:45 +0200 (MEST) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C8D39D9314; Wed, 26 Oct 2016 23:56:40 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> Date: Wed, 26 Oct 2016 23:56:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Brian Trammell , Ted Hardie , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 21:56:48 -0000 Hi Mark Agien, > Am 26.10.2016 um 22:58 schrieb Mark Nottingham : >=20 >> Two thoughts: our first working group meeting will be in Asia and = our second in the U.S.--would you like a space in Europe for the = interim?=20 >=20 > We're going to have a broad spread of locations, so we'll get there = (and Jana made the same offer ;) Given we have this standing offer, can we maybe have poll between the = participants where they prefer an interim end of November? Thanks, Mirja= From nobody Wed Oct 26 15:51:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8E129AA3 for ; Wed, 26 Oct 2016 15:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC83lahTbtxA for ; Wed, 26 Oct 2016 15:51:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B94E1295AC for ; Wed, 26 Oct 2016 15:51:43 -0700 (PDT) Received: from [10.227.67.109] (unknown [1.152.55.228]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 75B7B22E1F3; Wed, 26 Oct 2016 18:51:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Mark Nottingham X-Mailer: iPhone Mail (14B72) In-Reply-To: <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> Date: Thu, 27 Oct 2016 09:51:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Cc: Brian Trammell , Ted Hardie , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:51:45 -0000 Hi Mirja, I don't think we have enough lead time for that, and the end of November is g= oing to be a conflict for pretty much all US people.=20 Sent from my iPhone > On 27 Oct. 2016, at 8:56 am, Mirja K=C3=BChlewind wrote: >=20 > Hi Mark Agien, >=20 >>> Am 26.10.2016 um 22:58 schrieb Mark Nottingham : >>>=20 >>> Two thoughts: our first working group meeting will be in Asia and our s= econd in the U.S.--would you like a space in Europe for the interim?=20 >>=20 >> We're going to have a broad spread of locations, so we'll get there (and J= ana made the same offer ;) >=20 > Given we have this standing offer, can we maybe have poll between the part= icipants where they prefer an interim end of November? >=20 > Thanks, > Mirja From nobody Wed Oct 26 15:59:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE96129448 for ; Wed, 26 Oct 2016 15:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUJiwb6SnCQm for ; Wed, 26 Oct 2016 15:59:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6A0129B34 for ; Wed, 26 Oct 2016 15:59:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5676DD9316; Thu, 27 Oct 2016 00:59:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wcf6y9c9tg3l; Thu, 27 Oct 2016 00:59:14 +0200 (MEST) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E02A4D9314; Thu, 27 Oct 2016 00:59:13 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> Date: Thu, 27 Oct 2016 00:59:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Brian Trammell , Ted Hardie , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:59:18 -0000 Sorry, I meant end of January. The point was to ask the participant = where they=E2=80=99d prefer a meeting. Mirja > Am 27.10.2016 um 00:51 schrieb Mark Nottingham : >=20 > Hi Mirja, >=20 > I don't think we have enough lead time for that, and the end of = November is going to be a conflict for pretty much all US people.=20 >=20 > Sent from my iPhone >=20 >> On 27 Oct. 2016, at 8:56 am, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi Mark Agien, >>=20 >>>> Am 26.10.2016 um 22:58 schrieb Mark Nottingham : >>>>=20 >>>> Two thoughts: our first working group meeting will be in Asia and = our second in the U.S.--would you like a space in Europe for the = interim?=20 >>>=20 >>> We're going to have a broad spread of locations, so we'll get there = (and Jana made the same offer ;) >>=20 >> Given we have this standing offer, can we maybe have poll between the = participants where they prefer an interim end of November? >>=20 >> Thanks, >> Mirja >=20 > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic From nobody Wed Oct 26 16:09:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460BD129B38 for ; Wed, 26 Oct 2016 16:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7QDn7BVS2WG for ; Wed, 26 Oct 2016 16:09:36 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276B31295F9 for ; Wed, 26 Oct 2016 16:09:36 -0700 (PDT) Received: from [10.227.67.109] (unknown [1.152.61.4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 029B950A84; Wed, 26 Oct 2016 19:09:33 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Mark Nottingham X-Mailer: iPhone Mail (14B72) In-Reply-To: <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> Date: Thu, 27 Oct 2016 10:09:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Cc: Brian Trammell , Ted Hardie , quic@ietf.org, Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 23:09:38 -0000 I want to see if the arrangements we have are viable first.=20 Sent from my iPhone > On 27 Oct. 2016, at 9:59 am, Mirja K=C3=BChlewind wrote: >=20 > Sorry, I meant end of January. The point was to ask the participant where t= hey=E2=80=99d prefer a meeting. >=20 > Mirja >=20 >=20 >> Am 27.10.2016 um 00:51 schrieb Mark Nottingham : >>=20 >> Hi Mirja, >>=20 >> I don't think we have enough lead time for that, and the end of November i= s going to be a conflict for pretty much all US people.=20 >>=20 >> Sent from my iPhone >>=20 >>> On 27 Oct. 2016, at 8:56 am, Mirja K=C3=BChlewind wrote: >>>=20 >>> Hi Mark Agien, >>>=20 >>>>> Am 26.10.2016 um 22:58 schrieb Mark Nottingham : >>>>>=20 >>>>> Two thoughts: our first working group meeting will be in Asia and our= second in the U.S.--would you like a space in Europe for the interim?=20 >>>>=20 >>>> We're going to have a broad spread of locations, so we'll get there (an= d Jana made the same offer ;) >>>=20 >>> Given we have this standing offer, can we maybe have poll between the pa= rticipants where they prefer an interim end of November? >>>=20 >>> Thanks, >>> Mirja >>=20 >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >=20 From nobody Wed Oct 26 21:10:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237EA129880 for ; Wed, 26 Oct 2016 21:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz9nY_qACQlo for ; Wed, 26 Oct 2016 21:10:15 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB63127071 for ; Wed, 26 Oct 2016 21:10:15 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bzc18-0007ou-0Y for quic@ietf.org; Thu, 27 Oct 2016 06:10:14 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bzc16-00034H-KU for quic@ietf.org; Thu, 27 Oct 2016 00:10:13 -0400 Received: (qmail 12307 invoked from network); 27 Oct 2016 04:10:09 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Oct 2016 04:10:09 -0000 From: "Christian Huitema" To: =?UTF-8?Q?'Mirja_K=C3=BChlewind'?= , "'Mark Nottingham'" References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> In-Reply-To: <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> Date: Wed, 26 Oct 2016 21:10:04 -0700 Message-ID: <031d01d23008$006f6e20$014e4a60$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEuRMSrettxA7brGrb/ATwavpp2fgHiwYMoAhEPnrQBZejL6gIXxFrFAt45/fqhsQiKwA== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDxD/ jCd8YymGeo2s0PE2XKaa9iogUZ+PuZf5Ytzy7XHPdcmtTcWSOKD5RASVzg27inXh5noZfH+Ue/bn p6ZbxyV5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdItI+H292vaf+flnjcpZKBvi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suok3DPIWrP5+rmqhQ+VmxXJXgZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept Archived-At: Cc: 'Brian Trammell' , 'Ted Hardie' , quic@ietf.org, 'Lars Eggert' Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 04:10:18 -0000 > Sorry, I meant end of January. The point was to ask the participant = where they=E2=80=99d prefer a meeting. End of January? Hawaii would be nice. -- Christian Huitema From nobody Wed Oct 26 21:27:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE24B1295CC for ; Wed, 26 Oct 2016 21:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysrBEbJqg9u3 for ; Wed, 26 Oct 2016 21:27:28 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0737E129405 for ; Wed, 26 Oct 2016 21:27:28 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 64so13293129uap.3 for ; Wed, 26 Oct 2016 21:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yEGFs7SKHX/6bUffbvMiGeyMmDeVIuvOXuvUSKYu+UM=; b=CxZRCoBDsVnncvOAqMHCphhDFPnJUHwB4IU56vAltjRCs726GbzFnN9rZ7CFwaSptl s3I8eqmsG9a9gW86BJ38HPSFNolhhRyAlpKWihQ5zOKgjAeDqnCDziDEHLpT+9JUswPU uZGYCTbgqcUXTJdu6z1qAnXb9jzekJdH0JjwJGneJps/SQm2AD0x2rF8oQENV+NcgLew L/Hk2lO42iYu1NDsNN7rncvWeI8NdkrzFUTWFLb8BkY7+nw4Wi2GMMk1+P+SNx7lS0Om S14DA36swNUhM/CpmyJllb8coBtzahZGVyyZ08q3udF7JXo7mWi3xMj2HnQChuh7BR6p CziQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yEGFs7SKHX/6bUffbvMiGeyMmDeVIuvOXuvUSKYu+UM=; b=TyoJj1zIP0/vXql2JiVVkRiuvSq2JITzxGGoojlcNrvFYcPjpCDDjtEG4SOInuIBpl AFVXK/jyKWIDBgtbpjJY2R7v9yuC+Hsh1JqMk5OmImCsyK/6BV6mBAYGWOUWHup1W1sS 38dejXoniceSwXFWF5kKZhZM9bG6pPgBaoWiABdEy2O9B4JhAumwnVYL1tCUl5Yyo2uW cixm77nonAj9AF4jwa9Zbn0NC23X5HKTjf9o+sVNs/AzKCE//MFLfH7L1hGMsAbCZbzA 0ae06uZVBZMFLAjklCEt3t2idL7cXsd+sf9JP8HK6EVX3ok0/f4Twh37ngPKSpbHnb8r 8Ovg== X-Gm-Message-State: ABUngvd8M+lTVVIlyezx1b3YYmIGb/OsIl+yMq1kdwKYJ+7+iCc1WNspiYwiaLsMGIb85ZPwJ3sHAO7a7tTkpSwM X-Received: by 10.176.69.234 with SMTP id u97mr4299809uau.158.1477542446863; Wed, 26 Oct 2016 21:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Wed, 26 Oct 2016 21:27:26 -0700 (PDT) In-Reply-To: <031d01d23008$006f6e20$014e4a60$@huitema.net> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> <031d01d23008$006f6e20$014e4a60$@huitema.net> From: Jana Iyengar Date: Wed, 26 Oct 2016 21:27:26 -0700 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c0d06d0b008d3053fd128a1 Archived-At: Cc: Ted Hardie , Mark Nottingham , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Lars Eggert , Brian Trammell , quic@ietf.org Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 04:27:30 -0000 --94eb2c0d06d0b008d3053fd128a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Following in the path of the IETFs that were conducted in Minneapolis in March, arguably Japan would be more productive :-) Seriously though, I expect that we'll likely have several meetings next year in various locations. Since Japan's being proffered right now by the chairs, it seems reasonable to see if this can work for many active QUIC participants. I'd be interested in seeing remote participation made more workable however. There are many reasons that even active participants may not be able to make it to any proposed location. Visa is just one of these considerations -- it's not the difficulty of getting a visa, the prep and lead time required for it can be debilitating. Folks who are keen to be active ought to be able to remotely participate despite the inconvenient time difference. On Wed, Oct 26, 2016 at 9:10 PM, Christian Huitema wrote: > > Sorry, I meant end of January. The point was to ask the participant > where they=E2=80=99d prefer a meeting. > > End of January? Hawaii would be nice. > > -- Christian Huitema > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --94eb2c0d06d0b008d3053fd128a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following in the path of the IETFs that were conducted in = Minneapolis in March, arguably Japan would be more productive :-)

Se= riously though, I expect that we'll likely have several meetings next y= ear in various locations. Since Japan's being proffered right now by th= e chairs, it seems reasonable to see if this can work for many active QUIC = participants.

I'd be interested in seeing remote par= ticipation made more workable however. There are many reasons that even act= ive participants may not be able to make it to any proposed location. Visa = is just one of these considerations -- =C2=A0it's not the difficulty of= getting a visa, the prep and lead time required for it can be debilitating= . Folks who are keen to be active ought to be able to remotely participate = despite the inconvenient time difference.

On Wed, Oct 26, 2016 at 9:10 PM, Christ= ian Huitema <huitema@huitema.net> wrote:
> Sorry, I meant end of January. The p= oint was to ask the participant where they=E2=80=99d prefer a meeting.

End of January? Hawaii would be nice.

-- Christian Huitema



_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--94eb2c0d06d0b008d3053fd128a1-- From nobody Thu Oct 27 00:54:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D731294A0 for ; Thu, 27 Oct 2016 00:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPnVn65pWbUv for ; Thu, 27 Oct 2016 00:54:00 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9956212946E for ; Thu, 27 Oct 2016 00:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D6EFBD9321; Thu, 27 Oct 2016 09:53:58 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s7KQNEMyhCiG; Thu, 27 Oct 2016 09:53:58 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9A4D2D9316; Thu, 27 Oct 2016 09:53:58 +0200 (MEST) To: Jana Iyengar , Christian Huitema References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> <031d01d23008$006f6e20$014e4a60$@huitema.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <0dad9dcc-1283-3c6b-a467-a10a9eba9cc9@tik.ee.ethz.ch> Date: Thu, 27 Oct 2016 09:53:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Brian Trammell , Mark Nottingham , quic@ietf.org, Lars Eggert , Ted Hardie Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 07:54:04 -0000 Hi Jana, hi Mark, hi all, I personally don't really see a reason to make this a QUIC-around-the-world tour. We should a meeting location where it is most practical for most of the people that want to participate. I can't see who filled the doodle but that would probably give some indication about a suitable meeting location. As we already have some offers, I 'm sure it wouldn't be a problem to find a room in Europe or the US. Further, I think fully interactive remote participation is a must. The IETF provides you WebEx or meetecho, so that shouldn't be a problem. If there is any reason at a certain location that you could use it, it is not the right location. And finally, one question: Do you want people to fill the doodle if they would be able to participate in person on those dates in Tokyo, or would be able to participate on those date but remotely, or when I'm supposed to say yes or no? Mirja On 27.10.2016 06:27, Jana Iyengar wrote: > Following in the path of the IETFs that were conducted in Minneapolis in > March, arguably Japan would be more productive :-) > > Seriously though, I expect that we'll likely have several meetings next year > in various locations. Since Japan's being proffered right now by the chairs, > it seems reasonable to see if this can work for many active QUIC participants. > > I'd be interested in seeing remote participation made more workable however. > There are many reasons that even active participants may not be able to make > it to any proposed location. Visa is just one of these considerations -- > it's not the difficulty of getting a visa, the prep and lead time required > for it can be debilitating. Folks who are keen to be active ought to be able > to remotely participate despite the inconvenient time difference. > > On Wed, Oct 26, 2016 at 9:10 PM, Christian Huitema > wrote: > > > Sorry, I meant end of January. The point was to ask the participant where they’d prefer a meeting. > > End of January? Hawaii would be nice. > > -- Christian Huitema > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > > From nobody Thu Oct 27 00:56:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056411294A0 for ; Thu, 27 Oct 2016 00:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.352 X-Spam-Level: X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87LJqlnVnPqt for ; Thu, 27 Oct 2016 00:56:28 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B044F12946E for ; Thu, 27 Oct 2016 00:56:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,404,1473145200"; d="scan'208";a="153771647" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx144-out.netapp.com with ESMTP; 27 Oct 2016 00:55:09 -0700 Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 00:55:18 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 27 Oct 2016 00:55:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MtoI9uK4BC/9a0JHh4PLZtpP6+L1aursDt03LxZYxj8=; b=ND4cFdEl9t6wWao9zHNeUT9p6U9ldq2ZdYdsBmX19SXmKVnd+se631ilsMVVImbCbXQLd5OYjJJ1tKpOfmBdW9O2G6e2DKegqpnIgsLJlXFvo7mabvj00ZYbxtGSOjpJA+yjZcqSzn9Lv9ndb25N4SKjuwtFgSIdLkUzr53BQA8= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Thu, 27 Oct 2016 07:55:19 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0679.015; Thu, 27 Oct 2016 07:55:19 +0000 From: "Eggert, Lars" To: Jana Iyengar Thread-Topic: [QUIC] First Interim planning -- availability poll Thread-Index: AQHSL1y669Ztym3JIk2EZw/uvQE6vaC6wY8AgAB3CwCAABBIgIAAD1sAgAACKwCAAFbbAIAABNoAgAA6FgA= Date: Thu, 27 Oct 2016 07:55:19 +0000 Message-ID: <88CB250F-6DA3-48CC-81F1-26F6BFF8E35D@netapp.com> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> <65B2FEE9-2CF4-4526-823B-905216897096@mnot.net> <21DE1D15-2C82-42D0-A486-C9C773443B15@tik.ee.ethz.ch> <85A2BDE4-793A-4E47-920F-4EDFF6CA3EE5@mnot.net> <210E0B65-2793-4139-BD19-B63045C30675@tik.ee.ethz.ch> <031d01d23008$006f6e20$014e4a60$@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 265bc9c5-3142-4707-b158-08d3fe3e98e5 x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:0drVsQWaXl1+QGAknZkZzauyJlveFHWKQbSCwqo5G+a+zeme6/i6PPE8UP15dMTbmW/AKVZddMJbgpgUnmj18x+/8bY3ixUGtaJOTZuufb6v+hNqTwZLqPf/aj64dFV9LMGkCYQcM4m8fNGolwunlws/ZmMtEdo1uxCwPGHask8QfyGXo+azcAB1VVg2XOLiqaEEwDgtpEXg8Q7U5cVMGiC0DT9Eujony9Abt33+5+Atf8aEYmyGGNTLf/RjLJt2cFxiFRonYdtcOkCHCpJyDzHW4q1h0NO7Tt6/bxwW4TtvVSEDpNZAapH+eAlXc8i95IoQJQrr2DrdAbFG2uFQYbTtFPs4ZUkmu24tCO7/4WM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6042046)(6043046); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(377424004)(24454002)(8936002)(3280700002)(76176999)(5002640100001)(3660700001)(101416001)(81156014)(81166006)(7846002)(97736004)(5660300001)(50986999)(305945005)(7736002)(86362001)(8676002)(99286002)(36756003)(2906002)(189998001)(92566002)(19580405001)(33656002)(19580395003)(10400500002)(68736007)(122556002)(105586002)(77096005)(50226002)(106356001)(4326007)(93886004)(106116001)(2900100001)(102836003)(3846002)(6116002)(586003)(11100500001)(87936001)(110136003)(82746002)(83716003)(57306001)(2950100002)(6916009)(66066001)(4001150100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 07:55:19.0885 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: Ted Hardie , Mark Nottingham , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Brian Trammell , Christian Huitema , "quic@ietf.org" Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 07:56:30 -0000 Hi, On 2016-10-27, at 6:27, Jana Iyengar wrote: > Seriously though, I expect that we'll likely have several meetings next y= ear in various locations. Since Japan's being proffered right now by the ch= airs, it seems reasonable to see if this can work for many active QUIC part= icipants. this is at least my thinking here as well, and likely Mark's. We're going t= o be having meetings every 2-3 months (at IETFs and interims), and so we're= going to be going places that are inconvenient for some, some of the time.= I'd ask that people trust the chairs to select a reasonable mix of locatio= ns over the coming months. I really do not think it is a productive use of WG time to meeting-plan by = consensus. We're very open to offers to host (and already have received a f= ew off-list - thanks!), and we encourage participants to suggest locations = that are convenient for them where they can offer to host. For this first m= eeting, we have a host at a location that has worked before.=20 > I'd be interested in seeing remote participation made more workable howev= er. There are many reasons that even active participants may not be able to= make it to any proposed location. Visa is just one of these considerations= -- it's not the difficulty of getting a visa, the prep and lead time requ= ired for it can be debilitating. Folks who are keen to be active ought to b= e able to remotely participate despite the inconvenient time difference. Agreed. There are at least Meetecho and Webex available via the IETF, but i= f participants have good experiences with other solutions, we're very open = to use something else. The main issue we'll be facing is likely going to be with the (lack of) A/V= installation at the meeting venue - I expect these interims to be large (>= 50 people) and that's way past where using a single mic and camera is going= to work. So even passive remote participation is likely going to be challe= nge. For active remote participation, add speaker/projector setup into the = mix. if anyone has suggestions for how we can reliably provide a better rem= ote experience, please contact the chairs. (If feels like there should be a= kickstarter for a "remote-meeting-in-a-box" hardware package.) Lars= From nobody Fri Oct 28 21:24:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9086129436 for ; Fri, 28 Oct 2016 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Xmv8mkS9On for ; Fri, 28 Oct 2016 09:50:50 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6E2129598 for ; Fri, 28 Oct 2016 09:50:50 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id z190so93108701qkc.2 for ; Fri, 28 Oct 2016 09:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Pa2t0eZTIzfhZRfG/eD/yPlMl/EKnfZUZtAFRJl+XQ=; b=qEGSXzbfgfZJVG+hOircH8fhCshh9Nz1fMbLjPd2iqWjaC02vi9eVhnm5C+5kTLg/j 3p0sciujUeBK1WC72O5pRRdUI94oztisTd7QQ9cneX9pDogH41HR9EUutQRoQK9kVZEE jOQ1d8OaXH15jxA8M+ceuBXgYihqPptZg1QsdEJJqUR8GbZsHfhFKPX2of1yE+3RrspE EmhyDTiIWFdyWA6ZHCn+oC+Z5uxEv17swSjY+6d0tN15TCr658f1/J5hjVkzgr9aU2Do d79ZIDsKMQbbzLSpWq5RzeWbsFRrJEpcsSZY0+JtKxyCKmxC68SmXHrxMtz9728I4+mM zE6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Pa2t0eZTIzfhZRfG/eD/yPlMl/EKnfZUZtAFRJl+XQ=; b=K8aG1ymPBSRASlCBwi2uSgLqE46mCs0qreIoTzpSN+7injNxgAFblEXr8BCwaa0npy hI3Vk9K8tIhUhQ97XjMwlychUZdPSsaPAaketjeqI30x+UCrkBrffzhx3HhomTsUsquh i+C0p6me6dP4ycj3bfcjcVVwzMJ/7zvKrH4l7iNsuR11puczfWVCxMellt5AOXcKYIqf lcsdO5Dbrad4yOc4GpJJ4+t5a0+jpcxYyP5ZO2A5O63nS5XFpr1LV6TdM9bCn5BzJEnl feM2rJ6blYmVBa/q9wlmTg/zDg19C35axZN4o54fUk6Cqqxa9reJ6cGvDZb1We4u5vDy JdPg== X-Gm-Message-State: ABUngvdAGpwPHc+X8CBRfSh/G9Z2ywyEhqy5FiDkD42JgUqtfUkpyrpdV61Cca6oRO75hvlxWO/zITLH2HRJvw== X-Received: by 10.55.119.132 with SMTP id s126mr11528161qkc.38.1477673449391; Fri, 28 Oct 2016 09:50:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Fri, 28 Oct 2016 09:50:19 -0700 (PDT) In-Reply-To: <01de01d22fae$aae5fd60$00b1f820$@huitema.net> References: <01de01d22fae$aae5fd60$00b1f820$@huitema.net> From: Ted Hardie Date: Fri, 28 Oct 2016 09:50:19 -0700 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c0665c60bb0ac053fefa906 Archived-At: X-Mailman-Approved-At: Fri, 28 Oct 2016 21:24:31 -0700 Cc: Ian Swett , Kyle Rose , Ryan Hamilton , Ingemar Johansson S , Spencer Dawkins at IETF , Jana Iyengar , marcelo bagnulo braun , Jim Roskind , quic@ietf.org Subject: Re: [QUIC] QUIC ACK frames and one-way transfer time (was RE: Drafts structure and split) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 16:50:51 -0000 --94eb2c0665c60bb0ac053fefa906 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2016 at 10:30 AM, Christian Huitema wrote: > On Wednesday, October 26, 2016 10:10 AM, Ingemar Johansson wrote: > > > That was interesting. > > I probably need some pen and paper exercise to figure out how good > synchronization > > one can get this. If it is within 20-30ms (rough figure) then it can be > useful. Otherwise > > it can still be useful as it can help to remedy for instance late comers > advantage and > > base-delay inflation issues that is a known problem for LEDBAT. > > If an implementer really feels ambitious, there is enough information in > the ACK to run an NTP style algorithm and compute skew and lag. That will > drive the precision in the millisecond range. My employer may have IPR that covers this approach. I'm working with our legal folks to get a disclosure filed. Of course, that's not really necessary for any practical purpose. The > receiver measured ACK delay is quite sufficient. > > I agree with this; while there are cases where you might want and need this, I don't really think this is one of them. regards, Ted > -- Christian Huitema > > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --94eb2c0665c60bb0ac053fefa906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 26, 2016 at 10:30 AM, Christian Huitema <hu= itema@huitema.net> wrote:
On Wednesday, October 26, 2016 10:10 AM, Ingemar Johans= son wrote:

> That was interesting.
> I probably need some pen and paper exercise to figure out how good syn= chronization
> one can get this. If it is within 20-30ms (rough figure) then it can b= e useful. Otherwise
> it can still be useful as it can help to remedy for instance late come= rs advantage and
> base-delay inflation issues that is a known problem for LEDBAT.

If an implementer really feels ambitious, there is enough informatio= n in the ACK to run an NTP style algorithm and compute skew and lag. That w= ill drive the precision in the millisecond range.

My employer may have IPR that covers = this approach.=C2=A0 I'm working with our legal folks to get a disclosu= re filed.

Of course, that's not really necessary for any practical purpose. = The receiver measured ACK delay is quite sufficient.


I agree with this; while there are cases where= you might want and need this, I don't really think this is one of them= .

regards,

Ted
=C2=A0
-- Christian Huitema




_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--94eb2c0665c60bb0ac053fefa906--