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

Jana Iyengar <jri.ietf@gmail.com> Tue, 13 November 2018 07:00 UTC

Return-Path: <jri.ietf@gmail.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 7EC4C128CF3 for <tcpm@ietfa.amsl.com>; Mon, 12 Nov 2018 23:00:52 -0800 (PST)
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 uyjnomSWRn4T for <tcpm@ietfa.amsl.com>; Mon, 12 Nov 2018 23:00:48 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 E9E18130DC1 for <tcpm@ietf.org>; Mon, 12 Nov 2018 23:00:47 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id t9-v6so9849456ljh.6 for <tcpm@ietf.org>; Mon, 12 Nov 2018 23:00:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kzPOztQsxYDhmXgz7t/FB72Iplab8jCk9HpVwAjn0Uw=; b=caP4eceMU83EW4oLnYBQGMPPQZvlMQSWta/iTXhZOiLqDyuqzH/39vj0zrsp4ptavx cCAIuvB1zFrXAJgdZhHaKisPUXlIqs/bllkiu6Q3JoumFzUM85JtPxNzRxrUF2MSHK8a UhGTm5bp9OJnSkC8fh9/93Xtg+euHwSH36Ox36TmT3LC9kA4hQ/8d9KBUSHOeQndztoc hWdBub4PjL4yF+KScuwIh/3XWqe+lGspLS72i15bxWZt3ArxFKQvncbXDxLDZy4DEkhp JavOMkCtdRjKG/Ht8uJnyGDZ/nmdIvbZFedblwqsNhqbLzgMwWLrPpYjbNghghFscGvv SlVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kzPOztQsxYDhmXgz7t/FB72Iplab8jCk9HpVwAjn0Uw=; b=HDor+nz34sZZ59t5RTffYbblaHcl0ieUahEjySAOr+wWgrueprAUuaSlI6l38IF4uX iGb4VH4qHHh73hChlC0ZODavfl2NltniPV/rjnYoyFoim3ol0WWDz1YVPL+pPOYaWuJv OvAg1eW0o70aBGS7Um+p7VDa21NKFTwGMFiLdCXUTnyyi7lNlRZttG5jaE/uQANqd0Fa pFVCWmJNgnOl0hd87tqCQ1AAzwf0tAULTDBnncibkb9jjY7Mvx9EQszs1Yh29BJPYNCS MfK92XgPWqL036vW6moVtgjh/sL34zDr2tu+NGblw7UX9z3T2R7A0Qu/M5hye8LI1Q0A gMoA==
X-Gm-Message-State: AGRZ1gIcOwCY53kqAeIQl18skJEf4Zu720qLuYITeKW2QuIwHrckLYHN byy7tgzcBJQ2D2kFC7SBPBvE2p7cgeegxMhskls=
X-Google-Smtp-Source: AJdET5dYkAjqfmys/fwvEeejbMIfjShluLdYpqjqjEXddQ8siAPZkiEgtD99tyta2RwDHG2IORuzoKtBdPzaRiw4EJU=
X-Received: by 2002:a2e:6c04:: with SMTP id h4-v6mr2303914ljc.92.1542092446034; Mon, 12 Nov 2018 23:00:46 -0800 (PST)
MIME-Version: 1.0
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> <CAK6E8=eAfBMNrCsCLexg2fWxb2dOVOSeFPV81pFPaz+3TdyHsA@mail.gmail.com> <MW2PR2101MB1049420039F3E1C96A885A9EB6C10@MW2PR2101MB1049.namprd21.prod.outlook.com>
In-Reply-To: <MW2PR2101MB1049420039F3E1C96A885A9EB6C10@MW2PR2101MB1049.namprd21.prod.outlook.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Tue, 13 Nov 2018 14:00:34 +0700
Message-ID: <CACpbDceZHEaXQ=PvVH7ScC8CFYZbd7sHCxfEUkYy3-VApbUzsQ@mail.gmail.com>
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Yuchung Cheng <ycheng@google.com>, Bob Briscoe <ietf@bobbriscoe.net>, Ian Swett <ianswett@google.com>, tcpm@ietf.org
Content-Type: multipart/alternative; boundary="00000000000074f0a5057a86601b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oPxovMVk_fICUiXkU-Xse0OiFwE>
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: Tue, 13 Nov 2018 07:00:52 -0000

Praveen,

I think that's a deployment configuration question... you're right to note
that BBR requires pacing, but I don't think the solution here is
necessarily to build pacing into the transport. It's certainly useful to
build it in as a safeguard in case the deployment environment does not
implement pacing, but I think it still is useful to describe and implement
controllers for environments that implement pacing.

- jana


On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian <
pravb@microsoft.com> wrote:

> Yuchung this might be worth experimenting with and getting more data on.
> Maybe there should be some reaction to an unconfirmed RTO even if it is not
> reduction all the way to LW? I like Jana's suggestion that the
> implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacing.
>
> I checked the latest draft and pacing is a RECOMMENDED. I am noticing that
> transport algorithms in Linux and in QUIC are evolving assuming pacing
> which is a function usually implemented and configured outside of the
> transport. So the transport is potentially making an assumption which may
> result in safety issues. For example BBR congestion control may not work
> very well if pacing was disabled or misconfigured? I don’t know of any
> robust solution to this other than build pacing into the transport itself.
> Pacing is also very challenging for low latency flows because of lack of
> support for fine grained timers.
>
> -----Original Message-----
> From: Yuchung Cheng <ycheng@google.com>
> Sent: Monday, November 12, 2018 8:37 AM
> To: Jana Iyengar <jri.ietf@gmail.com>
> Cc: Praveen Balasubramanian <pravb@microsoft.com>om>; Bob Briscoe <
> ietf@bobbriscoe.net>gt;; Ian Swett <ianswett@google.com>om>; tcpm@ietf.org
> Extensions <tcpm@ietf.org>
> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
>
> 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%2Fbob
> >> > briscoe.net%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7C3c4d22866
> >> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> >> > 7C636776374678321324&amp;sdata=T%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee
> >> > buPcuMYlVhgDY%3D&amp;reserved=0
> >> >
> >> > _______________________________________________
> >> > tcpm mailing list
> >> > tcpm@ietf.org
> >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >> > w.i
> >> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40micr
> >> > oso
> >> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7
> >> > cd0
> >> > 11db47%7C1%7C0%7C636773207316711149&amp;sdata=K667a3IQG4rarQ%2FOfAl
> >> > yhK
> >> > 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%40micro
> >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7
> >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=33WxKh5c6qL4ln5jerpx
> >> Rhytfrj1iTK284pEqv5fWKY%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%40micro
> >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7
> >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=33WxKh5c6qL4ln5jerpx
> >> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=0
>