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

"Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it> Mon, 01 June 2020 09:47 UTC

Return-Path: <fabio.bulgarella@guest.telecomitalia.it>
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 4287F3A0EBB for <quic@ietfa.amsl.com>; Mon, 1 Jun 2020 02:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=guest.telecomitalia.it
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 2RcRkm6IvbNF for <quic@ietfa.amsl.com>; Mon, 1 Jun 2020 02:47:07 -0700 (PDT)
Received: from mx07.telecomitalia.it (mx07.telecomitalia.it [156.54.232.23]) (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 301D33A0EBC for <quic@ietf.org>; Mon, 1 Jun 2020 02:47:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=guest.telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@guest.telecomitalia.it; t=1591004823; x=2454918423; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=WdrKefF1sfz8oL6fyB1MusvTFNs9WLVwDa23ojcNjG4=; b=My7ONUuTVJowjuoZnPonisHhK7AMHK4e7rzFxk27sz4ng4CSpXl6VvQxeLxDLxMZ JXiAl0NXrOQSpfuEfx5zt0x3cOUxAksAwM8dmqm7jqyEOHRZelcRBpFr/I81Bn0h mjHmmCwWJydLMaC+9ydTmA3wfQRmqZWFXnnKMqOHBgE27w2GxvPSjBh9bEuZRmy/ pWE0bWtWIk6hRrvz8Z5Hp/Zx9ekdVNG5IyUre13WObpMlrwNOn78FvNwuc+x0H/o CIfOMlOKYhKUaeIj7K6GC5MizKz4fih/gaUIGs9V0YmHxeISTjH78Adi7NRMUC5u klkxJlQgksJkfkWPUIPAYw==;
X-AuditID: 0a5a2d17-4a7ff700000048f6-cf-5ed4ce969b6e
Received: from TELMBXC12BA020.telecomitalia.local ( [10.90.43.46]) by mx07.telecomitalia.it () with SMTP id 54.87.18678.69EC4DE5; Mon, 1 Jun 2020 11:47:03 +0200 (CEST)
From: "Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it>
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
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>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "quic@ietf.org" <quic@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, Marcus Ihlar <marcus.ihlar@ericsson.com>
Subject: Re: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)
Thread-Topic: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)
Thread-Index: AQHWF/zfNwOq9+2pFU28gxDKDgXEdaiFgojx///ut4CAAT/o4YAGTsMAgDbA/14=
Date: Mon, 1 Jun 2020 09:47:01 +0000
Message-ID: <1591004822041.41433@guest.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>, <20200427152957.GC24088@lubuntu>
In-Reply-To: <20200427152957.GC24088@lubuntu>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [188.219.222.222]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsXCFaWtpzv93JU4g+fHmCyW/ZC3+DKBzeLn vZ2sFk0NK5gteh68Y7a4dPAju8XBl69YLXoWcDtweEw+soDZ49fXq2weCzaVeixZ8pPJ48m2 48weLc9OsgWwRXHZpKTmZJalFunbJXBlTHscXLDNuGL7o4lMDYwbNbsYOTkkBEwkvh5dzdLF yMUhJLCKUWLK7ofsXYwcHGwCXhKz7yiDmCIChhL79iaDlDALtDBLzD19kxmkV1ggTeLB1/mM ILaIQLrE0VN9rBD1fhI/FvGAhFkEVCROT3gFVs4rYCHxdhpIOciqRmaJGU2v2EASnAK6Ertu XWUCsRkFZCUm7F4ENpNZQFzixfQT7BB3Ckgs2XOeGcIWlXj5+B8rhG0gsXXpPhYIW1li9Z1r rBC9ehI3pk5hg7C1JZYtfA11hKDEyZlPwOqFgH7/sPIcywRGsVlI1s1C0j4LSfssJO0LGFlW MYrmVhiY65Wk5qQm5+dmliTmZCbqZZZsYgTHpa74DsYJG97oHWJk4mA8xCjBwawkwjtZ/VKc EG9KYmVValF+fFFpTmrxIUZpDhYlcV63A1fihATSE0tSs1NTC1KLYLJMHJxSDUySLo+iP161 Sd43TYRZ/AaHaXB9rsjdtLLENlehaYf8TGfWld06zaKVt9p2za8l0z6562wT0b2fwdK1QPC+ k+jGZIYnNy8c5Chn3dtVo1S35cV6+dnzJB9PkKxR8WzKFFFm/3Bm8o+LG8I+Tty8TzbxceL8 dTyFN48LPLTy1Qrr7G+Z7L7RRdv03v9sXs/025NlIl8f5vm8e/O+C1X71zcKVHrP+Odn5l50 m49l6Vz5REbNR71ZKrO3lm/6PrGBweLauVt7mX78Mq4PK2dZyLdztza31z7bEuFPS5eIbVkX OP+gtT73iePTy415XW5nFf58qOulXru0K9v17Nr9P0KmSR3aVrrnYl9+3ZZvTJpKLMUZiYZa zEXFiQDf1bqwOgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4WVPycDvA6uIxdrPNorhsPT5MzM>
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, 01 Jun 2020 09:47:11 -0000

Hello Dmitri,
sorry for the late reply. We have just replied to Igor concerns in a previous mail proposing a comparison session.
Our proposal is to implement both solutions on a common implementation of the QUIC protocol so that the same data flow can be marked using both techniques (i.e., Qbit, Rbit and Lbit - borrowing the third most significant bit occupied by the spinbit) and analyzed using the two observers.
Let us know what you think, thanks.

Here, just few thoughts about your last considerations.


> 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.


Regarding this point, with respect to a signed SLA, we believe that there are no big differences between asserting that the problem is not in our domain or asserting that the problem is outside our domain. In any case, your system is still unable to locate the leak outside your domain: you cannot say if it is in the OpC or in any other operator in the queue (unless you call OpC and ask for place a probe in their domain).  Furthermore, referring to your example, considering that the OpC also does not experience any problems, with the QR method we can measure E2E on the opposite side without having a probe physically placed on that side. So you have more information to use in the event of a legal dispute.


> 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.


If observation is possible on both sides, both the QL and QR methods work best. If, on the other hand, only one direction can be observed, each of the two solutions has its pros and cons: you see everything on the observed side but you are totally blind on the opposite side. We only see our domain on the side under observation and also E2E on the opposite side. What is better? Any contribution in this sense from the working groups is welcome.


Best regards,
Fabio B.



________________________________________
Da: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Inviato: lunedì 27 aprile 2020 17:29
A: Bulgarella Fabio (Guest)
Cc: Lubashev, Igor; Ian Swett; Cociglio Mauro; isabelle.hamchaoui@orange.com; Riccardo Sisto; alexandre.ferrieux@orange.com; quic@ietf.org; IETF IPPM WG (ippm@ietf.org); Nilo Massimo
Oggetto: Re: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)

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.