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

[Warren Kumari <[e-mail]>]

On Wed, Feb 20, 2019 at 11:28 AM Black, David <[e-mail]> 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 <[e-mail]>
> > Sent: Wednesday, February 20, 2019 12:16 PM
> > To: The IESG
> > Cc: [e-mail]; Black, David;
> [e-mail];
> > Black, David; [e-mail]
> > 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