Subject: Re: low delay RTCP

From: Leonid Rosenboim <[email-masked]>
Date: Mon, 17 Jul 2000 09:26:59 +0200

Although I am new to this forum, I would like to contribute to this
thread from my past experience:

 I agree with Shigeru san, Low Delay is contrary to Multicast, here is
an additional reason:

Many of today's switches, such as Layer2 Ethernet or ATM switches,
implement Multicast in software, while switching normail unicast traffic
in
hardware. This leads to significant additional delay (as well as a
potential
throughput bottleneck)  for any Multicast traffic when compared to
Unicast traffic
going through the same route.

 It is my understanding that for NEWPRED to be effective, low delay is
essential,
hence it is my opinion that the NEWPRED specification, as well as any
other error
handling mechanism which is sensitive to round-trip delay should be
limitted to Unicast
transport, and recommend the use of a dedicated reflector (a.k.a. MCU)
for multiple
participant applications.

 Hopt this input is useful.

 Leonid

---

From: "Injong rhee" <[email-masked]>
Date: Mon, 17 Jul 2000 09:35:08 -0400

I believe NEWPRED does not work with reflectors. However, retransmission
can. There is some work in IETF-RMT that tries to come up with logical
structure among receivers to handle feedback suppression and aggregation
in multicast
environments. I am not sure that it is wise to limit the low delay
feedback to unicast only since it may not be the inherent feature of
low delay feedback (i.e., well designed systems can handle it without
hurting scalability).

-----Original Message-----
From: Leonid Rosenboim [mailto:[email-masked]]
Sent: Monday, July 17, 2000 3:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: low delay RTCP

 Leonid

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Jul 2000 09:53:14 -0400

--> Leonid Rosenboim writes:
>in hardware. This leads to significant additional delay (as well as a
>potential throughput bottleneck)  for any Multicast traffic when compared
>to Unicast traffic going through the same route.

Whilst this is undoubtably true, it's a temporary implementation limitation
rather than an inherent feature of multicast.

>essential, hence it is my opinion that the NEWPRED specification, as well
>as any other error handling mechanism which is sensitive to round-trip
>delay should be limitted to Unicast transport, and recommend the use of a
>dedicated reflector (a.k.a. MCU) for multiple participant applications.

I disagree. It's true that NEWPRED should be restricted to small numbers of
participants (due to the difficulty of getting timely feedback), but this
does not necessarily imply that it cannot be used with multicast (just that
such use must be carefully controlled).

Colin

---

From: Leonid Rosenboim <[email-masked]>
Date: Mon, 17 Jul 2000 16:53:07 +0200

By reflectors I mean application-specific units, a.k.a. MCUs which not only
reflect but
TRANSCODE the streams, switch between sources and all sorts of intelligent
media-aware
functionality which makes a video conferense a paletable experience. There
is much experience
already around such units developed for the H.320 (VideoConf over ISDN)
environment.

Media-aware MCUs which do transcoding can definitely be NEWPRED peers to
every client.

Leonid

---

From: Leonid Rosenboim <[email-masked]>
Date: Mon, 17 Jul 2000 17:00:53 +0200

Colin Perkins wrote:

> [snip]

You should better ask some people who actually design switches for a living
before
making such a statement. Personally I do not believe that Multicast is EVER
going
to be implemented in hardware, but I am not a switch impelentor myself, I just
talk
to other people who are.

> [snip]

I am not saying that you can not use NEWPRED on Multicast, I am only suggesting

not to STANDARDIZE it for the time being. If you FOCUS the spec on practical
needs
and application, the spec will be ready sooner and will yield more
interoperable
implementations thus. And NEWPRED on MC certainly does not look practical for
the foreseeable future.

Leonid

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Jul 2000 10:58:10 -0400

>Colin Perkins wrote:
...
>needs and application, the spec will be ready sooner and will yield more
>interoperable implementations thus. And NEWPRED on MC certainly does not
>look practical for the foreseeable future.

If supporting multicast significantly complicates the spec, and there is a
tight deadline, then I agree with you. Just lets not blind ourselves with
NEWPRED is unicast only, and accidently design something which prohibits
multicast use in future.

Colin

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 17 Jul 2000 17:13:42 +0200

> Personally I do not believe that
> Multicast is EVER
> going
> to be implemented in hardware,

This whole discussion is a red herring.

Of course there are switches where multicast is a few hundred microseconds
slower than unicast.
NEWPRED becomes less effective when you delay it on the order of complete
frames, i.e. multiples of 20 ms or up.

Conclusion: Switch performance should be entirely irrelevant at this order
of magnitude.

Gruesse, Carsten

PS.: I'm not talking about historic switches that are totally defective in
the multicast area such as the 3com switch 1000.
(Please remind me of other switches where the above conclusion is not
true -- I'll make sure not to buy them...)

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 17 Jul 2000 20:28:43 +0200

Hi all:

I want to throw in some video-related facts into this discussion, along
with a few numbers (in the attached excel spreadsheet -- sorry for
using MS tools :-)

What Reference Picture Selection (aka NEWPRED) does is to
take a known-as-correct old reference picture instead of a
(corrupted) recent one for prediction.  The knowledge what
reference picture to use is established through feedback.
Necessarily, the longer the delay on the feedback channel,
the older the reference picture will be.  See our feedback I-D
for a more verbose discussion.

Using an older reference picture corresponds roughly to coding
pictures at a lower frame rate.  What I have done in the
spreadsheet is to calculate the average picture size for
two video sequences (foreman, trevor) at fixed quality level
and skip factors between 0 and 50.  The results are as
follows:

In order to keep the size of an RPS picture smaller then
200% of the typical picture size, your maximum delay
for the feedback message is roughly

Trevor:
a) at 30 fps: 2 pictures delay, corresponding to 66 ms
b) at 15 fps: 5 pictures delay, corresponding to 300 ms
c) at 10 fps: 5 pictures delay, corresponding to 500 ms
d) at 7.5 fps: 5 pictures delay, corresponding to ~670 ms

Foreman:
a) at 30 fps: 2 pictures delay, corresponding to 66 ms
b) at 15 fps: 5 pictures delay, corresponding to 300 ms
c) at 10 fps: 7 pictures delay, corresponding to 700 ms
d) at 7.5 fps: 6 pictures delay, corresponding to 800 ms

Intra pictures are in case of Foreman roughly 1.5 times
as big as a one second old RPS picture; in case of
trevor its about 1.3.  Meaning that even at 1 second delay
RPS is still outperforming a full intra picture.  This
assumes of course a sufficiently deep picture buffer for RPS.

Conclusion

a) At the full frame rate you need to be incredibly fast -- faster
then what can be achieved in todays network (or am I too
pessimistic there?)

b) For "typical" frame rates of today's video telephony
equipment, your delay demands are somewhat more
relaxed, but still too tough to use the regular RR report
mechanisms of RTP (at least in case of Multicast).

c) In any case RPS is better then INTRA (if all systems
are capable of using it).

For the video folks:
Video Coding Standard: H.263+
Optional Modes: I, T, (N)
QP: fixed, 13
					Foreman	Trevor
resulting bitrates for full frame rate:	 ~100 kbit/s	~60 kbit/s
resulting bitrate for intra-only:		~ 640 kbit/s	~460 kbit/s

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Mon, 17 Jul 2000 22:42:27 +0200

> then what can be achieved in todays network (or am I too

Just remember that while we design things to not break in the general
Internet, there is a sizable area of application (sometimes called Business
TV) typically with managed networks where RTTs in the dozens of milliseconds
are quite achievable.  (Only, of course, if you are geographically close --
you can't beat the speed of light.)  Coincidentally, this is also the only
area of application where multicast is widely deployed.

Gruesse, Carsten