Re: [tcpm] Thank you for the QUIC session in tcpm

Yuchung Cheng <ycheng@google.com> Mon, 12 November 2018 16:37 UTC

Return-Path: <ycheng@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6412F1AC for <tcpm@ietfa.amsl.com>; Mon, 12 Nov 2018 08:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Rkf5cgca5UEg for <tcpm@ietfa.amsl.com>; Mon, 12 Nov 2018 08:37:46 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 19B3C12426A for <tcpm@ietf.org>; Mon, 12 Nov 2018 08:37:46 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id k141-v6so14072839itk.3 for <tcpm@ietf.org>; Mon, 12 Nov 2018 08:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZwpgOaO3j9EPsJGGwYUmM4EZuUKJJjLUdrLqk1BQX1E=; b=I7Ljs+oMk2ohXequPTyNFz45EhlWZaXb+0rrHTP5ZlzeR1IB3VIFRki8H7NkgnbVaz 6JmpzziVXHcwzgGfeV2c+zRo/az0zzQnBfFsjlNPuQnI3sIMmFksamTx1fTuttcg6eig m+AZ5zAW7THxRo8NWXeWzENt3k1KXbcDhcxGTKY8F887tzfegPTWyvL9ouz8FESpB4bm TkQyBfK9e77xpGb7HdH60jhS5JkxN5uO3/MTfvzwQw2ZWge01ZUgl1FWEHvE7wDPx5b7 eC4ynwXcOcIREIK7enz+9ATeJGReSeqfVA+oElftrDjevJ74x5Xjp1mRHnUFVKaXIpHA BoZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZwpgOaO3j9EPsJGGwYUmM4EZuUKJJjLUdrLqk1BQX1E=; b=iIifrB5VraXvuTQnFy3ZRsiln4sQ6+BPjIYI/bkm4Phx4/aF0B5wvToLw2oONIpTxP OLE6Equ8e+R/tELUh/pko7QXpAHpx0j7Nj9h8cO/+ouv3YwhYRhchX5spFMNE3JEVc4O CbRZU393aJ7nLS/kCVkIqNtLsfe0/A7yXLgT3Y3yQwebZLdIQbEgB/SLuF5BY1hOIDxL mI1enFHVXWzKaosiOrwgsTopER8cszz972/oZ/FKGeklMR+V4V1JRZk6e8vKb1ToMKmq +xXtgHE1lu83j/MJjyNbNz3AjXfJTUi8cNyK0kwMynm0kJ0I/42JqHCZ1O8HQky8TbMs CxJQ==
X-Gm-Message-State: AGRZ1gLVrcOjtdsnCvjnQC766+JbccysaM19VM7BwbtLzyspmPPS+b5Y 0NsNFfUVlQp9EE57TTv/CAbYwJQVF8pj/GDSqyMiFA==
X-Google-Smtp-Source: AJdET5eLV02QZLzmqCj63tkfp5fMBzUdPnTkuuiRn2N/FbUi8D7zPoI3tkonK/ucedjw8g1B8VSOHktPJcXcs2cLJLc=
X-Received: by 2002:a02:3b54:: with SMTP id i20-v6mr1458753jaf.17.1542040665019; Mon, 12 Nov 2018 08:37:45 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a5e:8515:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 08:37:03 -0800 (PST)
In-Reply-To: <CACpbDcfcxZBo6A_9yjefhedUWTFe0Ce2eZxyFFa8zvscTRtAKg@mail.gmail.com>
References: <dddc426c-b7e0-8446-d236-71bdba4010fe@bobbriscoe.net> <CAK6E8=eEQM++TqAS+wLWCwFbXuNcbRZV6Nnewz1+6nWhnfAuQQ@mail.gmail.com> <MW2PR2101MB1049AD006A7311CBB7D9D072B6C60@MW2PR2101MB1049.namprd21.prod.outlook.com> <CACpbDcfcxZBo6A_9yjefhedUWTFe0Ce2eZxyFFa8zvscTRtAKg@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 12 Nov 2018 08:37:03 -0800
Message-ID: <CAK6E8=eAfBMNrCsCLexg2fWxb2dOVOSeFPV81pFPaz+3TdyHsA@mail.gmail.com>
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ian Swett <ianswett@google.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ccqYbNvC_Yi4K-qy-vuYbw5oeU4>
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2018 16:37:48 -0000

On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> Praveen,
>
> The point you're raising -- that we've lost the ack clock after an RTO -- is
> a reasonable point. My argument is that with pacing, cwnd reduction is
> unwarranted because in the extreme case, this collapses to restart after
> idle, where sending at cwnd with pacing is reasonable
I agree w/ Jana as well - the most generic way to treat burst due to
prior_inflight << cwnd is pacing. With QUIC's approach, when RTO
fires, cwnd remains unchanged until the ACK of the first
retransmission (i.e. a probe packet) comes back. Therefore the delay
is one RTT and the potential damage is an additional cwnd-worth of
burst.

Yes the worst case is more aggressive, and it can be too much for DC
incast case if pacing isn't supported - one idea is to selective
enable that if RTT variance is
very large vs RTT.

>
> The draft does not say that a sender should reduce the cwnd if it is not
> pacing, which we should add. Does that make sense?
>
> - jana
>
> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian
> <pravb=40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Yuchung I brought that difference up in an email to the quic wg earlier
>> this week.
>>
>> In app send limited case, inflight could be very small compared to cwnd.
>> So in QUIC there is potential to send a burst out after a long idle period
>> (with outstanding data) where TCP wouldn't. The draft claims this is okay to
>> do because RTO may have been a result of RTT increase instead of loss. Is
>> there data to suggest on which side we should err? i.e. data on what are the
>> chances that an RTO is due to an RTT increase versus loss.
>>
>> Do you see any safety concerns with delayed reduction of cwnd in case
>> where the RTO is not spurious?
>>
>> -----Original Message-----
>> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
>> Sent: Thursday, November 8, 2018 4:38 PM
>> To: Bob Briscoe <ietf@bobbriscoe.net>
>> Cc: Ian Swett <ianswett@google.com>om>; tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
>>
>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>> >
>> > I just wanted to thank Jana for explaining QUIC loss recovery to us (and
>> > QUIC CC as far as it goes).
>> > And thank you Jana, Ian, the chairs of both WGs (and anyone else
>> > involved) for setting it up.
>> >
>> > If one is not full-time on QUIC, it's very difficult to keep up with all
>> > the changes. But now we have a checkpoint to start from, I feel I will not
>> > be wasting people's time if I try to get involved - at least I only might
>> > say something un-QUIC occasionally, rather than nearly always. This has
>> > allowed people who understand how TCP cold be improved to help with QUIC,
>> > when working on QUIC isn't their day job.
>> >
>> > Again, Thank you.
>> I like particularly that QUIC only reduces cwnd to 1 after the loss is
>> confirmed not upon RTO fires. It should be very feasible for TCP (at least
>> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions!
>>
>> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids.
>> Google internally uses usec. We wish we could upstream it but RFC needs to
>> be updated.
>>
>> >
>> >
>> > Bob
>> >
>> >
>> > --
>> > ________________________________________________________________
>> > Bob Briscoe
>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbobbriscoe.net%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773207316711149&amp;sdata=0pt6YfpYOaF%2B5IWEKY3LMj1idEnYbApqUvWzhtLa5qE%3D&amp;reserved=0
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.org
>> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
>> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microso
>> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd0
>> > 11db47%7C1%7C0%7C636773207316711149&amp;sdata=K667a3IQG4rarQ%2FOfAlyhK
>> > QQ05Cea421rgb64DlEMvs%3D&amp;reserved=0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773207316711149&amp;sdata=K667a3IQG4rarQ%2FOfAlyhKQQ05Cea421rgb64DlEMvs%3D&amp;reserved=0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm