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 B692B130E28 for ; Sat, 1 Sep 2018 02:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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 vzudz0kewn-1 for ; Sat, 1 Sep 2018 02:44:10 -0700 (PDT) Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2EC12426A for ; Sat, 1 Sep 2018 02:44:10 -0700 (PDT) Date: Sat, 01 Sep 2018 02:44:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535795049; bh=uoI/mG05D6sxyS1W+8ZzKFtQ/7N2bZofo7AuYNqScnk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Kyq4CAvjpDb4HRZIK1sQWcEr7HLYIBVASYccJs2BwsZ8gAf74Zn9s8ztHaau6lxw/ Jf8uAGfvu3QNh0+zNCoqIUZ1g4YlWrQTlcbgxM/kl9/dHh3pm3St4JFtMaeKmRnsfd AYH4BHRjwDZrtmjKtmKo3N+eVUg0thih6Qc/YurE= From: MikkelFJ Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] recovery: clarification on TLP when sender is outpacing the timer (#1718) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5b8a5f691d5a4_7fe83f9ddf8d45c0276695"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: mikkelfj 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.27 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, 01 Sep 2018 09:44:12 -0000 ----==_mimepart_5b8a5f691d5a4_7fe83f9ddf8d45c0276695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As I understand it, the TLP is there to ensure the receiver sees something that it can ACK, in case a packet is lost. If you keep sending ACK'able content that problem never occurs, and it is fair that the timer is not triggered. TLP is not meant to detect that the peer closed the connection but rather that the sender stopped sending (hence tail loss probe), possibly close to connection close, but not necessarily. If you keep missing ACK's another trigger sets in: you loss rate gets too high and you close the connection. There is ongoing discussions about negoatiating how an ACK can be delayed. https://github.com/quicwg/base-drafts/pull/1715#pullrequestreview-151076864 dead path dection: https://github.com/quicwg/base-drafts/issues/1638 -- 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/1718#issuecomment-417846905 ----==_mimepart_5b8a5f691d5a4_7fe83f9ddf8d45c0276695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

As I understand it, the TLP is there to ensure the receiver sees somet= hing that it can ACK, in case a packet is lost. If you keep sending ACK'a= ble content that problem never occurs, and it is fair that the timer is n= ot triggered.

TLP is not meant to detect that the peer closed the connection but rat= her that the sender stopped sending (hence tail loss probe), possibly clo= se to connection close, but not necessarily.

If you keep missing ACK's another trigger sets in: you loss rate gets = too high and you close the connection. There is ongoing discussions about= negoatiating how an ACK can be delayed.

#1715 (review)

dead path dection:
#1638

&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_5b8a5f691d5a4_7fe83f9ddf8d45c0276695--