IETF Logo Mail Archive

Re: [quicwg/base-drafts] ECN text refers to RTO (#2534)

ianswett <notifications@github.com> Tue, 16 April 2019 15:50 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 E22D8120639 for <quic-issues@ietfa.amsl.com>; Tue, 16 Apr 2019 08:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, 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 RRM-kCqNyvIM for <quic-issues@ietfa.amsl.com>; Tue, 16 Apr 2019 08:50:43 -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 3D73F120490 for <quic-issues@ietf.org>; Tue, 16 Apr 2019 07:26:36 -0700 (PDT)
Date: Tue, 16 Apr 2019 07:26:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555424792; bh=S9jIGmlF+6ST79gq/W0fnN8EtyuvWE3rJCdwbym8lL0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XoJTBTrGpTSjsl0oUQMKTaXHYIEAUCwcPWK7Hr5of1mVQFQMwn/tFT7X23xnu56BU G9+ujQG4Dz/YwKqz+WEClAoJGGjqMUMDjvwb5yP61Au9DEABhb3t8lN4OAdAfhPLJy fvmgUKsJ8sVzkFNtGUdSVOVcLFm38fQ5ZdZU4SuQ=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab14eaf14debd8084d1411eff598043d3a8918d5f992cebac3189892a169ce193d7f3a@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2534/483682698@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2534@github.com>
References: <quicwg/base-drafts/issues/2534@github.com>
Subject: Re: [quicwg/base-drafts] ECN text refers to RTO (#2534)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb5e61864de9_2def3f894dad45c42119f1"; 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/1TCThTW6dIr8VTQS7DytX87pUHY>
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: Tue, 16 Apr 2019 15:50:45 -0000

Fixing the naming(retransmission timeout to probe timeout) is trivial, but I'm not sure what to recommend here for when to disable ECN.  Also, probe timeouts don't occur until the handshake is complete, is that a problem?

One idea that's somewhat in keeping with RFC3168 would be to disable ECN on crypto handshake timeouts and probe timeouts, and if the un-marked packets get through and the marked do not, disable ECN.  But even that is subject to random loss and I believe is likely to spuriously trigger.  We could disable ECN temporarily on only the second timeout, to reduce the chance of spurious disabling?

RFC8311(https://tools.ietf.org/html/rfc8311#section-4.3) says we can do something different from 3168 if we document it, but doesn't specify what.

Is there some useful RFC I can cite that I haven't found, or are we on our own in designing a mechanism here?

-- 
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/2534#issuecomment-483682698

v2.23.0 | Report a Bug | By Email