Re: [quicwg/base-drafts] recovery: clarification on TLP when sender is outpacing the timer (#1718)

MikkelFJ <notifications@github.com> Sat, 01 September 2018 10:03 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 1920D124BE5 for <quic-issues@ietfa.amsl.com>; Sat, 1 Sep 2018 03:03:54 -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 9wNfVD_0cgTw for <quic-issues@ietfa.amsl.com>; Sat, 1 Sep 2018 03:03:52 -0700 (PDT)
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 4564B12426A for <quic-issues@ietf.org>; Sat, 1 Sep 2018 03:03:52 -0700 (PDT)
Date: Sat, 01 Sep 2018 03:03:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535796231; bh=uShyslcgXgGZbfW6efbSIbzTLiE5jwmU4r28h02lL44=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bZCyQP9UzVWYKIr8BDEUAZ8Xx6N3eZgw59/6yb1LzkSyCWFhxDJSw+Erw0Wh/4i/r daT2xwVoUi+hViIBdlmYqweNSiARdtcCaLqx5HHXkQO3IMfnBkKa3RSldYa8Tw64vI 3brZaXDILbQpGJVCz7B6yy2fxmSz9RKLBtpbtRpI=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2df31125549f8e1d8028241d8f81f2d628eb4b5e92cf0000000117a2260792a169ce153af807@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1718/417847899@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1718@github.com>
References: <quicwg/base-drafts/issues/1718@github.com>
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_5b8a640764d15_73243fbb0d8d45c05247a8"; 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: <https://mailarchive.ietf.org/arch/msg/quic-issues/r2B_heCPtaBLM6ZiK9JpmUjANxM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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, 01 Sep 2018 10:03:54 -0000

Mmm - why doesn't RTO fire? If you do not get a timely ACK, you should retransmit? TLP just helps make that happen faster near the end. Retransmit can happen based on gaps in ACK or timeout, or both (from memory, spec keep changing). If you only rely on gap in ACK, then yes, it would not trigger, so that is a bad strategy to use exclusively unless you use an aggressive connection timeout.

I'm not sure the critical loss rate is documented explicitly - but perhaps a section is needed to discuss this further?  In any case, the loss rate is highly application specific because you might operate infiniband where minimal delays a considered critical and any loss unlikely, or you might be on domestic congested wifi with high loss rates, or on a satellite link with large RTT and possible large loss bursts. Loss can also happen from DoS attacks or on path attacks and may have to adjust to circumstances.

If both peers cooperate, a connection close should happen. If not, a timeout happens eventually, and and a stateless reset may happen much earlier when supported and when the path is still viable but the endpoint is not.

-- 
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-417847899