Re: Consensus Calls for Late Stage Documents

Tommy Pauly <tpauly@apple.com> Wed, 15 January 2020 22:26 UTC

Return-Path: <tpauly@apple.com>
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 B4C581209DB for <quic@ietfa.amsl.com>; Wed, 15 Jan 2020 14:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 tAo4Ir6trD3r for <quic@ietfa.amsl.com>; Wed, 15 Jan 2020 14:26:01 -0800 (PST)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 6ECFD120992 for <quic@ietf.org>; Wed, 15 Jan 2020 14:26:01 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00FMGw5U019566; Wed, 15 Jan 2020 14:25:55 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=lMzrktXSmdpGKTIFj1+wSw4PJzY5o2KBmyDFxIOwbGw=; b=XgGayeFkILzgKNlf82FZ0+mb2kFydfBxwOXQZ2i3+2eDIyArKKGOTYS5Qcde2AxPdb29 zxjzdk5Xh5PkGYkhIiBtG8/Re1MoJA4xEBWbkfUTWek0luay60kvhpcwyjt5hwhayb4V /5OeiVphkzB2bIk5S+GaWstwktSr4U1+S+txqNVTkh8O1AL96ikaKUyWxKu6Pr/eMTIz ufe3zAgNp69riNTDBuzc/v/SScLVTpylGBmIWkYGs4wt6ndRjqmvGbYy7U5cdUA4oLyF MHtJ1O1noVki6/P17OleRSuWOV3KUlGjVzdviEbXYnmoJZxCe3+FGR0OYW1a0BcUzpPE qg==
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2xfe658ut1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jan 2020 14:25:55 -0800
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4600MQ36B5CX00@ma1-mtap-s03.corp.apple.com>; Wed, 15 Jan 2020 14:25:54 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4600G0060KDM00@nwk-mmpp-sz11.apple.com>; Wed, 15 Jan 2020 14:25:53 -0800 (PST)
X-Va-A:
X-Va-T-CD: a5deab3aa8128cfa8ffecae1f592b6eb
X-Va-E-CD: 19d396bd906248db80241e801e59b99e
X-Va-R-CD: 2b935ab2a48956a4bdee46aba64c1dcc
X-Va-CD: 0
X-Va-ID: 86ad834d-43f0-49ab-b085-7d706969eda6
X-V-A:
X-V-T-CD: a5deab3aa8128cfa8ffecae1f592b6eb
X-V-E-CD: 19d396bd906248db80241e801e59b99e
X-V-R-CD: 2b935ab2a48956a4bdee46aba64c1dcc
X-V-CD: 0
X-V-ID: 2374d2e6-f497-454d-93d0-acd152e4812a
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-15_03:,, signatures=0
Received: from [17.230.161.30] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4600D7K6B20W00@nwk-mmpp-sz11.apple.com>; Wed, 15 Jan 2020 14:25:50 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <02B7142E-B5EF-418F-9F52-0105FD770755@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_41703082-48CF-4906-BF0E-E5ED12EAB6D5"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Subject: Re: Consensus Calls for Late Stage Documents
Date: Wed, 15 Jan 2020 14:25:47 -0800
In-reply-to: <CACpbDccumYO5jmhFbq-MiFtw-zmHn2TpLP+hdeUSskdn5UmDcw@mail.gmail.com>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>, Eric Kinnear <ekinnear@apple.com>, Rui Cunha Paulo <rpaulo@apple.com>, Lars Eggert <lars@eggert.org>, Christoph Paasch <cpaasch@apple.com>
To: Jana Iyengar <jri.ietf@gmail.com>
References: <43D8DACA-C1C4-449A-A4BC-4F0E6F8F1CAB@mnot.net> <247B1759-7D5C-436D-B6C5-BC2AF2479366@apple.com> <CACpbDccumYO5jmhFbq-MiFtw-zmHn2TpLP+hdeUSskdn5UmDcw@mail.gmail.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-15_03:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/azmaAp83cjpX6dj6eOBPUIxFNzg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 22:26:03 -0000


> On Jan 15, 2020, at 2:16 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> 
> Vidhi,
> 
> The current draft already recommends use of a pacer, and your PR 3351 suggests a mechanism that an endpoint can use for doing it. That still doesn't obviate the earlier need to specify a requirement for endpoints that do not implement any pacing.
> 
> Basically, codifying an example pacer does not change the premise of PR 3232 - that implementations might choose to not pace.
> 
> Said differently, even if we were to specify one way of pacing, as PR 3351 does, PR 3232 still applies. I don't think we need to hold off on PR 3232 based on PR 3351.

We can discuss more on the issues/PRs, but one quick note on why we'd like to hold off on merging anything just yet:

In our testing, the specific solution described in #3232 can actually cause some issues with underutilizing the link that are undesirable. Beyond that, it still leaves edge cases open in which burst can still occur, which is the problem originally described in #3094. The new PR is describing another approach to solve #3094.

The main spirit of the new PR is noting that the main problem with non-pacing implementations being too bursty is that the burst limit specified in the pacing section today gives a byte limit, but no time limit. It should be sufficient to specify some bounds on the delay between bursts to solve the problem described in #3094, without locking implementations into a specific congestion-control relationship with the number of ack packets (not just acked bytes as it is today).

Best,
Tommy

> 
> - jana
> 
> On Wed, Jan 15, 2020 at 1:47 PM Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote:
> Hi Mark,
> 
>> * #3094: congestion window increase on every ACKed packet could result in bursty sends
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232 <https://github.com/quicwg/base-drafts/pull/3232>>
> 
> We would like to hold off on this change as we are working on specifying Pacing mechanism which would allow the implementations to decouple congestion window increase from sending rate and thus eliminate the need for 2MSS limit during slow start.
> Below is the PR:
> https://github.com/quicwg/base-drafts/pull/3351 <https://github.com/quicwg/base-drafts/pull/3351>
> 
> I will create a issue to start the discussion.
> 
> Thanks,
> Vidhi
> 
>> On Jan 5, 2020, at 7:56 PM, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> wrote:
>> 
>> Happy New Year, Working Group.
>> 
>> The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). Absent any pushback, we'll direct the editors to incorporate them late next week.
>> 
>> See <https://github.com/quicwg/base-drafts/projects/5 <https://github.com/quicwg/base-drafts/projects/5>> for the current state of issues in the Late Stage process, itself defined at <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>>.
>> 
>> * #3274: Encrypting Retry token
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274 <https://github.com/quicwg/base-drafts/issues/3274>>
>> 
>> * #3247: I am concerned the congestion control text is too permissive.
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248 <https://github.com/quicwg/base-drafts/pull/3248>>
>> 
>> * #3245: Make RFC 6928 normative
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3287 <https://github.com/quicwg/base-drafts/pull/3287>>
>> 
>> * #3244: Can we make a normative ref to  RFC8085?
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3248 <https://github.com/quicwg/base-drafts/pull/3248>>
>> 
>> * #3243: Add caution when using IW10 and fragmentation 
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3280 <https://github.com/quicwg/base-drafts/pull/3280>>
>> 
>> * #3152: Client storage of tokens should be independent of other stored state
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3150 <https://github.com/quicwg/base-drafts/pull/3150>>
>> 
>> * #3142: It is unspecified how a server sends Handshake packets during / after migration
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145 <https://github.com/quicwg/base-drafts/pull/3145>>
>> 
>> * #3094: congestion window increase on every ACKed packet could result in bursty sends
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3232 <https://github.com/quicwg/base-drafts/pull/3232>>
>> 
>> * #3014: Handling of corrupt Retry packets
>>   The proposal is <https://github.com/quicwg/base-drafts/issues/3274 <https://github.com/quicwg/base-drafts/issues/3274>>
>> 
>> * #2863: unrecoverable loss pattern leads to deadlock
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3145 <https://github.com/quicwg/base-drafts/pull/3145>>
>> 
>> * #2789: Use a higher seed RTT for new paths
>>   The proposal is to close with no action.
>> 
>> * #2744: Idle Timer Can Fire Even with Outstanding Data to Send
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3266 <https://github.com/quicwg/base-drafts/pull/3266>>
>> 
>> * #2602: Idle timeout needs more description and a recommendation
>>   The proposal is <https://github.com/quicwg/base-drafts/pull/3099 <https://github.com/quicwg/base-drafts/pull/3099>>
>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>> 
>