Return-Path: 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 ; 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 ; 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 ; 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 Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 23:41:21 -0000 ----==_mimepart_5c9ffe9e23ac2_20383f94906d45c0966317 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @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 ----==_mimepart_5c9ffe9e23ac2_20383f94906d45c0966317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@janaiyengar you make some good points, but the sender = needs to know which packet to use to create an RTT sample. The obvious a= nswer is the largest ack-eliciting packet number. I can think of some ca= ses 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 s= eems important that ack_delay is from the largest_acked ack-eliciting pac= ket in that case, otherwise the RTT sample will be incorrect. I'm not fe= eling great about the fact we're not explicitly specifying the largest ac= k eliciting packet an instead letting the sender figure it out, but besid= es that this seems ok. I will note that we could also advise not includi= ng 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 si= mpler, 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 co= uld report a max_ack_delay of 0ms and consistently report a larger ack_de= lay 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 mechan= isms incentivize accurate reporting.

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

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub,= or mute the thread.3D""

= ----==_mimepart_5c9ffe9e23ac2_20383f94906d45c0966317--