Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 0DC54120348
 for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 16:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level: 
X-Spam-Status: No, score=-6.597 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_IMAGE_ONLY_28=1.404,
 HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=github.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 DIMSuj_P54va for <quic-issues@ietfa.amsl.com>;
 Fri, 12 Apr 2019 16:48:44 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 69E061201BC
 for <quic-issues@ietf.org>; Fri, 12 Apr 2019 16:48:44 -0700 (PDT)
Date: Fri, 12 Apr 2019 16:48:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1555112923;
 bh=i9wUXbXV82WR0EvPCEepG3ALv/ONcedBkwTvd43EeCk=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=nGRuPWrD5daTOgayl9O9fD/N4mSxRFno7qr2fxOBn2bdrKeysTPISqnwqCNElNpG0
 9un0NemZ0BU8Lq/eLv+hANbE3H6ctpa6xhDV58OI/Eh4AbdWiBUm1KG1n/+1GReLa+
 arS5M78j1nb9nrdTLwkGPq5XNIQvP/X4YUmOQg94=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab93b8b988d6c408d8dd1b33094922589e8e3924df92cebabe565b92a169ce19b58a1d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2604/482754972@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2604@github.com>
References: <quicwg/base-drafts/issues/2604@github.com>
Subject: Re: [quicwg/base-drafts] Pseudocode fix: Data should be sent on
 loss-threshold timer (#2604)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5cb123db6bc21_53af3ffb564d45b852388";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/WYyguSN4dHB9S9CRkMoajLNzakE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG
 <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 23:48:46 -0000


----==_mimepart_5cb123db6bc21_53af3ffb564d45b852388
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Yeah, I realized that we don't really talk about PRR. If we want to bring the entire mechanism here, that might be a bit of work. How about we do as you propose above (without PRR in the comment), add some text about how a sender can implement PRR if they want a smoother way out of recovery with a reference to the PRR draft?

Separately, is it worth filing an issue to do PRR for QUIC? Since we don't assume pacing here, it might actually be useful. It will be some work to do it though. WDYT?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2604#issuecomment-482754972
----==_mimepart_5cb123db6bc21_53af3ffb564d45b852388
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Yeah, I realized that we don't really talk about PRR. If we want to br=
ing the entire mechanism here, that might be a bit of work. How about we =
do as you propose above (without PRR in the comment), add some text about=
 how a sender can implement PRR if they want a smoother way out of recove=
ry with a reference to the PRR draft?</p>
<p>Separately, is it worth filing an issue to do PRR for QUIC? Since we d=
on't assume pacing here, it might actually be useful. It will be some wor=
k to do it though. WDYT?</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/2604#issuecomment-482754972">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqybC=
TApXKB_1hFpUKKuo8WCzoL_Bks5vgRtbgaJpZM4cmOVC">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq63lPzyGs0u5hD8yaIWnaMH5=
eBFxks5vgRtbgaJpZM4cmOVC.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
janaiyengar in #2604: Yeah, I realized that we don't really talk about PR=
R. If we want to bring the entire mechanism here, that might be a bit of =
work. How about we do as you propose above (without PRR in the comment), =
add some text about how a sender can implement PRR if they want a smoothe=
r way out of recovery with a reference to the PRR draft?\r\n\r\nSeparatel=
y, is it worth filing an issue to do PRR for QUIC? Since we don't assume =
pacing here, it might actually be useful. It will be some work to do it t=
hough. WDYT?"}],"action":{"name":"View Issue","url":"https://github.com/q=
uicwg/base-drafts/issues/2604#issuecomment-482754972"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2604#issuecomment=
-482754972",
"url": "https://github.com/quicwg/base-drafts/issues/2604#issuecomment-48=
2754972",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5cb123db6bc21_53af3ffb564d45b852388--

