IETF Logo Mail Archive

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

ianswett <notifications@github.com> Wed, 10 April 2019 19:23 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 27C11120307 for <quic-issues@ietfa.amsl.com>; Wed, 10 Apr 2019 12:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: 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 1ze7B1Pgj3mQ for <quic-issues@ietfa.amsl.com>; Wed, 10 Apr 2019 12:23:09 -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 6CC52120103 for <quic-issues@ietf.org>; Wed, 10 Apr 2019 12:23:09 -0700 (PDT)
Date: Wed, 10 Apr 2019 12:23:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554924188; bh=KW7CL3E8CPzRshGtM1wHZJi1/n3uH89y9x5Qnw8CFcM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hIWibe140lgt1wqh8fEnyk+NftgfbFcxB79W+hCew4lSti9d+VDK9DfYvVhzO1fGP ONiopIBvnVWv3tJcbCxzWwahGKmqfw48xkEVIo3fCZL7zjLy99SKrouGjfxipaN1Lk KTvyAoWIyTU2bWa5GdV/8mbC1MDlLmZZT13GVMdM=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd8e69d7df659c4ee0a367d746b308a2acc17d8f092cebabb751c92a169ce19a97bc9@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/481827995@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_5cae429c555fc_76083f91d06d45c41478fc"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/OgUWlU3EXDr1uE5p04EqXTcLTBc>
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: Wed, 10 Apr 2019 19:23:11 -0000

There's text on this edge case, but not the interaction with persistent congestion.
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-6.3.2
"When a PTO timer expires, new or previously-sent data may not be
   available to send and packets may still be in flight.  A sender can
   be blocked from sending new data in the future if packets are left in
   flight.  Under these conditions, a sender SHOULD mark any packets
   still in flight as lost.  If a sender wishes to establish delivery of
   packets still in flight, it MAY send an ack-eliciting packet and re-
   arm the PTO timer instead."

I think if you follow either suggestion listed, you shouldn't inadvertently declare persistent congestion from being idle, since in one case you immediately declare packets lost and in the other, you'd only declare persistent congestion if the subsequent PTOs established it?

-- 
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-481827995

v2.13.0 | Report a Bug | By Email