Re: [alto] IESG evaluation results
Martin Duke <martin.h.duke@gmail.com> Mon, 06 December 2021 17:52 UTC
Return-Path: <martin.h.duke@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54163A0CB2 for <alto@ietfa.amsl.com>; Mon, 6 Dec 2021 09:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 By-cHsdn7UR2 for <alto@ietfa.amsl.com>; Mon, 6 Dec 2021 09:52:02 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 D66BF3A02BC for <alto@ietf.org>; Mon, 6 Dec 2021 09:52:01 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id y5so21244738ual.7 for <alto@ietf.org>; Mon, 06 Dec 2021 09:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1t+4nKIftBPalvwK/BtS+cNQzba2EnWF8OBSB7TS+E0=; b=S10lZ0B8hMhTR3x5hxHVIsA584soYi08V3gAVENyjuhASZVgqUSFdeT1yKnYRE0ZXf yzpxYdSeAHOhiT26mqWGqhCy4Qo5TUxLO2uKjkLk5kuVhlFTj2NDyqjr5bnhH+2/mmON 1WhRRidw7PnVDO+QeFuqRpKCv6u7ckk/T4BsG1K/JnTkhU0nSUQ90ouuw064NZ+BsGyb 18ihaM9kPlsNsPGh5SV8oaSdBHA/djuNi0CwNDwd6XmYlANKIoZ5Ll+PxTwFkLPxfm18 PJyUM47eW1AqZ+A+bh0Et2EeA8pJXRjEroAk6NRVLmTh+kNx4sqS3zITfSIJKr5azCio /HJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1t+4nKIftBPalvwK/BtS+cNQzba2EnWF8OBSB7TS+E0=; b=W6qDzO2pV0aTdOnVwX0fdBGhcIT8855ob/RwzHnJGlehhqwAfhW9bXFv4M6Bhx86s0 dHMyw1Uw7xrQ2+zdTp2p4yzBAY874yXyX4JDt+dMClyBgDKbC4G0HbwyHW+dvz03LG0L ZTuplnpG7l7CLcMRj20IwFzHzXRKcVhrBJqATTiHnggvx1OZdaz50UdSm0KVOUmcEEUm /Zdh9jdMuTZw4RqRb57gLm9ICaqyHoLsEu3JuP8N5u3LyOIa7sJDvXFPB0EFaD+BjyET Cs+KnDEKGM63GlIkFoYZKyLnPhD/durnMJxhNTjIA1SCxNqbxrGEUaLrwrPHjvCiuzMS sOwg==
X-Gm-Message-State: AOAM531T6DawArIvHlSQIlR/82O+cWY5Dii58mqNTCfHO0lnEgUnpgf1 qgyP2oz+M77DTchRmJb6NsgRLqbgy3znWhx9Yz+PoSEa
X-Google-Smtp-Source: ABdhPJzJ7oFesMkZelOV7CXZhhO/7eH8vlCv2tEdCWolPU/bk3uKKAE468v/uPUXfSPYMcUusoKZLoX4NnAlCQFo7z4=
X-Received: by 2002:a05:6102:c4d:: with SMTP id y13mr37662197vss.43.1638813120094; Mon, 06 Dec 2021 09:52:00 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxSoY5VgFws9CVbvdKNstKxa+CpXhXh-tztO+QO3LKBxnQ@mail.gmail.com> <CANUuoLq35ZJ5j7g5NXaEPvS0bOXdn8BgwsgjpNG2iBSyRA+XGQ@mail.gmail.com> <CANUuoLrzc5OE4PCK1JizPh25EHZBD1AY1iWjPpOQrf6BLEAhGw@mail.gmail.com>
In-Reply-To: <CANUuoLrzc5OE4PCK1JizPh25EHZBD1AY1iWjPpOQrf6BLEAhGw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 06 Dec 2021 09:51:49 -0800
Message-ID: <CAM4esxQXpwaBPLKGFEnK4UhyHE597mqU9cDsyWZZtCj6d_4=hQ@mail.gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e063bf05d27de997"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/nYMhRLTluPEgXrX31yGm2NdN6d0>
Subject: Re: [alto] IESG evaluation results
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2021 17:52:07 -0000
Hi Richard, Yes, I agree that metric collection is out of scope. However, to the extent that we can import very precise definition (perhaps saying that ALTO servers SHOULD post measurements as close to this definition as possible?) it will save a lot of text and review. On Fri, Dec 3, 2021 at 11:06 AM Y. Richard Yang <yry@cs.yale.edu> wrote: > Hi Martin, > > Add the WG, so that we can hear others' comments as well. Please see below > for a small addition. > > On Fri, Dec 3, 2021 at 1:46 PM Y. Richard Yang <yry@cs.yale.edu> wrote: > >> Martin, >> >> Thanks a lot for the update! A quick reply on performance metrics. >> >> On Fri, Dec 3, 2021 at 1:22 PM Martin Duke <martin.h.duke@gmail.com> >> wrote: >> >>> >>> 2) We will have to do something about performance-metrics. In the >>> telechat, we agreed that metrics collection is out of scope. >>> >> >> Not sure I understand what metrics collection refers to. Could you please >> add a bit of detail? >> >> >>> However, more precise definitions of these metrics are in scope. I would >>> suggest finding RFCs in the ippm WG stream that contain useful definitions >>> and using those. >>> >> >> Going down the path ippm can lead to potential issues. The >> current metrics definitions are more based on deriving path metrics from >> link metrics reported in the routing system (e.g., BGP-LS). This is how >> current deployment (e.g., Flow Director, Lui's team) works and hence is >> proven to be feasible. I do not see that the routing systems will start to >> ask routing devices to measure link properties using ippm measurements, and >> then report using routing protocols. Then conforming to ippm measurement >> metrics can lead to higher deployment barriers. We sure can take a look but >> want to point out the potential problem first. >> >> > Almost all metrics are derived from BGL-LS metrics (RFC8571). Hence, it is > not clear what more precise definitions mean. Does it mean that those > definitions in RFC8571 (which are defined in IGP existing IGP protocols) > are not precise, and hence should not be used (and hence switch to ippm > type of metrics, which specify many more parameters such as traffic > patterns)? Or it means that the performance metric document should just > make a single reference, and the IGP metrics as already defined by IETF are > acceptably "precise". > > Or maybe it is only about the tput metric, and if so, we can discuss it > carefully. > > Thanks a lot, > Richard > > > > > > >> Thanks. >> >> Richard >> >
- [alto] IESG evaluation results Martin Duke
- Re: [alto] IESG evaluation results Y. Richard Yang
- Re: [alto] IESG evaluation results Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
- Re: [alto] IESG evaluation results Martin Duke