Re: Spin bit discussion - where we're at

Roland Zink <roland@zinks.de> Mon, 27 November 2017 19:46 UTC

Return-Path: <roland@zinks.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296611204DA for <quic@ietfa.amsl.com>; Mon, 27 Nov 2017 11:46:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 ch6f-dzwX5SL for <quic@ietfa.amsl.com>; Mon, 27 Nov 2017 11:46:00 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD08F120721 for <quic@ietf.org>; Mon, 27 Nov 2017 11:45:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511811957; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:X-RZG-CLASS-ID: X-RZG-AUTH:Accept-Language:Auto-Submitted:Cc:Date:From:Message-ID: References:Reply-To:Resent-Cc:Resent-Date:Resent-From:Resent-To: Sender:Subject:To:Content-Alternative:Content-Description: Content-Disposition:Content-Duration:Content-Features:Content-ID: Content-Language:Content-Location:Content-MD5: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=knlyto2Ovsnaqg8ahcPFlSgAILveL7Ajn+ydUgL3FQM=; b=OIEzTNNHPHvJERgwqcgzwhSZso81tA6Pa0ABs39LhJwWEjnml7ccE0fOGPMSiMIhwA elzw6aOeLORBLSnOi+qumYV8mLdO3XJuSdc4/Tk+qsuOilPfrUb0YZM4CHl9A/NrRjc8 gw5qTjbxkn9flkDjbm38AHFfIQQdkZTNARq1g=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElTTgmJ6Fg==
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.80] (p57B96C2D.dip0.t-ipconnect.de [87.185.108.45]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id e03071tARJjl44h (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 27 Nov 2017 20:45:47 +0100 (CET)
Subject: Re: Spin bit discussion - where we're at
To: Christian Huitema <huitema@huitema.net>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>, "quic@ietf.org" <quic@ietf.org>
References: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net> <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <fd09b775-4c0e-9d99-e49c-421212f2e5e4@cs.tcd.ie> <F4F7A438-F30F-406B-9971-DA05DA458B44@netapp.com> <C8DDB9E3-C8F9-49CB-8C6D-E381C00AC02D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <CAGD1bZbYjB96nc1ud3xmSm8g6jHhPYpeT=iWWQiZxRzzyVvdRw@mail.gmail.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <DB4PR07MB348CAF067401CD277485464C2250@DB4PR07MB348.eurprd07.prod.outlook.com> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> <bfdad81b-7a16-c779-6281-58c60d491033@huitema.net>
From: Roland Zink <roland@zinks.de>
Message-ID: <118af13a-4aa7-4240-e67a-ba489e524166@zinks.de>
Date: Mon, 27 Nov 2017 20:45:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <bfdad81b-7a16-c779-6281-58c60d491033@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IBQPsQdqeno0AQA9R9vvKaRI0ms>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2017 19:46:02 -0000

I agree it is not only QUIC. I also don't think it is necessary to panic 
now. We have issue #740 
(https://github.com/quicwg/base-drafts/issues/740) about adding a 
security issues section were existing means could be added. When QUIC 
can help to address such issues it can become more reliable so I 
wouldn't say this is out of scope just because other protocols have 
similar issues. If it really turns out that the current mitigations are 
not sufficient then work on better queue management algorithm will 
probably come too late.


Roland



Am 27.11.2017 um 19:02 schrieb Christian Huitema:
> On 11/27/2017 9:36 AM, Roland Zink wrote:
>
>> If QUIC makes the problem crystal clear then now seems to be a good
>> time to solve or mitigate it before risking it becomes a real world
>> problem.
> First, let's start by agreeing that this is not a problem specific QUIC.
> You could say the same about Bit Torrent, any protocol that sends video
> over UDP, or any application that opens multiple TCP connection. So,
> yes, there may well be a problem, but since it is not specific to QUIC
> the mitigation does not have to be specific to QUIC either.
>
> But let's not panic. Practical mitigation has started long ago, with
> ISPs effectively controlling how much data can be sent through a
> customer's up-link. Maybe these current mitigations are not sufficient,
> but if that is the case I would expect more work on better queue
> management algorithm.
>
> -- Christian Huitema
>