Re: [bmwg] [Technical Errata Reported] RFC8239 (5652)

Warren Kumari <warren@kumari.net> Tue, 06 August 2019 16:02 UTC

Return-Path: <warren@kumari.net>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BFC120401 for <bmwg@ietfa.amsl.com>; Tue, 6 Aug 2019 09:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 o8W7VwX3DG23 for <bmwg@ietfa.amsl.com>; Tue, 6 Aug 2019 09:02:00 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 09D831203D5 for <bmwg@ietf.org>; Tue, 6 Aug 2019 09:01:52 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id l9so84993145qtu.6 for <bmwg@ietf.org>; Tue, 06 Aug 2019 09:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b8x6r1bov3Fuc5p22iIJuR6vnSRBVGG+EelGFNsPlbs=; b=jTaeuTf5rrKDvQgpuRd5fwbuJuj6G9IKza6uBzLfWaw+R4Lf46hz9yUUJjJstQp8kj JgY501+XhkezHrelWGHYtxzQ4Ok/ChdDFLNm5kL52M0AY3vorBYWO/uijymhFAVKgATT 1YtHKRPCQpCpr3xdO1CKPthWgii0fN4vZhhpRworhSXJAlb5JtpzZK3uGWJgDNFC8lKK 1ufqfWgItCowVDhc7P55wkyKM937/UdBBvuIidudncT3huu8lpoKzB3OvR4aRRdtR2+S B02HDA6rbbxWjWFmc6bKS2VD9pcxGU8OZEzPfUDtepKCJGm0IsVSRpFxSPzea04t5HQy 9TZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b8x6r1bov3Fuc5p22iIJuR6vnSRBVGG+EelGFNsPlbs=; b=n9EcFKVkzNrphle2g5ls0dyzgzbvBot/kiscEiyi9opgOqBLBL9xrq99+HHOpjSq6u tl2WC/F0BDqmaSypNi+/nZfQl750N6xM0QECHHoZuMx4CKARhi52sBW+v5+VuJoZ5Aed kd0DgPUjfOZmgA/20H4PZHk6I+HeoClXGwsxf4qf1JEg+WdjDs75caXjsoJgEml5KTiM eyAydZfah/KI2gt7pRUmIBjp79oKFJTMfiJJepO9P/1ZThcrucnMJpRWHhgDPtS/eyEi KT94IEmlzXs9uQvIA+PegS437LK1o6IG69oKxHEwOaFfCQNIRpntK+0zwmBRl8kOU3L6 1ycA==
X-Gm-Message-State: APjAAAXMxKQoeewN/Mlbfq5iD9oA05Oeu0XTkd1drswFM/c6VNmVLiv2 4JQQXboFEHwB5SLx/HkpyeDta9rHS3z0+tUWeQ4Dyw==
X-Google-Smtp-Source: APXvYqwDid7s9ikY27L9x9Vy1BvpDWWMGSNS3B/4oCyigKv3XSoUIO3IHCjY2AhYf0Aa85uL/4bE9T21+EcWorypBaU=
X-Received: by 2002:aed:2068:: with SMTP id 95mr3636258qta.265.1565107310795; Tue, 06 Aug 2019 09:01:50 -0700 (PDT)
MIME-Version: 1.0
References: <20190312142436.DFB42B82A82@rfc-editor.org> <4D7F4AD313D3FC43A053B309F97543CF6C003A8D@njmtexg5.research.att.com> <CALccSYcocYn0LeLWPQQb_vQc29Vi565Q0Ypxnh+pcPD2RXKC0A@mail.gmail.com> <CAHw9_iJxJtnkOTm7dUDBdp_sbL2XbdMKVayu2K_VH6DOrZBCMQ@mail.gmail.com>
In-Reply-To: <CAHw9_iJxJtnkOTm7dUDBdp_sbL2XbdMKVayu2K_VH6DOrZBCMQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 06 Aug 2019 12:01:14 -0400
Message-ID: <CAHw9_i+CsL2dbVJ_Qv865FvowS_6EGLM=eYxgSCf3u7K-ueo1A@mail.gmail.com>
To: "Jacob H. Rapp" <jhrapp@gmail.com>
Cc: "MORTON, ALFRED C (AL)" <acm@research.att.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "lucien.avramov@gmail.com" <lucien.avramov@gmail.com>, "ibagdona@gmail.com" <ibagdona@gmail.com>, "sbanks@encrypted.net" <sbanks@encrypted.net>, "nmalykh@ieee.org" <nmalykh@ieee.org>, "bmwg@ietf.org" <bmwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/xlWWrV9Kq4nM51PijU18431Qj5M>
Subject: Re: [bmwg] [Technical Errata Reported] RFC8239 (5652)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 16:02:10 -0000

On Mon, Jul 1, 2019 at 4:57 PM Warren Kumari <warren@kumari.net> wrote:
>
> On Wed, Mar 13, 2019 at 3:31 PM Jacob H. Rapp <jhrapp@gmail.com> wrote:
> >
> > Thanks Al. Lucien and I are reviewing and will provide feedback soon.
> >
>
> Hi there,
>
> Any progress? This errata is still open, and I'm trying to clean up
> the Ops side of errata...

Any update?
I'm likely to just approve the errata if not.
W

>
> W
>
>
> > thanks,
> >
> > --
> > Jacob
> >
> > On Tue, Mar 12, 2019 at 10:45 AM MORTON, ALFRED C (AL) <acm@research.att.com> wrote:
> >>
> >> Authors,
> >>
> >> In a quick review, the proposed change appears to
> >> concentrate the oversubscription traffic at the
> >> N-1 egress port.
> >>
> >> Another fix could be (changing the first designation of the egress port,
> >> and highlighting that there are both ingress and egress port N here):
> >>
> >> OLD
> >>        o  Last iteration: Ingress port N-2 sending line rate to egress
> >>           port N-1, while port N is sending a known low amount of ...
> >> Suggest
> >>        o  Last iteration: Ingress port N-2 sending line rate to egress
> >>           port N, while ingress port N is sending a known low amount of ...
> >>
> >> But there is some adaptation needed from previous steps because
> >> N is the *last* port, so the egress port N should be tested in the
> >> last iteration, AFAICT.
> >>
> >> Let us know what you think.
> >> Al
> >>
> >> > -----Original Message-----
> >> > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> >> > Sent: Tuesday, March 12, 2019 10:25 AM
> >> > To: lucien.avramov@gmail.com; jhrapp@gmail.com; ibagdona@gmail.com;
> >> > warren@kumari.net; MORTON, ALFRED C (AL) <acm@research.att.com>;
> >> > sbanks@encrypted.net
> >> > Cc: nmalykh@ieee.org; bmwg@ietf.org; rfc-editor@rfc-editor.org
> >> > Subject: [Technical Errata Reported] RFC8239 (5652)
> >> >
> >> > The following errata report has been submitted for RFC8239,
> >> > "Data Center Benchmarking Methodology".
> >> >
> >> > --------------------------------------
> >> > You may review the report below and at:
> >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
> >> > 2Deditor.org_errata_eid5652&d=DwIBaQ&c=LFYZ-
> >> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=LxASF7NaQP_D9pzHXIbGJ6hUXBu5E
> >> > beKiJwvXf1ur84&s=JISNNUf8r8-ZwJkApM9cfoP8T-V2OoAYCvcNSiyymmA&e=
> >> >
> >> > --------------------------------------
> >> > Type: Technical
> >> > Reported by: Nikolai Malykh <nmalykh@ieee.org>
> >> >
> >> > Section: 3.2
> >> >
> >> > Original Text
> >> > -------------
> >> >       o  Last iteration: Ingress port N-2 sending line rate to egress
> >> >          port N-1, while port N is sending a known low amount of
> >> >          oversubscription traffic (1% recommended) with the same packet
> >> >          size to egress port N.  Measure the buffer size value by
> >> >          multiplying the number of extra frames sent by the frame size.
> >> >
> >> >
> >> > Corrected Text
> >> > --------------
> >> >       o  Last iteration: Ingress port N-2 sending line rate to egress
> >> >          port N-1, while port N is sending a known low amount of
> >> >          oversubscription traffic (1% recommended) with the same packet
> >> >          size to egress port N-1.  Measure the buffer size value by
> >> >          multiplying the number of extra frames sent by the frame size.
> >> >
> >> >
> >> > Notes
> >> > -----
> >> > Incorrect number of the output port for oversubscription traffic.
> >> >
> >> > Instructions:
> >> > -------------
> >> > This erratum is currently posted as "Reported". If necessary, please
> >> > use "Reply All" to discuss whether it should be verified or
> >> > rejected. When a decision is reached, the verifying party
> >> > can log in to change the status and edit the report, if necessary.
> >> >
> >> > --------------------------------------
> >> > RFC8239 (draft-ietf-bmwg-dcbench-methodology-18)
> >> > --------------------------------------
> >> > Title               : Data Center Benchmarking Methodology
> >> > Publication Date    : August 2017
> >> > Author(s)           : L. Avramov, J. Rapp
> >> > Category            : INFORMATIONAL
> >> > Source              : Benchmarking Methodology
> >> > Area                : Operations and Management
> >> > Stream              : IETF
> >> > Verifying Party     : IESG
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf