Subject: low delay RTCP

From: "Shigeru Fukunaga" <[email-masked]>
Date: Wed, 12 Jul 2000 21:33:16 +0900

Dear all,

I would like to start discussing about generic RTCP. I made a draft for the starting point 
of the discussion. Would you please check it and give me comments?

This first draft mainly describes the low-delay RTCP (for NEWPRED of MPEG-4 
and H.263+) for the moment. It is possible to add and modify for other tools (FIR or 
re-transmission, etc), if everyone wants to merge these tools to one draft and we get
a consensus after discussion on this reflector or in the Pittsburgh meeting.

Best Regards,
Shigeru Fukunaga
--
   Shigeru Fukunaga ([email-masked])
   Oki Electric Industry Co., LTD.
   Tel. +81 6 6949 5101; Fax. +81 6 6949 5108

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Jul 2000 17:38:10 +0200

I'm currently working on something similar.  In fact, there is only
one big difference: I (and a few people I consulted with) believe that
a hard restriction to unicast is likely not necessary.  We are instead
thinking of a scheme that allows the use of feedback even in small
multicast groups, the size of which depends on factors such as
bitrate, network conditions as reported by receiver reports, and such.
Reason for this is the observation that especially RPS/Newpred is
very effective in small multicast groups, as it takes 1) much fewer bits
then true intra pictures, and 2) does not have negative implications
compared to intra macroblocks (blocking artifacts around Intra MBs
are avoided).

Other then that its really language and structure only.

I suspect we can merge the drafts during/after the Pittburgh IETF.

Stephan

The idea is to

---

From: "Shigeru Fukunaga" <[email-masked]>
Date: Fri, 14 Jul 2000 11:45:09 +0900

Dear Stephan and all,

Thank you for your comments.

> compared to intra macroblocks (blocking artifacts around Intra MBs

As you indicated, FIR and NEWPRED can work on small multicast 
group. I agree with your investigation.

On the other hand, the performances of these tools also strongly depend 
on the delay, because the delay leads the slow error recovery, In this case, 
the degraded pictures are displayed for long time, or the video is freezed.

If possible, I would like to realize both small multicast and low delay.
However it seems not possible because of the flood of backward messages.

Therefore we have to select one from 2 items.
You selected the small multcast and not low delay. While I selected the
low delay on unicast. As our 2 types of selection have some reasons 
respectively, it seems not easy to marge 2 drafts.
I think it is not so good these 2 types of rule are defined in one profile.

I think there are following alternatives:
 1. You or I will change one's mind and integrate to one profile.
 2. 2 profiles will be defined for 2 ruls respectively.
 3. We will find good reason (condition) to be compatible both small 
    multicast and low delay.
 4. 2 types of rule will be defined in one profile.

I would like to get comments.

Best Regards,
Shigeru Fukunaga

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 14 Jul 2000 10:50:41 +0200

>However it seems not possible because of the flood of backward messages.

I believe we have found a way to avoid this to a certain extend by
dithering and preventing other receivers of sending their own upstream
messages for a identical reason (by listening to all messages sent
RTCP is multicasted, too).

>  4. 2 types of rule will be defined in one profile.

Looks like 3, or maybe 4 to me.

See you in Pittsburgh.

Stephan

---

From: "Dr. Injong Rhee" <[email-masked]>
Date: Fri, 14 Jul 2000 09:46:50 -0400

Fukunaga San,

> group. I agree with your investigation.

Count in retransmission as well. It seems that retransmission and FEC are
natural for unicast and  multicast.

Retransmission and FEC can be made
scalable even for large multicast group with appropriate feedback
suppression or local recovery shcemes (On the other hand,
NEWPRED and FIR seem inherently limited in large multicast groups
because the encoder must adapt to each recver's loss
patterns).  For instance, retransmission with some hierarchical
struture for local recovery as discussed in IETF-RMT group would also scale
fairly well for a large group. FEC, of course, is scalable for any
group size as it does  not need as much feedback as other recovery
schemes being proposed.

> I think it is not so good these 2 types of rule are defined in one profile.

I believe that FIR and NEWPRED (retransmission for that matter) are not
incompatible as far as feedback is concerned. They all require low delay
RTCP and can work for small multicast. They can even work together; FIR
can be very useful when NEWPRED fails (which happens when recver or
sender frame buffer runs out).

>  4. 2 types of rule will be defined in one profile.

I think 3 or 4 would be a good option as it seems consistent with the
general sentiment of this group -- am I wrong? :-)

Thanks
Injong

-- 
Injong Rhee, Department of Computer Science
North Carolina State University, Raleigh, NC 27695
Home page: http://www.csc.ncsu.edu/faculty/rhee
Email: [email-masked], Phone: 919-515-3305, Fax: 919-515-7925

---

From: Koichi Yano <[email-masked]>
Date: Mon, 14 Aug 2000 09:19:06 -0700

Injong and Fukunaga-san,

We have already presented RTCP retransmission request profile for
unicast session at former IETF meetings and got agreement as a work item
of AVT WG.
I will submit a revised draft today.
(draft-ietf-avt-rtprx-00.txt)

I believe, all concerns about feedback (I mean low delay) are the same
as this case, although our proposal focus on retransmission.
I think we can realize FIR or NEWPRED messages on top of our proposal
(RTCP_NACK).

1) You can use a payload specific field of RTCP_NACK for these. 
Anyways, you should send NACKs when packet loss is detected for the
congestion control use. So send these messages in tandem with NACK
packet since these messages are necessary in the case where loss is
detected.

2) Or new RTCP packet types are defined for these. (the profile needs to
be changed)

Koichi

On Fri, 14 Jul 2000 09:46:50 -0400