Re: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00

"Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com> Mon, 20 June 2011 15:56 UTC

Return-Path: <tom.van_caenegem@alcatel-lucent.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8109E802F for <avt@ietfa.amsl.com>; Mon, 20 Jun 2011 08:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzd5sXmcj04o for <avt@ietfa.amsl.com>; Mon, 20 Jun 2011 08:56:50 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E445C9E800D for <avt@ietf.org>; Mon, 20 Jun 2011 08:56:49 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5KFud16008570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Jun 2011 17:56:39 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 20 Jun 2011 17:56:39 +0200
From: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
To: Roni Even <Even.roni@huawei.com>, 'IETF AVTCore WG' <avt@ietf.org>
Date: Mon, 20 Jun 2011 17:56:37 +0200
Thread-Topic: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00
Thread-Index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gADSqsTA=
Message-ID: <EC3FD58E75D43A4F8807FDE074917546182142FB@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com>
In-Reply-To: <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: nl-NL, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
Subject: Re: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
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>
X-List-Received-Date: Mon, 20 Jun 2011 15:56:50 -0000

Hi Roni,

At the meeting in Prague I got indeed some positive feedback on "draft-vancaenegem-avtcore-fb-supp-and-retransm-00", which I submitted because the way one does feedback suppression is very much impacting the retransmission. There is also a strong dependency on topology where the RAMS architecture (SSM with multiple disjoint FT) represents my main interest. Because Magnus has expressed several times he felt that even though RAMS includes elements related to retransmission, still some holes were left related to retransmission for SSM with a RAMS-like architecture. So, I made a new submission draft-vancaenegem-avtcore-retransmission-for-ssm, in line with Magnus' comments. This draft takes over the main elements from "draft-vancaenegem-avtcore-fb-supp-and-retransm-00"  (in fact replaces it) and adds new items such as congestion avoidance considerations/rules , as well as multicast/unsollicited retransmission, and is focusing on SSM with disjoint FT/RS architecture.

The WG draft on feedback suppression has nothing to do with retransmission (this has been discussed on the mailing list quite some time ago), and basically defines the suppression message. So, I disagree with your view here. I still have comments on this draft (some of them are outstanding and have not really been resolved -also part of the reason I submitted "draft-vancaenegem-avtcore-fb-supp-and-retransm-00"). I will provide my comments on the most recent version soon.

Regards,

Tom 


    

-----Original Message-----
From: Roni Even [mailto:Even.roni@huawei.com] 
Sent: zondag 19 juni 2011 15:47
To: 'IETF AVTCore WG'; Van Caenegem, Tom (Tom)
Cc: 'Magnus Westerlund'
Subject: RE: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00

Hi,
I have finally found the time to read the document. I agree with Magnus that the issue of retransmission in the RAMS architecture where the RS and FT are collocated is not specified and it should also be reflected in the feedback suppression draft.
I think the draft has good text on the analysis of the feedback suppression and this should be added to the WG document. Maybe Tom and Qin can work on the WG document on this topic.
As for the retransmission, I am not sure if this should be as part of the suppression draft. If the issue is only for the case where we have the FT/RS collocated with unicast feedback as in the RAMS case maybe it can be in the RAMS scenario draft. If we are looking at a broader retransmission case (that is not well specified in current draft) that includes also the multicast retransmission from the RS or from the DS it may be good to discuss it as part of the WG document.

Regards
Roni



> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of 
> Magnus Westerlund
> Sent: Saturday, March 26, 2011 12:24 PM
> To: IETF AVTCore WG; VAN CAENEGEM Tom
> Subject: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-
> retransm-00
> 
> Tom, AVTCORE,
> 
> I have reviewed this draft and have the following comment.
> 
> To me it appears that one big reason for the issues is actually that 
> we haven't specified how RTP retransmission in SSM with unicast 
> delivery is supposed to work. Because if that was well defined we 
> would likely have concluded that one should not forward NACK request 
> to the DS from a FT for any request it service locally.
> 
> Thus as I raised before in relation to the RAMS work that there 
> appeared to be a need for defining this properly, including this 
> aspect. Do we have anyone that is interested in defining this?
> 
> Secondly I think there clearly are some improvements needed of the WG 
> document based on what you comment. One thing is clearly to clarify 
> the WG document on its usages, and then map those usages of 
> suppression to different topologies.
> 
> My personal opinion on how to handle your comments are to include your 
> concerns in the WG document.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance avt@ietf.org 
> https://www.ietf.org/mailman/listinfo/avt