Subject: Network flooding when using feedback

From: Stephan Wenger <[email-masked]>
Date: Mon, 26 Jun 2000 13:55:25 +0200

Hi all,

I'm working on an Internet draft covering feedback messages for
predictive video coding schemes.  This work is triggered by the
MPEG-ES packetization discussion, but, in fact, it should have
been done much earlier.

One of the main concerns when using feedback channels are
network flooding problems in multicast environments.

The scaling problem on the feedback channel is well understood.
Any irregular behavior on the forward channel, such as a packet loss,
may result in feedback messages from many receivers at the
same time -- a typical scaling problem.  RTCP prevents this
by allowing only a constant, shared bitrate for all feedback messages,
regardless of the size of the multicast group, thus adding latency
on the feedback channel.  The current MPEG-4 packetization draft
supports a scheme called NEWPRED that is not efficient when
there is a lot of latency, and, therefore, limits the size of the
multicast group to a single receiver for those messages.

That draft also discusses a scaling problem on the forward channel,
which, I believe, does not exist.

The number of negative feedback messages obviously depends
on the size of the multicast group.  I dare to say that it is
proportional to that size, or anything like this.  But I think that
it is reasonable to expect more negative feedback when the
multicast group is big then in case of point-to-point.

Any form of loss leads, when using predictive video coding, to
the need to regain synchronicity between the encoder's loop
and the decoders reference pictures.  Regardless of the
employed mechanism (intra pictures, intra macroblocks,
newpred, whatever) this takes more bits then optimal
predictive coding in a loss less environment.  Hence,
the larger the multicast group is, the more bits must
be spent to keep the encoder's loop and the decoders
synchronized.  But is this a scaling problem?

I believe not.  The encoder has the full control over its sending
bitrate.  Upon receiving of negative feedback messages, it
MAY respond by using additional bits for intra information
or newpred.  It MAY also decide to continue as if nothing
happened (thus accepting that some, or all, receivers suffer
from artifacts introduced due to the asynchronicity of the
encoder and decoders).  It MAY decide to spend bits to
regain synchronicity, but use a different quantization factor
or skip frames in order to keep the sending bitrate constant.
Well designed encoders MAY do all the above, choosing
adaptively based on the number and importance of the
receivers that reported problems.

Since the encoder has full control over its sending bitrate,
there is no scaling problem, at least none associated with
the use of feedback.

Am I missing something?  Please let me know.  Thanks.

Stephan

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Jun 2000 17:09:03 -0400

--> Stephan Wenger writes:
...
>there is no scaling problem, at least none associated with

I wouldn't call this a scaling problem, but there is the obvious potential
for a destructive feedback loop if the encoder increases its sending rate
(due to the addition of extra error correction information) according to
loss feedback from the network. 

Any scheme which adds error correction information must clearly consider 
the stability of its control loop, to ensure that this doesn't occur.

Colin

---

From: "Injong rhee" <[email-masked]>
Date: Tue, 27 Jun 2000 23:04:14 -0400

Hi. Stephan,

It is true that use of feedback (per loss or some small collection of
losses) *may* create
implosion in large multicast groups. However, feedback alone does not cause
implosion.
Implosion is more to do with *where* feedback is sent to. For instance,
 if it is sent to one node (i.e., sender) then it obviously causes
implosion. However,
if feedback reception is distributed (i.e., no centralization of feedback
processing),
then you *might* be able to avoid implosion. There have been quite a few
works
in the reliable multicast community on scalability feedback handling.

The point is that  as long as the use of feedback
information in a protocol allows aggregation or distributed processing of
feedback,
scalability problem due to feedback implosion is not an issue.
 Retransmission or forward error correction is this kind that allow
distributed
feedback processing. (Now if one asks how distributed feedback processing
can be
mapped to the RTP/RTCP framework, I would say that is more of a protocol
problem,
than of a fundamental problem with the approach. If I am wrong, enlighten
me).

With respect to NEWPRED, it has inherent limitation in multicast
environments.  This
is not just because there is a feedback channel for each receiver, but also
because
these channels have to have the sender as an endpoint. Furthermore,
since the sender has to attend to each receiver's loss by adjusting
reference frames
for each receiver,  in a large multicast group, there is no way that
feedback
aggregation is going to help in this situation. Thus, letting alone the
feedback
implosion problem, the scalability problem exists (in a large multicast
group,
almost every frame seems to have losses to the sender; so the sender can't
find a clean frame to reference). Retransmission or forward error correction
does not have this problem though.

However, this should not be the reason to preclude NEWPRED from
the MPEG-4 RTP profile. I believe that in current Internet,
RTP is used more in unicast environments than in multicast
environments (partly due to lack of applications and of multicast
infrastructures).
Although NEWPRED has a problem in a multicast environment, it is
useful in unicast scenarios. I think you also share this view (don't you?).

 In fact, I see a lot of merits in mechanisms which
force feedback to be sent immediately rather than waiting for RTCP RR timers
to
go off as proposed in current draft.
My only objection about the currently proposed profile is its strong  tie
only to
NEWPRED. We should work hard  to devise (or define) a  *generic*  RTP
feedback
format which allows individual profiles to customize it for their own needs.
For instance, NACK or ACK are common feedback mechanisms used in many
network protocols (especially for retransmission).

My two cents,
Injong

-----Original Message-----
From: Stephan Wenger [mailto:[email-masked]]
Sent: Monday, June 26, 2000 7:55 AM
To: [email-masked]
Subject: Network flooding when using feedback

Hi all,

Stephan