Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

["Black, David" <[e-mail]>]

With <WG Chair Hat=OFF>, I wanted to +1 this conclusion:

> > > II) LE CC MAY be more aggressive than BE CC (give it more share than
> > > BE traffic if LE traffic is treated as BE) only if known to operate
> > > across a fully LE enabled path (every hop supporting LE). In this case, LE CC
> > > MUST fall back to I) when it can suspect that the path is not fully LE capable.
> >
> > I think that this cannot be reliably detected by the end-systems only.
> > A separate codepoint could help that indicates LE elevation.
> 
> See above - let's consider point II) canned right now and
> let me try to figure out some more input from ICCRG and Ruediger
> before i have a new opinion about "more aggressive than BE CC" options.

I strongly support both this separation of the two approaches and not taking
up approach II) in the current LE PHB draft.   Two quick reactions/comments:

a) Approach II) to LE CC seems only feasible in a fully controlled environment,
	at least for the network to which the sending endpoint is attached.
	Diffserv "in the wild" deployments can be much less disciplined.

b) Approach II) also feels like a different PHB by contrast to the LE PHB where
	there's an expectation that endpoints will reduce LE traffic in the face
	of competition with BE traffic (see SHOULD/MUST discussion on
	level of requirement for use of LBE transport in another thread).

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Toerless Eckert
> Sent: Wednesday, April 11, 2018 9:26 PM
> To: Bless, Roland (TM)
> Cc: [e-mail]
> Subject: Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
> 
> On Tue, Apr 10, 2018 at 02:59:17PM +0200, Bless, Roland (TM) wrote:
> > Hmm, I also agree that LE CC at least covers BE CC requirements.
> > However, right now I think that some traffic may actually not be
> > CCed, such as short UDP transactions, one request, one response
> > (DNS is a typical example).
> 
> Right. So the text i was proposing somehwere else on the thread
> stating that LE traffic MUST also be good BE citizen (not get larger
> share than BE traffic if forwarded via BE PHB) is probably an easier
> way to describe the expectations against LE CC mechanisms - it avoid
> having to specify what really our (IETF) BE CC expectations are by just
> referring to them.
> 
> > This is then not a UDP flow and maybe not
> > really eligible for the LE class, however, I can imagine some uncritical
> > telemetry data such as infrequently polling of temperature sensors
> > to use LE. That's why I used a SHOULD. However, I already have a
> > revision of text on CC requirements on my TODO list for the next
> > I-D revision anyway. So the above text uses "LE traffic" that also
> > includes packets that cannot be strictly denoted as "flow".
> 
> Well, by just referring to BE LE as suggested about this would
> be resolve: If you're allowed to not use CC for stuff like
> DNS in BE, then you're therefore also allowed to do it in LE
> (this does not imply whether or not it would make sense in LE)
> 
> Referring to BE LE is somewhat lame, it would be nicer if we had a
> comprehensive BE CC requirements spec we could point to, but i have
> to admit i don't know which doc does include this right now. On
> the other hand, CC expectations for BE may evolve over time,
> and referring to them the way suggested above makes LE automatically
> adjust as well to maybe changing BE CC requirements.
> 
> Wrt to UDP/Telemetry: I think it would make LE a lot more attractive
> if we had some positive examples how to use it for real relevant
> use-cases. There is a list of nice use cases by name, but i fear
> that most of them can't really live with a completely
> unpredictable, opportunistic traffic class like LE alone.
> 
> I was think that most applications for LE will require at least
> some form of deadline: require a deadline. Movie/software data files
> could be made available 48 hours before release, but only at
> release would the key for decrypt be distributed. Periodic actions
> like backup, where deadline is the period, etc., pp.
> 
> The generic solution to this is to use BE/LE in a hybrid fashion.
> Calculate "min rate" to finish transfer by the deadline.
> Transfer via LE, but whenever rate falls below min rate,
> transfer remaining rate via BE.
> 
> IMHO, One could use MP-TCP for this, one LE, one BE flow.
> But i would only include text about MP-TCP after approval of
> this disussing on MPTCP mailing list.
> 
> Telemetry could work similarily. If you need some minimm reliable
> rate, you send that with BE and add higher rate with LE. But
> whether or not either BE or LE rate is permissible if no further
> CC is applied is another discuss.
> 
> > BTW, RFC8085 also says SHOULD:
> >    It is important to stress that an
> >    application SHOULD perform congestion control over all UDP traffic it
> >    sends to a destination, independently from how it generates this
> >    traffic.
> 
> Not quite sure about the history on the MUST/SHOILD part of the
> doc. The explanatory details are pretty good though ;-)
> 
> > > b) 8085 has UDP in the title. It would be good if the CC text was
> > > amended to make it clear the requirement applies whatever the
> transport
> > > is. Not sure what the best magic text (or better reference) for non-UDP
> > > based transports is.
> >
> > I deliberately did not put UDP into the text, but I probably can
> > clarify a bit that RFC 8085 describes UDP-based applications, but
> > that this may apply to other non-CCed transports as well.
> 
> Something like that, yes.
> 
> > > c) I couldn't figure out from rfc6297 if all the observed LE protocol
> > > (profiles) would actually automatically receive less share of bandwidth
> > > if simply run together with "normal" TCP traffic in the same BE queue.
> > >
> > > To me its somewhat logical that an LE transport protocol that knows
> > > it will get LE treatment could and should actually be somewhat more
> > > aggressive than a BE transport because it has to recover from more loss,
> > > or if ECN is used it needs more aggressive upspeeding to best utilize
> > > the likely a lot more fluctuating ressources in LE.
> >
> > Probably, but higher aggressiveness could also impact fairness and
> > stability within the LE class, but my main concern is that LE may
> > get elevated to BE by domains that don't support LE. In this case
> > BE flows may loose their "fair share" in presence of more aggressive
> > LE flows.
> 
> Lets take the discussion about the current aggressiveness of the various
> LE CC mechanisms known to ICCRG mailing list first, if there is no
> clear better knowledge, i'd at best suggest that that option is for further
> research. Which we may want to note in the doc.
> 
> > > d) The document only mentions what happens when LE traffic gets BE
> > > treatment in passing:
> > >
> > >   [about SHOULD do LE CC]:
> > >   "but is also essential if LE traffic is mapped to the default PHB
> > >    in DS domains that do not support LE"
> > >
> > > I think wrt. to CC requirements against LE traffic, we should make
> > > it front and center to define LE CC behavior in comparison to
> > > BE CC behavior - else we will get all type of unpredictable results
> > > when folks start to use various LE protocols:
> >
> > It think that this leads too far. With respect to RFCs2474/2475
> > (DiffServ PHB and Architecture) a PHB definition
> > describes/determines only the packet forwarding behavior within a single
> > node (cf. Sec.3 of RFC2475 https://tools.ietf.org/html/rfc2475#section-3).
> > The single PHB is agnostic what is happening inside its DS class,  since
> > a DS node only operates on the whole behavior aggregate. So I
> > think it is reasonable to shortly discuss LE PHB CC requirements, but it
> > seems that we otherwise need a separate document for discussing all
> > the issues...
> 
> Right. I'd like to continue this discuss, especially with Ruediger
> being knowledgable about this, but at this point in the discussion
> i wouldn't continue to suggest the above text (d).
> 
> > > I) LE CC must ensure that if operating across a congested hop that
> > > is treating LE as BE, LE CC MUST NOT give LE traffic more bandwidth share
> > > than the competing BE traffic, and it SHOULD give it less share.
> >
> > > So i hope thats the uncontentuous part. Here is the interesting part:
> >
> > Nope, since it is probably not possible to fulfill this requirement:
> > if there is less BE traffic present (e.g., inelastic or all application
> > limited) at the bottleneck, say 20% of link capacity, and the rest is
> > used by LE traffic (i.e., 80%), so the MUST NOT is not sensible in this
> > case (would mean that LE traffic is throttled to 20% too). This is
> > exactly, what I don't want. LE should be able to use up all otherwise
> > unused resources.
> 
> I think I) is right AND you are right, so either i need to
> propose a better wording to make I) better readible, or you need to
> read it again ;-)
> 
> I) only describes the necessary LE CC behavior if the LE
> traffic was ( unknowing to the LE CC mechanism)  treated as BE,
> not if it is really treated separately from BE as LE.
> 
> In your case, all real BE traffic occupies just 20% of the link, so
> its not really a congestion point at all. Additional BE traffic on that
> link that wanted arbitrary bandwidth could therefore get 80%, therefore
> according to my requirement, so could the LE traffic, so your
> example result is met.
> 
> More interestingly, lets say you've got 10 BE flows that want
> arbitrary bandwidth, on a 10 Mbps link each gets 1 Mbps. We add
> 10 LE CC flows and also treat them in the BE queue (without them
> knowing of course). The result is that each of the LE CC flows
> should now get at most 0.5 Mbps, because now we have 20 flows
> competing on the link, and if those where all BE CC then each one
> would get 0.5 Mbps each.
> 
> This is really the core example, because we primarily care about
> LE CC to not be unfair to BE traffic IF the LE traffic is treated as
> BE (somewhere along the path).
> 
> Now, in reality, these 10 LE flows are put into an LE queue with
> 0% bandwidth share, so unfortunately, they will not get anything,
> because those 10 BE flows get all the 100% bandwidth. Or maybe the
> operator actually gives LE some 5% weighted fair queue to LE on
> the link, in which case all LE flows would only get those 5%.
> Hoever many LE flows there are. On a link with an actually
> congested BE queue.
> 
> I do think that there is of course no way for an LE CC
> flow to know that it is NOT competing with BE CC traffic unless
> we add anything new to the mix (which we don't), so the LE CC
> flows will always have to compete amongst each other as if they
> compete also with BE flows. Therefore no need to explicitly make
> a requirement specifically about the case where LE CC flows are
> NOT in the same queue with BE CC.
> 
> lastly: I think at least some of the existing LE CC mechanisms
> are actually meant to compete with BE CC and then actually get
> _less_ share of the BE queue than competing BE CC traffic. I
> think they would all get the actually free 80% in your example,
> but in my congested example of 10 BE plus 10 LE flows in the
> BE queue, i think they would get less than 5% of bandwidth
> each. Which is fine. Which might be something we could write
> up as a requirement, but i am not sure that we should. Primarily
> because i think it would be a very difficult target to describe.
> 
> > > II) LE CC MAY be more aggressive than BE CC (give it more share than
> > > BE traffic if LE traffic is treated as BE) only if known to operate
> > > across a fully LE enabled path (every hop supporting LE). In this case, LE
> CC
> > > MUST fall back to I) when it can suspect that the path is not fully LE
> capable.
> >
> > I think that this cannot be reliably detected by the end-systems only.
> > A separate codepoint could help that indicates LE elevation.
> 
> See above - lets consider point II) canned right now and
> let me try to figure out some more input from ICCRG and Ruediger
> before i have a new opinion about "more aggressive than BE CC" options.
> 
> Cheers
>    Toerless
> >
> > Cheers,
> >  Roland
> 
> --
> ---
> [e-mail]