Re: [quicwg/base-drafts] Define idle period for congestion control (#2555)

ianswett <> Wed, 10 April 2019 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B529120310 for <>; Wed, 10 Apr 2019 12:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pDk4IBLsd52J for <>; Wed, 10 Apr 2019 12:57:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AAD171201C1 for <>; Wed, 10 Apr 2019 12:57:54 -0700 (PDT)
Date: Wed, 10 Apr 2019 12:57:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1554926273; bh=A+q7kNyANz8WtTkySgLV/Ke3onzA8nz9jDhDDSSSvKU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=La8c/AZuorbJlyM6QUggIB+NXb081HTsIg8TJuV5+RbalXUBXvhZfE/atP+iZEPqG fOSnLGC6+XbB4XvQ9b+rNloQejwSvLTDrECtcaQgZBGa4aKRGMxaiekBCVNTMGFlj+ zFHn/0zk/wQUgLnWr9OvlSnOLZZZhNxvhHt21q58=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2555/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Define idle period for congestion control (#2555)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cae4ac16d7f8_7f5e3fb063cd45bc8301a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 19:57:57 -0000

Your interpretation of RFC5661 looks correct and is different from what's in the QUIC recovery doc.  But the implications are that it's ok to send an unlimited sized burst into the network as long as you only drained the pipe very recently.  I think that recommendation is a poor one unless the window sizes are fairly small(in which case they'd be close to IW10 anyway).

The sender is bursting packets into the network, which previously did not cause loss because they were ack-clocked, but one or more buffers on the network doesn't have enough space for the full CWND.  It seems likely this could cause losses for other flows sharing the link as well.  This could happen frequently in HTTP applications such as DASH video playback.

NewCWV is already referenced for decaying CWND after idle.  I could change the text to say nothing about reducing CWND to IW upon full idle and instead say you shouldn't burst more than IW into the network at once ever, and senders may use pacing, ACK-clocking, and/or timers to accomplish that? may also be relevant to this topic?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: