Re: [quicwg/base-drafts] Persistent congestion pseudocode to match text (#4010)

Kazu Yamamoto <notifications@github.com> Fri, 21 August 2020 20:06 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 5D2B23A1187 for <quic-issues@ietfa.amsl.com>; Fri, 21 Aug 2020 13:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 xm-NU4THmHOf for <quic-issues@ietfa.amsl.com>; Fri, 21 Aug 2020 13:06:42 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA06F3A1186 for <quic-issues@ietf.org>; Fri, 21 Aug 2020 13:06:41 -0700 (PDT)
Received: from github-lowworker-6349a71.ac4-iad.github.net (github-lowworker-6349a71.ac4-iad.github.net [10.52.18.20]) by smtp.github.com (Postfix) with ESMTP id 21F48E0DD4 for <quic-issues@ietf.org>; Fri, 21 Aug 2020 13:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1598040401; bh=Rrtyb+QOWC3zXJhMWYLGsSC2ckdPBMpAs52eupKbuPk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=A6/qkzScRrny3DRnEM2RUUy1s0RWGw/VIJX49dLLvwVhWttzhApp7AEdYdTKw3PcF 8w/AZsVnaBaVP0qSA+camXmL9UVruahqh031KTbfEbtmYtUCYy98d4FxwklxJpo8Sw JmPIX6MfCVSzo3Rp2XjCs6IBwotJ6XU06Jmk3Htw=
Date: Fri, 21 Aug 2020 13:06:41 -0700
From: Kazu Yamamoto <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2F5PXJB6NAWNEZFK55JQFFDEVBNHHCREMQGU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/4010/c678469958@github.com>
In-Reply-To: <quicwg/base-drafts/pull/4010@github.com>
References: <quicwg/base-drafts/pull/4010@github.com>
Subject: Re: [quicwg/base-drafts] Persistent congestion pseudocode to match text (#4010)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f40295112d91_77251964150623"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazu-yamamoto
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/ZNLtm8pZ4gvpIzvbtbT3AM0ZNOw>
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, 21 Aug 2020 20:06:43 -0000

@martinthomson I have implemented this in Haskell quic.

1) With this pseudocode, *global* sequence number (unique and contiguous across the packet number space) is necessary to find the largest contiguity. In Haskell implementation, no additional field is necessary because packet numbers are unique globally.

2) It seems to me that `pc_lost` is over engineering if it is used only to detect persistent congestion. However, this structure can be also used to prevent spurious retransmission due to reordering, pointed out @kazuho. For example, if an endpoint receives ACK 1,3 and then ACK 2, the current pseudo code interprets that packet 2 is lost. If we use `pc_lost` as lost packet candicates and delay the decision, this issue can be resolved. So, we can justify the introduction of `pc_lost`. :-)

3) `pc_lost` consumes much resource because it is cleared only when persistent congestion happens. But, if we use `pc_lost` as lost packet candidates, it should be reduced when retransmission. Since the pseudocode does not describe how retransmission is implemented, we can left how to reduce `pc_lost` as implementation dependent and need not to implement it in this pseudocode.

-- 
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/pull/4010#issuecomment-678469958