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

Toerless Eckert <tte@cs.fau.de> Fri, 06 April 2018 16:04 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242FF120724; Fri, 6 Apr 2018 09:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3UWnDN8Eee4; Fri, 6 Apr 2018 09:03:49 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525DD1204DA; Fri, 6 Apr 2018 09:03:49 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2A00D58C4C6; Fri, 6 Apr 2018 18:03:45 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1B83A440214; Fri, 6 Apr 2018 18:03:45 +0200 (CEST)
Date: Fri, 06 Apr 2018 18:03:45 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: tsvwg@ietf.org
Cc: draft-ietf-tsvwg-le-phb@ietf.org
Message-ID: <20180406160344.xwfqgzhzfto56jhq@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vAUNjn9YtiSkqaaEc14Y6iFi45M>
Subject: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2018 16:04:00 -0000

Some thought about CC and bleaching for LE (no multicast this time)

> LE traffic SHOULD be congestion controlled (i.e., use a congestion
> controlled transport or implement a congestion control method [RFC8085])

a) What would be the current summarized TSV IESG review requirement
against a CC statement for BE ? I thought it was something like

  "MUST be CC controlled unless known to be operating across a controlled
  network, and even then it SHOULD use a circuit breaker [RFC8084]".

Whatever the right text is - IMHO it would be great if we knew that text,
and then explained in the draft any difference in CC expectation for LE
vs. these BE rules. I for once do not understand why a simple "SHOULD" would
suffice. My starting point is that LE CC = BE CC, and then - see below.

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.

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. 

Even if so far the researched LE CC mechanisms have not explored this
"more aggressive" behavior, i think it would be great if we could
define the right option for it, to make LE even more useful with
future network profiles (see point f below). But of course the
challenge then is how to make sure such more aggressive LE would
never kill BE in the Internet:

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:

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:

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.

But how could LE CC ever meet the "MUST fall back" expectation ?

e) I don't think LE CC can ever figure out the "MUST fall back" except
through bleaching (or other to be invented signaling).  But the
"do not bleach" rule of the current text is really the most useful rule
for the Internet to make introduction of LE into Internet nodes as
attractive as possible.

II-bleach) LE CC MAY be more aggressive than BE CC (give it more share than BE flows)
only if known to operate across a controlled network where the path
is expected to support LE on every hop. Paths meant to support
more aggressive LE CC SHOULD bleach LE to BE on hops that do not
support LE. LE CC MUST fall back to be equal or less aggrssive than
BE CC when receiving bleached packets (DSCP set to BE).

So, this allows more aggressive than BE, but only for controlled networks.

f) Here is an example where i think more aggressive LE will be quite
valuable: IMHO, we may see a lot more non-TCP friendly traffic
in their own queues, the more inelastic and short-term bursty
services start to appear on SP networks. I would think especially
in 5G/6G and metro networks, DetNet style traffic or really high
bitrate/bursty AR/VR traffic will want to have a lot of low-latency
trafic that is little, or not congestion controlled. And this can 
nicely be stuffed into separate priority queues and get what it wants
(Benefit of having a large SP network).

So this is then a very ragged base load on the links. Then i add
BE traffic, which CCs to mid to longer term available remaining
bandwidth. That leaves a lot of shorter term ragged cliffs left
over which can only be grabbed by more aggressive CC than BE
willing & able to deal with this highly variable leftover bandwidth.

Aka: Taking bandwidth unused in a pure BE network is simple and
works with less aggressive CC than BE-CC. Scavenging remaining bits
from more interesting "multi-service" network loads is the real scavenging
job requiring more aggressiveness.

Cheers
    Toerless