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

[Brian E Carpenter <[e-mail]>]

I agree with David, and I'll add one other point.

LE is a bit unusual in the diffserv model, in that logically it is
*only* the source node that can definitely know that traffic is of low
importance. So it simply makes no sense for a router later on the
path to re-classify a packet as LE; it can't have that knowledge.
That is rather different from other cases, such as router identifying
VOIP traffic and re-classifying it as EF.

    Brian
On 2019-02-21 08:27, Black, David 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.  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?
> 
>> 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"...
>>
>