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

[Toerless Eckert <[e-mail]>]

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]