Re: [quicwg/base-drafts] Persistent congestion interaction with app limited state (#2593)

Subodh Iyengar <notifications@github.com> Fri, 12 April 2019 23:55 UTC

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 9D7A0120447 for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 16:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Level:
X-Spam-Status: No, score=-8.002 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, RCVD_IN_MSPIKE_H2=-0.001, 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 CtNPR8Tl4psN for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 16:55:52 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D99120424 for <quic-issues@ietf.org>; Fri, 12 Apr 2019 16:55:52 -0700 (PDT)
Date: Fri, 12 Apr 2019 16:55:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555113351; bh=2VwD4rU1bk7s+ReUQBfoZTjIOe6UHH6B0IJAk8xD5xA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G1Y0b+nY9KR+lBOKcNjFNxsT9HoEJvW3UyJN556wVOVhPa+S+Hk6OL1rvfSGrTRPZ 9IFcqI1OAcXIxaMaflmReq54E61juDUkvs+10OLJuMPRjCDUJ8b0d8bZwZeM40OoOb s+GYr8EBx/eI3FPMxjP7tq8SEefvxuGtQe/OAMz8=
From: Subodh Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abcf6b01243d51d33a1f2b979ab20069e630ace3d492cebabe580792a169ce19a97bc9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2593/482755911@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2593@github.com>
References: <quicwg/base-drafts/issues/2593@github.com>
Subject: Re: [quicwg/base-drafts] Persistent congestion interaction with app limited state (#2593)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb1258772808_28763fc648ad45b4165282"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: siyengar
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/NTNTdGisAIaI3GjfCTDVmDpeY-g>
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:55:55 -0000

Ya i think that's a decent mitigation there. The text assumes an implementation that keeps the PTO armed even if there is a packet outstanding that does not have new or expired data. In our case we don't arm the timer when there is a packet with no new data. The assumption that the spec makes is that if you have outstanding packets to send you have outstanding data, however we explicitly check whether we have outstanding data to send rather than using outstanding packets as a proxy.

Oh now that you brought up PTO, I'm thinking about what would happen if data was being sent slowly, that is if data is sent just before PTO expires and in response to new requests which are trickling in. Is the intent of persistent congestion here to mark this case as persistent congestion as well?

-- 
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/2593#issuecomment-482755911