Re: Re: Greasing more of QUIC

<alexandre.ferrieux@orange.com> Wed, 13 December 2017 16:09 UTC

Return-Path: <alexandre.ferrieux@orange.com>
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 9201412783A for <quic@ietfa.amsl.com>; Wed, 13 Dec 2017 08:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 L12uPZHIFAIS for <quic@ietfa.amsl.com>; Wed, 13 Dec 2017 08:09:07 -0800 (PST)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA671126C0F for <quic@ietf.org>; Wed, 13 Dec 2017 08:09:06 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4AEC1205E4 for <quic@ietf.org>; Wed, 13 Dec 2017 17:09:05 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 2EE371A007B for <quic@ietf.org>; Wed, 13 Dec 2017 17:09:05 +0100 (CET)
Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Dec 2017 17:09:04 +0100
Message-ID: <14936_1513181345_5A3150A1_14936_390_1_5A3150A4.7010700@orange.com>
Date: Wed, 13 Dec 2017 17:09:08 +0100
From: alexandre.ferrieux@orange.com
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0
MIME-Version: 1.0
To: quic@ietf.org
Subject: Re: Re: Greasing more of QUIC
References: <CABkgnnUxr3cAv81m5PfzRb+LWbiUq1qaASMnLkG+hEokHR714A@mail.gmail.com> <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch>
In-Reply-To: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.168.234.6]
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SM-RyriaMa6yw5dA29lSdIZaUPU>
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: Wed, 13 Dec 2017 16:09:09 -0000

Hello Brian,

On -10/01/-28163 20:59, Brian Trammell (IETF) wrote:
>
> [...] what I was hoping I'd see here, and didn't, is an explicit statement of the threat model the greasing we apply
> is meant to counter.

Thanks for focusing on this. I'd like to take this opportunity to chime in with a network operator's perspective on 
these matters.

As it turns out, the generic term "middlebox", which seems to be rather loaded in this context, somehow hides another 
important use case for us: a passive middle observer meant for troubleshooting.

While I agree that all active middleboxes may somehow wreck things in creative though unwilling ways, a passive middle 
observer can do no harm. But the point is that this middle observer is not only harmless, but necessary for the smooth 
operation of the network, which benefits the whole chain: its purpose is simply to locate, as effectively as possible, 
the offending link or piece of equipment, once some problem has been detected end-to-end.

To do so, the most efficient method is dichotomy, which allows to home in on the problem in logN steps for a path of N 
segments, where each steps means (1) installing the middle observer at a chosen point on the path and (2) deciding 
whether the problem happens upstream or downstream from that point.

Clearly step (2) assumes that the measurements done by the middle observer give the upstream/downstream information.
This means that the observable of interest (RTT, loss or reordering) should be available for both upstream and 
downstream segments. This somehow constrains the class of methods that can be designed to support the use case. In this 
respect, the spin bit is satisfactory (since it gives both upstream and downstream RTT estimates), while proposed 
alternatives like packet number echo aren't (since they only yield end-to-end RTTs).

Now, while pondering options like a random key shared by the endpoints, please keep in mind the use case of dichotomic 
troubleshooting, where typically none of the endpoints is under control. You may still impose stateful operation on the 
middle observer though. But don't just kill it.

-Alex

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.