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 2BED6130934 for ; Thu, 6 Dec 2018 19:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.46 X-Spam-Level: X-Spam-Status: No, score=-9.46 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] 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 Vf43BY1fEd_n for ; Thu, 6 Dec 2018 19:16:39 -0800 (PST) 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 7A779128DFD for ; Thu, 6 Dec 2018 19:16:39 -0800 (PST) Date: Thu, 06 Dec 2018 19:16:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544152598; bh=HF5VDI0Ba9q1kw9Vt5tzDVlZWz/yG98FmaecgFzzp8Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U+KS6PhfcbGdT/Vh/F/9A+PsY1oZNUpH3dxJ38rSQ9p1V/+2Na0VtCOow48vYmvkx bWlG/P4yDeqP/gJ2U45zW+6Ho7F+KYqESzH4gzbd2vH25yyTkRezDcTBnYuu3BGre2 7iU+ACXilUyiajpVoOUiy5o019D5M07W+yI4cGUI= From: janaiyengar Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Make in_flight the criterion for declaring loss (#2104) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5c09e61685f62_36563ff2186d45bc3137c2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: janaiyengar 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: Fri, 07 Dec 2018 03:16:41 -0000 ----==_mimepart_5c09e61685f62_36563ff2186d45bc3137c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > I think this is an excellent reason to move the text about "Generating Acknowlegements" into transport, because having it in two places increases the chances of inconsistencies. Agreed. It's on my todo for next week. That's about what to do with acking PADDING packets. The question I'm raising is whether loss detection is tied to being in flight or to eliciting an ACK. I'm arguing that loss detection is premised on bytes counting towards in-flight, but loss detection logic triggered by receiving an ACK (which is why we use max_ack_delay in the computations). The bytes being in flight are a necessary condition, not sufficient. Loss detection marks a packet as lost when no ACK is received for it. This is predicated on an ACK being sent by the receiver, delayed or not, if the packet is received, which is only true for ack-eliciting packets. PADDING of ACK-only frames is a weird special case that causes inflight to go up without being ack-eliciting. We had agreed in Montreal that if someone did this they will need to either add a PING frame in there or handle special conditions. -- 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/2104#issuecomment-445109347 ----==_mimepart_5c09e61685f62_36563ff2186d45bc3137c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think this is an excellent reason to move the text about "Generating= Acknowlegements" into transport, because having it in two places increas= es the chances of inconsistencies.

Agreed. It's on my todo for next week.

That's about what to do with acking PADDING packets. The question I'm = raising is whether loss detection is tied to being in flight or to elicit= ing an ACK. I'm arguing that loss detection is premised on bytes counting= towards in-flight, but loss detection logic triggered by receiving an AC= K (which is why we use max_ack_delay in the computations). The bytes bei= ng in flight are a necessary condition, not sufficient.

Loss detection marks a packet as lost when no ACK is received for it. = This is predicated on an ACK being sent by the receiver, delayed or not, = if the packet is received, which is only true for ack-eliciting packets.<= /p>

PADDING of ACK-only frames is a weird special case that causes infligh= t to go up without being ack-eliciting. We had agreed in Montreal that if= someone did this they will need to either add a PING frame in there or h= andle special conditions.

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

= ----==_mimepart_5c09e61685f62_36563ff2186d45bc3137c2--