Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Thu, 21 February 2019 00:41 UTC

Return-Path: <warren@kumari.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BD9130F14 for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 16:41:51 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 o4oGC8_3nr0j for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 16:41:48 -0800 (PST)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 5AB5B130F12 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 16:41:44 -0800 (PST)
Received: by mail-wm1-x336.google.com with SMTP id n19so8456937wmi.1 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 16:41:44 -0800 (PST)
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=YxnSOWVXVjB9Sf4yDc5i+HkrBcH0fOBBuZG5zKDpXps=; b=Gh3mG3TfO2t+cBRVejQyhNLtOOjqFvB38WYiFw2U/xeKdCrzP3onMhHDzcTzzB5e7I e1Qaw37ykbLF+kJNWnQafG7jyDRdJJR/EdUH2NHNkg5CGhrN4OAfsekkPR/YQ+nLthzs XaN0eLz7TfnQwMVEgJGw+ysBCcopbQuWMyFK/RAtFuvEJglL4GPsoIQnzJva0u/Md6ig wZMkCyfcz76Cm6Wdens9GylVpDmdGUlH/dyaUl+IlSNhaz2tTEU1jkkbyIqUhL8nf8eu 6oxGa/f6Cilp8eIw5USXvGX74syTvqstN28FEuUF9BHxstSAWW5nGyNJ4Qz+47/wFa6c 7lcw==
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=YxnSOWVXVjB9Sf4yDc5i+HkrBcH0fOBBuZG5zKDpXps=; b=QuFGWXAlto7h54mkFhMDoanXBDbSjhrCREkOqg7E0JXTWUCPZyVflpWnVktZhBF2HD rxE25/NJZKEdu++8jOaYXxuCI/ZtBsXvMZHyhxVBxQQmHWmhzK9Z7LraU4oMWod46X/c J8sTbqbFSDtE7dBkkuiv3Sc/Fn37N0wlwBcI1FbifU+f9rYJjpe5OSDL2Gxz5xLSGglK dOhtLH4meluWa63wqJRv6DyRbMjy7yqcZj7gY0V5IW8kbsF5C/rUqysi9Udj2WGCis02 3oy+jLglqYDnQ6/uCGK1dDrQ1u+UvKncET6Zx7r0lcMH8mJKseaG4znUg2b+VHAxFC01 Y4SA==
X-Gm-Message-State: AHQUAubkhRXwUDHtfpy01StUh1SZ2EctCsk/1EyXmwJ9tKWielmYYT+F Aw6JtjsN61b5/KLVTgNipuq6OPLFkgxTLoiIhkx+dA==
X-Google-Smtp-Source: AHgI3IZbpxV4w6/kEE9TpJk4K1YSqm/4dKtz+cq3DGufXejuIw+67G6fKyfe9/cKaWZKed2l3wkB6anxtZFlui6U1qo=
X-Received: by 2002:a1c:ce0e:: with SMTP id e14mr8940364wmg.53.1550709702302; Wed, 20 Feb 2019 16:41:42 -0800 (PST)
MIME-Version: 1.0
References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <CE03DB3D7B45C245BCA0D243277949363046559E@MX307CL04.corp.emc.com> <CAHw9_iJeOy=ChEsG2sz3gxKDwNSu_4XT-TtQFKoHYp-z2OLtgg@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363046A1F4@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363046A1F4@MX307CL04.corp.emc.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 20 Feb 2019 16:41:04 -0800
Message-ID: <CAHw9_i+1idzUG6doVcO+_Y3Me_6qPB9Cfb58a+k3ragNw7XvcA@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-tsvwg-le-phb@ietf.org" <draft-ietf-tsvwg-le-phb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f4b17f05825cbc7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-_qW5JIh5LBgV2akV3z6kIUXshM>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 00:41:52 -0000

On Wed, Feb 20, 2019 at 4:34 PM Black, David <David.Black@dell.com> wrote:

> >> Is that explanation reasonable?
>
> >
>
> > More than reasonable — but is it possible to put something in the
> document like that?
>
>
>
> Yes, that would certainly be reasonable ;-).
>

I've cleared my DISCUSS, and will trust y'all to figure something out which
sounds sane.
W



>
>
> Thanks, --David
>
>
>
> *From:* Warren Kumari <warren@kumari.net>
> *Sent:* Wednesday, February 20, 2019 5:32 PM
> *To:* Black, David
> *Cc:* The IESG; draft-ietf-tsvwg-le-phb@ietf.org; tsvwg-chairs@ietf.org;
> tsvwg@ietf.org
> *Subject:* Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09:
> (with DISCUSS and COMMENT)
>
>
>
> [EXTERNAL EMAIL]
>
>
>
>
>
> On Wed, Feb 20, 2019 at 11:28 AM Black, David <David.Black@dell.com>
> wrote:
>
> Hi Warren,
>
> > "An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
> >    traffic nor should packets be "downgraded" to the LE PHB instead of
> >    being dropped, particularly when the packets are unauthorized
> >    traffic.  "
> >
> > Great, sounds good to me -- but in the USA at least, there is are many
> cell
> > phone plans which are "unlimited", but after some amount of traffic
> (e.g., 22GB)
> > your connection gets throttled to a lower data rate. Is this traffic
> still 'a
> > customer's "normal Internet" traffic"? Is it appropriate (whatever that
> means)
> > to downgrade this traffic to the LE PHB? I understand not wanting to
> touch this
> > issue with  a 10 foot pole (and I don't know what the right answer is!),
> but
> > you *did* open this can of worms by talking about what classification
> user
> > traffic should have.
>
> I believe the motivating scenario for this statement in the draft involves
> traffic that exceeds a bandwidth and/or burst limit, as opposed to a total
> data quantity (e.g., monthly) limit.  In particular, it would be bad for
> the tip of a burst spike to be downgraded to the LE PHB in the middle of a
> flow that otherwise uses a different PHB - the flow receiver may not be
> amused by the serious packet reordering that could result.
>
> The scenario described above is different - I would say that traffic that
> exceeds a total data quantity (e.g., monthly) limit SHOULD NOT be
> downgraded to the LE PHB and (as you note) these cell phone plans obtain
> throttling via explicit rate limits.
>
>
>
> Me too!
>
>
>
> The result when the monthly high-rate total data quantity limit is
> exceeded is not LE PHB behavior, because the customer's traffic is
> throttled even if the network has capacity available for that traffic.
> Among the reasons for this operator behavior is to incentivize the customer
> to upgrade, e.g., to a 44GB monthly plan ;-).
>
> So, yes, that throttled traffic is "normal Internet" traffic, which has
> been rate-limited primarily for commercial reasons as opposed to network
> operational reasons.  The traffic remaining after the rate limit is applied
> is not appropriate for the LE PHB, and traffic in excess of the limit
> SHOULD not be downgraded, in order to avoid mixing the LE PHB with other
> PHBs in the same flow.
>
> Is that explanation reasonable?
>
>
>
>
>
> More than reasonable — but is it possible to put something in the document
> like that?
>
>
>
> W
>
>
>
>
>
> > But
> > I think it needs to be mentioned that the provider will need to upgrade
> their
> > monitoring / management system so that they can see the traffic lass. If
> they
> > monitoring circuit utilization using e.g. interface counters (and not by
> traffic
> > class), a link may have 1% "real" traffic and 90% LE traffic, and it
> will look
> > like it is 91% "full". I don't have any suggested text to address this
> (and
> > this is just a comment, so "well, duh, they should know that anyway!" is
> a fine
> > answer.)
>
> I would concur with your suggested answer, as adding support for a PHB in
> a network involves an explicit decision by the network operator - in
> general, see RFC 2475.
>
> Thanks, --David
>
> > -----Original Message-----
> > From: Warren Kumari <warren@kumari.net>
> > Sent: Wednesday, February 20, 2019 12:16 PM
> > To: The IESG
> > Cc: draft-ietf-tsvwg-le-phb@ietf.org; Black, David;
> tsvwg-chairs@ietf.org;
> > Black, David; tsvwg@ietf.org
> > Subject: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with
> > DISCUSS and COMMENT)
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-tsvwg-le-phb-09: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I believe that this should be trivial DISCUSS to address, but I thought
> it
> > important enough to warrant it. I'm OK with basically whatever you
> answer, I
> > just wanted to make sure this had been seen and considered.
> >
> > "An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
> >    traffic nor should packets be "downgraded" to the LE PHB instead of
> >    being dropped, particularly when the packets are unauthorized
> >    traffic.  "
> >
> > Great, sounds good to me -- but in the USA at least, there is are many
> cell
> > phone plans which are "unlimited", but after some amount of traffic
> (e.g., 22GB)
> > your connection gets throttled to a lower data rate. Is this traffic
> still 'a
> > customer's "normal Internet" traffic"? Is it appropriate (whatever that
> means)
> > to downgrade this traffic to the LE PHB? I understand not wanting to
> touch this
> > issue with  a 10 foot pole (and I don't know what the right answer is!),
> but
> > you *did* open this can of worms by talking about what classification
> user
> > traffic should have.
> >
> > Note: I'm happy to clear my DISCUSS no matter what the answer is, I just
> want
> > to make sure it has been considered / discussed.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Major:
> > "Some network providers keep link utilization below 50% to ensure that
> all
> > traffic is forwarded without loss after rerouting caused by a link
> failure
> > (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally
> unused
> > capacity and will be preempted automatically in case of link failure when
> > 100%
> > of the link capacity is required for all other traffic. " Yup - very
> true. But
> > I think it needs to be mentioned that the provider will need to upgrade
> their
> > monitoring / management system so that they can see the traffic lass. If
> they
> > monitoring circuit utilization using e.g interface counters (and not by
> traffic
> > class), a link may have 1% "real" traffic and 90% LE traffic, and it
> will look
> > like it it 91% "full". I don't have any suggested text to address this
> (and
> > this is just a comment, so "well, duh, they should know that anyway!" is
> a
> > fine
> > answer.)
> >
> > Nits:
> > "A main problem is that multicast" -- I'm not sure you can say "A main"
> - main
> > implies singular.; I'd suggest "The main" or "A major".
> >
> > "However,using the Lower Effort PHB for multicast requires to pay
> special" --
> > "requires paying"...
> >
>
> --
>
> 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