Re: [AVT] Fwd: Retransmission and fast channel change with usage ofRTP/RTCP
Colin Perkins <csp@csperkins.org> Wed, 26 March 2008 23:04 UTC
Return-Path: <avt-bounces@ietf.org>
X-Original-To: ietfarch-avt-archive@core3.amsl.com
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5646128C6A5; Wed, 26 Mar 2008 16:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.634
X-Spam-Level:
X-Spam-Status: No, score=-100.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHxD+edXxRCS; Wed, 26 Mar 2008 16:04:29 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C0B28C6C2; Wed, 26 Mar 2008 16:04:29 -0700 (PDT)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B0128C6A5 for <avt@core3.amsl.com>; Wed, 26 Mar 2008 16:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb5igJLt6fA0 for <avt@core3.amsl.com>; Wed, 26 Mar 2008 16:04:27 -0700 (PDT)
Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id 1E71B28C6FA for <avt@ietf.org>; Wed, 26 Mar 2008 16:04:27 -0700 (PDT)
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:60412 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1JeedB-0007JQ-Q2; Wed, 26 Mar 2008 23:02:05 +0000
In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB7FD805@lan-ex-02.panasonic.de>
References: <70765B7ABD04E845863F69CAC91A5ADB01B0DAA4@Xms1.etsihq.org> <12919642-CFC2-492C-9FC0-E1381B30CBFA@csperkins.org> <1FEB9B9F2EC38343955D02B2AE86AACB7656DF@lan-ex-02.panasonic.de> <50365D40-4B93-4B00-A68D-10BF08468D6D@csperkins.org> <1FEB9B9F2EC38343955D02B2AE86AACB7FD805@lan-ex-02.panasonic.de>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <8BD6448C-729E-4565-990F-8602B931ABE1@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
Date: Wed, 26 Mar 2008 23:02:03 +0000
To: Jose Rey <Jose.Rey@eu.panasonic.com>
X-Mailer: Apple Mail (2.753)
Cc: VAN CAENEGEM Tom <Tom.Van_Caenegem@alcatel-lucent.be>, IETF AVT WG <avt@ietf.org>, Jeff Goldberg <jgoldber@cisco.com>
Subject: Re: [AVT] Fwd: Retransmission and fast channel change with usage ofRTP/RTCP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Jose, On 25 Mar 2008, at 15:53, Jose Rey wrote: > thanks for your feedback. Inline... > > [...] >> >>> Now, since the RTP client at the retransmission proxy cannot send >>> its NACK in the media SSM group, it is proposed to send these in >>> the *repair* SSM through its Distribution Source, i.e. the >>> retransmission server, either as RFC-4585-NACKs or in summarized >>> RSI form. However, by doing this, we are mixing the SSRC spaces >>> of two different (but associated) sessions. Also the >>> retransmission client doesn't know what to do with this feedback >>> as it would just think the NACK is from another *repair* client. >> >> You probably want to exchange RTCP information, so that all the >> devices see the full SSRC space, making this one RTP session. > > We definitely want to avoid forwarding RTCP information from every > single user either in either 'reflection' or 'summarized' mode into > the repair session. That is, in part, the reasoning behind the out- > of-band definition of who is who in the 'session', as below. It can > be a lot of information, which is not really necessary for running > IPTV. Is this exchange a prerequisite for forming a valid > 'session'? I mean, RTCP receiver bandwidth and session group size > can be communicated via SRB messages and RTCP for repair clients is > probably going to be 'off', anyway. They need to share an SSRC space for it to be a single RTP session. If you can do that via out-of-band signalling, fine. My gut feeling, though, is that it might make sense to specify that full RTCP is distributed to every device in the session, to allow for future extensibility (there's no point forwarding RTCP into the repair session, since that would just loop it back to the receivers that generated it, but I think it does make sense that the retransmission proxies see the full RTCP). >>> A proposed solution for indicating the repair client what to do with >>> this forwarded NACK would be to use an additional SDP attribute >>> listing the SSRC of the RTP client (we would indicate the SSRCs >>> of the >>> retransmission proxy and feedback target as well). The repair >>> clients >>> would then know, by looking at the SSRCs that it is a forwarded NACK >>> from the media SSM and that they must forward it to the media client >>> for NACK damping. The appropriate semantics would probably have >>> to be >>> writen down in an I-D. >> >> Explicit SDP signalling of the different roles, addresses, and >> SSRC values used would seem to be a good thing. It might also be >> possible to include role hints in-band in RTCP packets, although >> we'd need to think through the implications of that. > > I think the first option is the preferred one. What would be the > advantages of the second? I'm not sure, but there do seem to be a lot of proposals for using RTCP in middleboxes (both for these IPTV applications, and for monitoring parts of VoIP systems). I'm wondering if it would be useful to explicitly identify various devices as middleboxes within RTCP, rather than other participants having to infer that. >>> Now, that's one scenario. Another one, though less common, is >>> where losses happen dowstream of the retransmission proxy, where >>> it cannot detect them. We are still thinking about a solution for >>> that. >> >> You mean correlated loss downstream of the retransmission proxy? > > Yes. For that, we are planning on distributing a polling mask, much > like in PGM: a group of selected users has the 'privilege' to > report in advance during a period when noone else is allowed to do > it. The proxy then infers whether it is affecting a lot or just a > few users (mcast or unicast retransmission). Something like this? http://citeseer.ist.psu.edu/bolot94scalable.html That might be a useful thing to standardise as an AVPF extension. Cheers, -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt
- [AVT] Fwd: Retransmission and fast channel change… Colin Perkins
- Re: [AVT] Fwd: Retransmission and fast channel ch… Randell Jesup
- Re: [AVT] Fwd: Retransmission and fast channel ch… Jose Rey
- Re: [AVT] Fwd: Retransmission and fast channel ch… Colin Perkins
- Re: [AVT] Fwd: Retransmission and fast channel ch… Jose Rey
- Re: [AVT] Fwd: Retransmission and fast channel ch… Colin Perkins
- [AVT] Some comments to subsection 8.1.1 in draft-… Ye-Kui.Wang
- Re: [AVT] Some comments to subsection 8.1.1 in dr… Colin Perkins
- Re: [AVT] Some comments to subsection 8.1.1 in dr… Ye-Kui.Wang
- Re: [AVT] Some comments to subsection 8.1.1 indra… Even, Roni
- Re: [AVT] Some comments to subsection 8.1.1 indra… Ye-Kui.Wang
- Re: [AVT] Some comments to subsection 8.1.1 indra… Colin Perkins
- Re: [AVT] Some comments to subsection 8.1.1 indra… Ye-Kui.Wang
- Re: [AVT] Some comments to subsection 8.1.1 indra… Randell Jesup
- Re: [AVT] Some comments to subsection 8.1.1 in dr… Ye-Kui.Wang