Re: [quicwg/base-drafts] Handling of duplicate packets (#1405)

Kazuho Oku <notifications@github.com> Fri, 01 June 2018 02:52 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 1AA98126C22 for <quic-issues@ietfa.amsl.com>; Thu, 31 May 2018 19:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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] 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 EgWzUveoAsgc for <quic-issues@ietfa.amsl.com>; Thu, 31 May 2018 19:52:39 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF49126C0F for <quic-issues@ietf.org>; Thu, 31 May 2018 19:52:39 -0700 (PDT)
Date: Thu, 31 May 2018 19:52:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1527821556; bh=CFrTXzAE6sFOlqKAQdzxxMCzs6jXIZF6ZWz11azpVyw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iFETLtGZbrOnPRPfwJ5IG43pq/7opkdxwEsrZ79ZT4cddP6ZZq4P5DSF2AYJ/aOVi hPgdNhx0NbRtPBE8+TlXvE9+zLjT3Pm1aFGLn5dCT0m8qZaXK/aYKHloMOhYI7RVHR bcP/Ew/jDIldAqZtuKZLp7P3mt27/wnJtWXAjmc4=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9fe2952c9bf4b276c9e2ee6ea8da3a6f503a646292cf00000001172876f492a169ce138d6870@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1405/393743048@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1405@github.com>
References: <quicwg/base-drafts/issues/1405@github.com>
Subject: Re: [quicwg/base-drafts] Handling of duplicate packets (#1405)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b10b4f453278_23e03fb0f198cf88225071"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/lN7NBDo0oUd6RdqdnV-PxbcvPAU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 01 Jun 2018 02:52:41 -0000

> The problem with processing ECN before decryption is that you get double-counting if packets are duplicated. And that happens. The ECN PR specifically says that you need to detect and discard duplicates to avoid this.

Yes. I am arguing against that statement, because I do not want to see endpoints being required to detect duplicates.

> Also, the ECN feedback is based on counting of packets sent vs. those that are acknowledged, so counting ECN-marked chaff would inflate and likely distort the signal.
> 
> There is probably a way in which processing ECN signals before decryption could improve signal, but I think that's a different design to what has been proposed.

Exactly.

My argument is based on my opinion that the current proposal is not optimal in sense that it loses the signal that was carried in one of the duplicated packets (one that is being delivered later), while requiring the endpoint to detect duplicates, which IMO is unnecessary.

Consider the case where an endpoint receives two packets that are duplicate, one with the CE bit set and the other one without. The signal sent by the approach used in the PR will depend on the order of the delivery of the two packets. If the packet with the CE bit set is delivered first, the sender will notice more congestion than is should, because the fact that the second packet did not have the CE bit set will not be notified. If the packet without the CE bit set is delivered first, the sender will notice less congestion than it should, because the fact that the second packet did have the CE bit set will not be notified.

The reason why such issue exists is because you process the packet before updating the counter. I am saying that it might be worth reconsidering the approach, _especially if_ we are going to be required to detect duplicates on the endpoint as a byproduct of the approach.

-- 
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/1405#issuecomment-393743048