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

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

Deborah,

On 2019-02-23 06:14, BRUNGARD, DEBORAH A wrote:
>> The main idea is that applications/users decide what traffic should go to the "background", i.e., which packet are marked as LE (end-to-end argument as hint: the >network lacks usually the application knowledge).
> 
> I'll take the opportunity to jump in here😊
> 
> This was my comment, I was confused, as there's a couple of places in this document which infer much more than previous RFCs on what a "user" can do vs. what a network operator can do. In my comment, I noted the sentence:
> 
> "However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
> remarked to LE on a regular basis without consent or knowledge of the user."
> 
> I scanned other RFCs, I don't see this requirement that an operator needs to have the consent/knowledge of the user before remarking? Suggest simply dropping the "without consent..." from the sentence.
> 
> And the sentence in the abstract "Ideally, applications mark their packets as LE traffic, since they know the urgency of flows." You answered Warren "The main idea is that applications/users decide what traffic should go to the "background", i.e., which packet are marked as LE (end-to-end argument..". This is very confusing as it contradicts other RFCs where marking/re-markings are tools for a network operator. It directly contradicts RFC8325/section 5.4:

You are quite right. This is an unusual type of traffic compared with the general model for diffserv, where it's assumed that traffic can be re-classified at domain boundaries by some form of (possibly deep) packet inspection. In fact, only a sending host can know for sure that traffic is LE by nature.

So, downgrading any traffic to LE would seem to be always wrong. (Upgrading LE to BE would be less wrong but still might defeat the sender's intention.) IMHO deleting the "consent/knowledge" clause would be reasonable.

    Brian

> "An alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy.  This option is RECOMMENDED over mapping, as this typically is the most secure solution because the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the developer of the operating system of the wireless endpoint device, who may be functioning completely independently of the network administrator)."
> 
> I recognize this RFC maintains "no harm" saying "There is no incentive for DS domains to distrust this initial marking, because letting LE traffic enter a DS domain causes no harm.  Thus, any policing such as limiting the rate of LE traffic is not necessary at the DS boundary." I'm a bit nervous on that assumption, I think most operators would agree with Warren's title, "hysterical raisins"😊 Can IETF really maintain (this is PS), "no worries"?
> 
> Thanks,
> Deborah
> 
> 
> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Bless, Roland (TM)
> Sent: Thursday, February 21, 2019 10:04 AM
> To: Warren Kumari <[e-mail]>; The IESG <[e-mail]>
> Cc: David Black <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
> 
> Hi Warren,
> 
> Am 20.02.19 um 18:16 schrieb Warren Kumari:
>> ----------------------------------------------------------------------
>> 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.  "
> 
> This was actually directly copied from RFC 3662.
> 
>> 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.
> 
> The main idea is that applications/users decide what traffic should go to the "background", i.e., which packet are marked as LE (end-to-end argument as hint: the network lacks usually the application knowledge).
> Operators must have good reasons to deliberately downgrade users' normal traffic. In case of throttled traffic, this would still be considered as being normal BE traffic. One case for downgrading BE traffic could be non-admitted multicast replication traffic as described in RFC 3754.
> 
>> ----------------------------------------------------------------------
>> 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.)
> 
> Thanks for the hint, valid point, but indeed: if they use Diffserv, they should also monitor the resource shares for each PHB individually.
> 
>> 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".
> 
> Right.
> 
>> "However,using the Lower Effort PHB for multicast requires to pay 
>> special" -- "requires paying"...
> 
> Done.
> 
> Regards
>  Roland
>