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

"Bulgarella Fabio (Guest)" <fabio.bulgarella@guest.telecomitalia.it> Thu, 23 April 2020 13:27 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 1C2CB3A041E for <quic@ietfa.amsl.com>; Thu, 23 Apr 2020 06:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mAsEzRLR6tGT for <quic@ietfa.amsl.com>; Thu, 23 Apr 2020 06:27:28 -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 418093A047D for <quic@ietf.org>; Thu, 23 Apr 2020 06:27:27 -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=1587648444; x=2451562044; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=oyNOnNQs80Nrv21bSCogNmV8Z/Zfs3zgNPhRLEBNHpE=; b=SoK3gy9CwZ1SchgD3sfW2HedIfHWBEk+Fgnb7f5jNTiN1wR0nMXcJb8txmu4L7WA 4Wdgb0Dbd2hx5CDFJTbCtgUU9xr6awWCW82dD5nBzkvm6Juiwkcg1CwbmxkLmEof BWAegwliFBvcfWhIatc9KuWm4F7A5w/xsWV7T9Zx8ATUsWnfwXQgtICYjZMcOSe/ fGem2sy7YsBjsiiWFb/SBjqd8R6d+Ja3JOG4uTv+5/zRiS4QGKcmNOe2L0n9wxKA wPs+fPeB1PVwt9lUAm+4Nc0w+/jBsUW+BChpdGnh8ncBM0h7PciwhqXuuLyxFJoK I5rtqTxyIvfZ/p4o7sMsbw==;
X-AuditID: 0a5a2d17-bd5ff70000008b12-64-5ea197bc007f
Received: from TELMBXC06BA020.telecomitalia.local ( [10.90.43.34]) by mx07.telecomitalia.it () with SMTP id AC.58.35602.CB791AE5; Thu, 23 Apr 2020 15:27:24 +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>, 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)
Thread-Topic: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)
Thread-Index: AQHWF/zfNwOq9+2pFU28gxDKDgXEdaiFgojx///ut4CAAT/o4Q==
Date: Thu, 23 Apr 2020 13:27:23 +0000
Message-ID: <1587648443587.63341@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>
In-Reply-To: <20200422200530.GA11856@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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsXCFaWtpLtn+sI4g4ZJ8hbLfshbfJnAZvHz 3k5Wi6aGFcwWPQ/eMVtcOviR3aJnAbfFz9s72R04PCYfWcDssWBTqceSJT+ZPJ5sO87s0fLs JJvH6ZXFAWxRXDYpqTmZZalF+nYJXBlTf/axFCyRrJjbadzAeEeki5GTQ0LAROJ2dw97FyMX h5DAKkaJK9eXAjkcHGwCXhKz7yiDmCIChhL79iaDlDALbGeWaP/8nwWkV1ggTeLB1/mMILaI QLrE0VN9rBC2k8TSz0/AalgEVCU2rVjODGLzClhInN3yH2rXRiaJ6YeaGUEWcAroSnTvDASp YRSQlZiwexHYTGYBcYkX00+wQ9wpILFkz3lmCFtU4uXjf6wQtoHE1qX7WCBsZYnVd66xQvQa SLw/N58ZwtaWWLbwNdQNghInZ0LcJgT0+4eV51gmMIrNQrJuFpL2WUjaZyFpX8DIsopRNLfC wFyvJDUnNTk/N7MkMSczUS+zZBMjOCp1xXcwTtjwRu8QIxMH4yFGCQ5mJRHeDQ/nxQnxpiRW VqUW5ccXleakFh9ilOZgURLn3VW4ME5IID2xJDU7NbUgtQgmy8TBKdXAJFAnMP9sfrT0Mo47 M1e87V3HIT+bOTWi4Owl4/ALS+xnlX/pvSyXe+2Mwsxuje/H2VR8GDQKwmMvHj9/1PPVG98y +Z/FM+ft2G61PfL8fwU7Y6+XG8Pem3+Zemjm/AxmiykeTbcyLiwyTUhYntzFzM0f/FEo35or 80jjJOslfGUN6xzSOtdErTjwXNmhzFz0V9+90nrb/0fr042+Npx/khIfo/jjfc0Jg6X7ZtbG 3F/2YcLe7t3zv7f490XESl/6X3v88xceyVUPruz2eZ30996GpONtC587K4ezLKg8alW0ir1L 2S1hcVU9W4dh0L7L8xN2t65aetr8xW2hNIfUNnsNX51Gw8jsI7l3oqV7lFiKMxINtZiLihMB Cium0DkDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cZBEcjY4EFjGZpx2qCXwkLEbqqg>
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: Thu, 23 Apr 2020 13:27:30 -0000

Hello Dmitri,

> I do not understand this part.  Problems in which protocol
> implementation do you mean -- the loss measurement protocol
> or some other protocol?  If the former, I do not understand
> what you mean by "our portion of code:"  Each implementer will
> write his own code, with his own bugs.

Sorry, I didn't explain this very well. What I meant was that the implementation of our solution is "untied" from the network protocol one.
In QR logic there are no dependencies on internal protocol events (packet declared lost) that can differ in different implementations.
Changes in the network protocol implementation will not require any changes in our logic. The same cannot be said for your solution.

> I already covered this, but I believe it can bear restating:
> Besides loss measurement, a probe should aid to locate the source
> of the loss: upstream or downstream.  A single QR probe cannot do it.
> 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).
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.

Fabio B.


________________________________________
Da: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Inviato: mercoledì 22 aprile 2020 22:05
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)
Oggetto: [EXT] Re: [ippm] New QUIC Packet Loss Measurement (draft-cfb-ippm-spinbit-measurements)

Hello,

On Wed, Apr 22, 2020 at 07:11:38PM +0000, Bulgarella Fabio (Guest) wrote:
> 4. First of all, our solution is not dependent on any specific protocol
> implementation unlike the QL and therefore there shouldn’t be problems
> related to the quality of the implementation. In other words, our
> portion of code is always the same, in every protocol implementation.

I do not understand this part.  Problems in which protocol
implementation do you mean -- the loss measurement protocol
or some other protocol?  If the former, I do not understand
what you mean by "our portion of code:"  Each implementer will
write his own code, with his own bugs.

> Secondly, as anticipated in point 2, by observing only one direction
> we can measure the losses in the operator's domain (Qbit) and the
> end-to-end in the opposite direction (Rbit). So, our solution does work
> also for asymmetric path segments.

I already covered this, but I believe it can bear restating:
Besides loss measurement, a probe should aid to locate the source
of the loss: upstream or downstream.  A single QR probe cannot do it.
Do you not agree that locating loss source is one of the probe's goals?

  - Dmitri.