Re: [tsvwg] Multicast suggestion for draft-ietf-tsvwg-le-phb-04

[Roland Bless <[e-mail]>]

Hi Toerless,

see inline comments.

On 06.04.2018 at 04:08 Toerless Eckert wrote:
> a) Would ike to bring up a multicast specific issue with LE and
> multicast: 
> 
> Since i was first exposed to fountain type codecs that can
> surive arbitrary loss and its benefit in conjunction with
> multicast transmission, i thought that LE traffic classes
> would be an ideal use case for IP multicast in conjunction
> with these codecs and LE. You just send this stream, it only gets
> replicated when there is available bandwidth not used by best
> effort traffic, jujust wait long enough until you have enough
> packets for your decoder to reconstruct your original data. Great!
> Kinda 2004'ish... thinking (first digital fountain products or the like 
> around that time).

Yes, interesting use case...

> Alas, what this nice but too simple thought about LE ignores
> with IP multicast is the problem that queue drops can only
> happen after replication inside a network device, so any
> non-congestion controlled multicast LE traffic does not only
> take away unnecessary bandwidth on the incoming interface (like unicast),
> but it does constitute an intentional or unintentional attack
> vector against a resource that in most network platforms
> can not even be managed at all, but is just shared at box/ASIC/NPU
> level: replication performance. With unicast, there is
> often some impicit or explicit fair allocation of NPU resources
> vs. input interfaces, but when you start having some multicast
> flows with a lot of outgoing interface receivers (lots of
> replications, and most of them discarded), you can quickly
> run into starvation of other multicast or even unicast flows
> because you started trying to replicate and forward million
> more packets thinking that they woudn't cost resources because
> they'd get dropped inernally anyhow being LE. Especially when
> the multicast replication performance is not separate from inicast,
> but you just got a single resource eg: NPU whose performance
> is simply measured in total number of egres packets it supports,
> you can get quite surprised how your aggregate egress packet rate
> goes down the drain because the poor NPU spends most of its time
> replicating and dropping LE packets to slower congested interfaces.

Interestingly, the LE idea was motivated by a DiffServ multicast
problem, see RFC3754.
I think I understand the problem, so I try to rephrase
in my own words:
Packet replication happens before the network node can know
that there is congestion at a particular output
queue, so the replication to that output queue was
not necessary. In my point of view this is an interesting
implementation-related optimization problem, but it is not really
specific for the LE PHB. The same problem exists for BE traffic,
as also some output interfaces may be congested, whereas others
would not.
At the time when we wrote RFC3754, there was a comment that on
some router architectures it is possible to directly duplicate
a multicast packet on the backplane of the router, so that all
outgoing interfaces read the packet in parallel. In this case
there may not be such a replication performance impact.

> With BE traffic you would not even think of designing multicast
> solutions, where the aggregate amount of egres traffic was larger
> than what the outgoing interfaces support. With LE traffic and
> network/found codecs you can esily run into the misconception that
> such a setup would work perfectly well, because you are not aware
> that replication and large amount of dropping does wase
> precious resources.

I'm not sure about this one...see next comment.

> Aka: I would highly recommend to make a statement that 
> multicast LE traffic (outside controlled networks) MUST
> be congestion controlled using the options summarizzed in 
> RFC8085, 4.1. - and add explanatory text about the reasons
> (as above).

I don't see how congestion control would help to
avoid the internal resource waste by unnecessary
replication. A congestion signal by packet loss
or ECN mark would only affect a particular multicast
branch and also receiver-based congestion control
would not change the situation.

> If this is something you think is useful, let me know, i could
> help rewrite to fit the draft.
> 
> b) I really had a hard time finding this draft because i am
> always looking for "scavenger" is there any way to smuggle that
> word into the draft (some side remark) so that future google searches
> will find it ?

> I don't think i am the only one that remembers this traffic
> class by that name, even if the official IETF term is different (LE).

Point taken, but let me explain a little bit:
The QBone Scavenger Service (QBSS) Definition was published
March 16, 2001, whereas our "Lower than best effort" idea was first
published in September 1999 as draft-bless-diffserv-lbe-phb-00:
http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg05168.html
or
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00

>From this time on, we developed it further within the DiffServ WG.
So strictly speaking, the IETF term has been changed from ""Lower than
best effort" to "Lower Effort"
(https://tools.ietf.org/html/draft-bless-diffserv-pdb-le-00).

I think that the QBSS definition was an Internet2 implementation
of our LBE PHB, but the QBSS definition never mentioned that origin.
So most people think that the scavenger service definition was the
original idea, but indeed our lower than best-effort was published
one and a half years before the QBSS specification.
So I'll try to provide that linkage to scavenger service for those
who are only familiar with the Internet2 side of the story :-)

Best,
 Roland