Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)

ianswett <notifications@github.com> Sat, 30 March 2019 23:41 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 87B51120340 for <quic-issues@ietfa.amsl.com>; Sat, 30 Mar 2019 16:41:21 -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 LeF4ZjrrX864 for <quic-issues@ietfa.amsl.com>; Sat, 30 Mar 2019 16:41:19 -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 458BD12033D for <quic-issues@ietf.org>; Sat, 30 Mar 2019 16:41:19 -0700 (PDT)
Date: Sat, 30 Mar 2019 16:41:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553989278; bh=LX1VGupt9UFEjD6jDI0yc85hcnchZUsfeL4K4gJoy88=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LiDhzS4c5lIwjyox5EAtglmZ7tspwjV3P19xc6cRyDINE/B3/LRp1yxyyjY6uXLEC 3Ppt2RDvuAw84qXEhvHN3x5nDS4LwhNfJ0ue4T+cRLZ/xDMLTCoV+s+M0Kr2Yis1ZK iuV20gGtp8h9KRsypcv32a9DpwcKVTQzgqIP++9k=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab593fcd865bff7697760abc2fb688f843677f12e392cf0000000118b7c09e92a169ce19787a10@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2568/478298803@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2568@github.com>
References: <quicwg/base-drafts/issues/2568@github.com>
Subject: Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c9ffe9e23ac2_20383f94906d45c0966317"; 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/NsKBnHFBHoUQW8IKSj-v7ySTa-o>
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: Sat, 30 Mar 2019 23:41:21 -0000

@janaiyengar you make some good points, but the sender needs to know which packet to use to create an RTT sample.  The obvious answer is the largest ack-eliciting packet number.  I can think of some cases involving ACK loss and/or reordering that would be slightly incorrect, but I can't think of any cases that would be disastrous.  However, it seems important that ack_delay is from the largest_acked ack-eliciting packet in that case, otherwise the RTT sample will be incorrect.  I'm not feeling great about the fact we're not explicitly specifying the largest ack eliciting packet an instead letting the sender figure it out, but besides that this seems ok.  I will note that we could also advise not including non-ack-eliciting packets as the largest acked and only ACK them when they're less than an ack-eliciting packet.   I wonder if that might be simpler, given this is somewhat of an edge case?

@nibanks The reason for limiting ack_delay to max_ack_delay is to incentivize correct reporting of max_ack_delay.  Otherwise, one could report a max_ack_delay of 0ms and consistently report a larger ack_delay value, allowing the receiver to decrease the sender's SRTT.  I'm not sure how large a problem this is in practice, but it's nice if the mechanisms incentivize accurate reporting.

The algorithms should devolve into something very similar to TCP if max_ack_delay is 0ms, so the worst case doesn't seem that bad.

-- 
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/2568#issuecomment-478298803