Re: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Mon, 27 April 2020 15:30 UTC

Return-Path: <dtikhonov@litespeedtech.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 CB8053A0D2F for <quic@ietfa.amsl.com>; Mon, 27 Apr 2020 08:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 ZHeVLydYoDmL for <quic@ietfa.amsl.com>; Mon, 27 Apr 2020 08:30:04 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720C83A0CE7 for <quic@ietf.org>; Mon, 27 Apr 2020 08:30:04 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id m67so18315291qke.12 for <quic@ietf.org>; Mon, 27 Apr 2020 08:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AvZYx4mQ1lFBKh6DFIb2elv3R6LhCk1QQ13tTf+oLwk=; b=IDD/Dn8vaDrqNrJK17VYxpcl5/M5bGth/KAo3KFMnJaKFc+cE1ZQuOkh2LthKy2q70 G2fL3jIunH8W3GF1vYwgkFi3XlwsAJJ3Fuw9RlxR4ZaONBVcvg31BM+6TAZhtQDvXtmq kF49uWH84IWa81pfuAC3TkWCP7TsRXr0uuHmM7mSyns3Ur+FO1Uq3M5arNDdZIAq4Wen QVVrQG0UQplI5W+tRuREqzAmKPuBMNNJZbQf22HsbWXnljTlM3W9+P75vzyBx3/TXGkw HCVPjaFafsa6qqWtcF7h8/Rw7n/TLEoqqYOzfBjvKHdijjnGwfj4SpKCCgu1+kEM3G+l ISfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=AvZYx4mQ1lFBKh6DFIb2elv3R6LhCk1QQ13tTf+oLwk=; b=kFcB5FmwXYYy/+6ue7b9GWRKParrlh4blowmokWW/wPerQlMkdVEm6cvZUho92vrAD sw6hnbVSDukLqAZVaTSzskWcC0usMd5pkrWZkrytxUR95dXpx4WEciJdpvqWWaoCyvAf 0ZjYtWBfXeOtpfinIgYD33H05nu3uNrBlsi0nUQLTciSyZXYuIIF2FTq5mBfd2Tja6iF naiYPUoV5nBqyUfKv4nr6srGcB1Vzu7NiUUw1kTprjp2hAuc1e6q52YOdcrFJ5HqWHkc AbbFpaIFlRoIU63/Cq4614CiY6Kax+sxFu15OrtsL3NrMWlfJb/D+MAt2GgNE2pmr03P T7/Q==
X-Gm-Message-State: AGi0PuaBINlJEDh35OC6Wvog6j/hh0NZIMXvpG8MwaYOJTaKGkFPDx4d /Yh/UKo46dxc+M7diaqEmWzvtg==
X-Google-Smtp-Source: APiQypIU4UO6Ge4KFuJReBrxzenZoM+1QvMhrCnTuQbI9JWS561O/1rssFpr6EAc0bMZzLrPDaywXQ==
X-Received: by 2002:a05:620a:22ab:: with SMTP id p11mr23438057qkh.373.1588001403329; Mon, 27 Apr 2020 08:30:03 -0700 (PDT)
Received: from lubuntu (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id y72sm10690288qkb.86.2020.04.27.08.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 08:30:02 -0700 (PDT)
Date: Mon, 27 Apr 2020 11:29:58 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: "Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, Ian Swett <ianswett@google.com>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "isabelle.hamchaoui@orange.com" <isabelle.hamchaoui@orange.com>, Riccardo Sisto <riccardo.sisto@polito.it>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "quic@ietf.org" <quic@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, Nilo Massimo <massimo.nilo@telecomitalia.it>
Subject: Re: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)
Message-ID: <20200427152957.GC24088@lubuntu>
Mail-Followup-To: "Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it>, "Lubashev, Igor" <ilubashe@akamai.com>, Ian Swett <ianswett@google.com>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, "isabelle.hamchaoui@orange.com" <isabelle.hamchaoui@orange.com>, Riccardo Sisto <riccardo.sisto@polito.it>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "quic@ietf.org" <quic@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, Nilo Massimo <massimo.nilo@telecomitalia.it>
References: <3ca3b5aae01d4650a3451639268b3f1e@TELMBXD14BA020.telecomitalia.local> <CAKcm_gMEELBizN_h5+s3Ow0LKXEgTRGg+-AqzJMZXVBDwQcDLA@mail.gmail.com> <6b9e74ac94114d28ae4a66f1e9625ebd@usma1ex-dag1mb6.msg.corp.akamai.com> <1587582698016.72632@guest.telecomitalia.it> <20200422200530.GA11856@lubuntu> <1587648443587.63341@guest.telecomitalia.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1587648443587.63341@guest.telecomitalia.it>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/38nl14LwCGejRVWtVYjY33ceKZo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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 Apr 2020 15:30:06 -0000

Hello Fabio,

On Thu, Apr 23, 2020 at 01:27:23PM +0000, Bulgarella Fabio (Guest) wrote:
> > Do you not agree that locating loss source is one of the probe's goals?
> 
> It is more interesting to know if a problem occurs in our domain or
> outside. And this is done by the Qbit (With 2 probes).

Consider the following setup:

    Client ... (OpA) ... (OpB) ... (OpC) ... Server

We are OpB, and Client's and Server's lawyers are banging at our door
with a legally binding SLA signed with our blood.  What do you think is
a realistic way of getting rid of the situation:

    a) Here are captures that prove that loss is in OpC, or in your
       premises, Mr Server.

    b) Here are captures that have no losses in OpA or OpB.  Have a
       good day.

Since a unidirectional QR capture does not include any evidence of
loss downstream, it would be dismissed by the Server lawyers as just
not capturing the right traffic.  An equivalent packet dump with TCP
would include evidence of loss in the form of packet retransmission,
and so would QL scheme.

Simultaneous captures by different organizations are often hard to
coordinate, especially for problems that do not reproduce all the time.
At any given point of the investigation, you depend only on your own
local resources and need to be able to provide evidence that makes sense
to everybody.

> However, it is not uncommon to be able to intercept the whole traffic
> of a connection by observing a single point.  In this case, all the
> necessary measurements can be made.

How common is "not uncommon:" 90%? 50%?  Here is a study that shows how
common symmetric flows are: out of six observations of four different
Internet links, the percentage of symmetric flows was 57%, 7%, 2%, 3%,
2%, and 3%:

  https://www.caida.org/research/traffic-analysis/asymmetry/

The way routing works is asymmetric in essence, as the destination decides
what it announces, which leads to the way to reach it.  When you revert
the arrow, the source cannot but just follow the routes.  The result is
a high prevalence of asymmetric routing.

  - Dmitri.