IETF Logo Mail Archive

Re: [quicwg/base-drafts] introduce a version alias mechanism (#2573)

Nick Banks <notifications@github.com> Fri, 12 April 2019 14:02 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 9F80F120714 for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 07:02:47 -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, 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 BjKmmkxVhjXm for <quic-issues@ietfa.amsl.com>; Fri, 12 Apr 2019 07:02:45 -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 585BE120712 for <quic-issues@ietf.org>; Fri, 12 Apr 2019 07:02:45 -0700 (PDT)
Date: Fri, 12 Apr 2019 07:02:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1555077764; bh=aIn614OJ/Xc1sapPYZpLn82PV7SQqy/6jeN6mN3daf4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=RoPQ3Bm2CygfjvdEfVjveiVaLPR5ECHPtcg+eBmhC7040gZOdyjSitRaP3s7RUMgB dXXzoTKhySqRuhe6cji0QUDCRVwtMYc88CBlHzumkiqMDWdQFqmfs92yh5v80+G5QI cE5BIkqQ1Xz+X+/2a4cKABZ1uM5hUPEkVq2mIhpI=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab3b6b73b964da7de39f86c3e0c171147abae8acfd92cebabdcd0492a169ce197ad4b9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2573/c482586164@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2573@github.com>
References: <quicwg/base-drafts/pull/2573@github.com>
Subject: Re: [quicwg/base-drafts] introduce a version alias mechanism (#2573)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb09a843875c_7bb43f8b806d45c0484c0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/aVSBaSi2HStm0OP90Y4HM-vDVNg>
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: Fri, 12 Apr 2019 14:02:48 -0000

@marten-seemann I agree that it's possible to coordinate these things, but the DDoS device is meant to be a light-wieght plug-in-play device into the path that can be extremely efficient in getting rid of unwanted traffic, all in hardware. The folks in Azure that own the functionality are extremely hesitant to add any additional complexity there that adds additional points of failure. Any kind of protocol between the backend servers and that box increases the complexity of such a device by an order of magnitude. It will take a lot of time to get such a complete solution in place.

In the mean time, we have to continue to have a solution, beyond the default UDP rate limitting algorithms that exist today. We were considering a simple connection close with server busy error code, but that's not possible with this design. So, the only invariant solution would be a practically empty VN response.

-- 
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/2573#issuecomment-482586164

v2.14.0 | Report a Bug | By Email