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

[Spencer Dawkins at IETF <[e-mail]>]

So, just to follow up,

On Mon, Feb 25, 2019 at 2:48 AM <[e-mail]> wrote:

> Deborah, Warren,
>
> IETF doesn't specify SLAs or related text, I agree. The LE performance is
> worse than default forwarding. I'm unhappy if my peer demotes my traffic to
> LE and points to an IETF standard allowing this.  What about:
>
> DISCUSSED CHANGE so far:
> Non-LE traffic (e.g., BE traffic) SHOULD NOT be
> remarked to LE on a regular basis.
>
> SOMEWHAT MORE PRECISELY DEFINED OPTION
> Non-LE traffic (e.g., BE traffic) MUST NOT be
> remarked to LE by default.
>
> I'd like to avoid LE to result in a "default below default" and prefer
> IETF standards not allow fancy interpretations.
>

This document was approved on the last telechat, but we're having a
Discuss-level discussion about it now, which means that I should be taking
this conversation very seriously (because "new technical objections are
always in order").

Am I understanding that

   - Deborah (and, IIRC, Warren) are thinking that MUST is the wrong
   answer, because we don't tell operators how to mark traffic in their
   networks, but
   - Ruediger is thinking that SHOULD is the wrong answer, because that
   allows LE to be a "default below default"?

Let's start and see if I got that right.

Spencer


> Regards,
>
> Ruediger
>
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <[e-mail]> Im Auftrag von BRUNGARD, DEBORAH A
> Gesendet: Samstag, 23. Februar 2019 17:33
> An: Roland Bless <[e-mail]>; Warren Kumari <[e-mail]>;
> The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [tsvwg] Warren Kumari's Discuss on
> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>
> Hi Roland,
>
> On your comment:
> "In former times P2P file sharing traffic was throttled by some ISPs
> without telling the users. The danger is that the same thing happens with
> remarking traffic as LE, so IMHO the user should be informed at least that
> traffic is downgraded. Maybe consent is too strong, so I propose to delete
> "consent", but stay with "without knowledge of the user" or I will rephrase
> it accordingly. However, it's still a SHOULD NOT only."
>
> I can not comment on what some ISPs do and what is in their service
> contracts. I am fine with this as a "SHOULD NOT". I am not fine with saying
> anything about what a service operator needs to do regarding a service
> contract. IETF hasn't in the past made these statements (btw - ITU-T does
> not touch this either). Hint: I don't think pointing to this RFC will help
> you.
>
> As Brian suggested, just keep the first part of the sentence.
>
> Thanks!
> Deborah
>
>
> -----Original Message-----
> From: Roland Bless <[e-mail]>
> Sent: Saturday, February 23, 2019 6:30 AM
> To: BRUNGARD, DEBORAH A <[e-mail]>; Warren Kumari <[e-mail]>;
> The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Warren Kumari's Discuss on
> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
>
> Hi Deborah,
>
> On 22.02.19 at 18: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:
>
> Sorry, for causing confusion :-)
> I was trying to answer the IESG comments one by one and didn't arrive at
> yours yet, so I also jump in.
>
> > "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.
>
> Your impression is probably right that this is not really consistent,
> because some of the text stems from RFC 3662 and some was added within this
> I-D.
> At the time of RFC 3662, the view was probably more toward: LE is mainly a
> tool for network operators.
> Yes, it is, but it's also a different question _who_ is actually deciding
> what traffic is classified as LE. In the light of net neutrality debates,
> it would be fair if the user classifies its traffic as LE if it is eligible
> and I find it reasonable that providers should be transparent: if they use
> LE as tool and downgrade users' traffic, they should say so, e.g., inform
> the user that they downgrade under certain conditions.
>
> In former times P2P file sharing traffic was throttled by some ISPs
> without telling the users. The danger is that the same thing happens with
> remarking traffic as LE, so IMHO the user should be informed at least that
> traffic is downgraded. Maybe consent is too strong, so I propose to delete
> "consent", but stay with "without knowledge of the user" or I will rephrase
> it accordingly. However, it's still a SHOULD NOT only.
>
> > 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.
>
> Besides the net-neutrality argument, the e2e argument is another good
> reason to only let user decide, what should go into this class. The user
> cannot harm the network this way, so there is no reason for the Diffserv
> domain to distrust this marking coming from the end-system.
> For other Diffserv PHBs this IS different, because they are elevated
> services (i.e., better than best-effort): a Diffserv domain should either
> do the initial marking or at least apply policing at the ingress boundary
> nodes - otherwise QoS guarantees may be at risk; here the markings from
> end-systems cannot be trusted at least policing is required that may
> include re-marking. So for the EF PHB for example, admission control and
> policing are essential.
>
> > It directly contradicts RFC8325/section 5.4:
> > "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)."
>
> Yes, that's exactly what I explained in the preceding text above:
> normally a Diffserv domain must strictly protect its network at the
> boundary.
>
> > 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"?
>
> Maybe I don't get the point. Under the assumption that this LE traffic
> would have been injected as normal default BE traffic otherwise, I don't
> see any negative consequences for the provider. It is a different thing if
> the user would refrain from injecting this traffic, because he/she wants to
> really only transmit this as background/scavenger traffic.
> But compared to the alternative that this traffic would traverse the
> domain as BE traffic otherwise, I would confirm the "no worries"
> property.
>
> Best regards,
>  Roland
>
> > -----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
> >
>
>