Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)

Kazuho Oku <notifications@github.com> Fri, 30 November 2018 02:49 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 6D9AF12D4E7 for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 18:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Level:
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 GvI00EEmj1HW for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 18:49:04 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8683D12896A for <quic-issues@ietf.org>; Thu, 29 Nov 2018 18:49:04 -0800 (PST)
Date: Thu, 29 Nov 2018 18:49:03 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543546143; bh=zS1xntEq4o7yZwsfBseLxgRG4+Pnd1F3Ib2yMffrHwI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gRqzg34wQKXD2gdf+kBcHbsRAE8S20+sR8P3djj45ct7ZBq1BchEYCOoZeoi8TcGc /5itX0KCUm1V3wDqsHTsSDqhSnS3NHfeDw1dHxRqzhUB6icieAG0qf8QtsxeMZZgN0 1waYKs22uufvV7M4y24vfqRB7OXawn5MfCBqNgX0=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdf0fb3872e00451c1486a025882ed721b90046e492cf000000011818671f92a169ce16f4226e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2060/443072299@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2060@github.com>
References: <quicwg/base-drafts/issues/2060@github.com>
Subject: Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c00a51f5e309_73043fa4a9cd45b4187659"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/1Ec3VvrmU8qYVduVckdFwK-rdbw>
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, 30 Nov 2018 02:49:07 -0000

> If there is a high rate of ACK loss or if the peer's alarms are persistently waking up late, then the SRTT and/or RTTVar will increase, thereby increasing these timers. If this happens very infrequently, then the EWMA will forget them relatively quickly. I think that seems appropriate?

I had not thought about that, and admittedly I am unfamiliar with loss recovery, however I wonder if that's appropriate.

IIUC, the reason we use X * SRTT where X is slightly greater than one is because we expect an ACK to arrive in SRTT with some jitter.

However, in case of ACK loss, the SRTT using the computation would become too large for the case where there is no loss, or too small for the case where there *is* a loss. For eaxmaple, in the case of having ACK loss at 33%, SRTT becomes 33% greater than the RTT. I am not sure if that is a desirable behavior.

If we can assume that ACK loss happens infrequently, IMO the correct thing to do would be to ignore the effect of ACK retransmissions.

![loss - 1](https://user-images.githubusercontent.com/41567/49265498-a5935200-f495-11e8-85e4-e2d394d9e1e1.jpg)

-- 
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/2060#issuecomment-443072299