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

From: Magnus Westerlund <[email-masked]>
Date: Sat, 26 Mar 2011 11:24:27 +0100

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: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 26 Mar 2011 13:36:45 +0100

> have anyone that is interested in defining this?
Previously I offered my name for this. And if we think we should do this, I can  help drafting it. We had quite a bit experience in this with rams. 

-acbegen

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Sat, 26 Mar 2011 15:18:30 +0100

Hi,Magnus, all:
Thank for raising discussion on some of these issues.
Please see comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "IETF AVTCore WG" <[email-masked]>; "VAN CAENEGEM Tom" <[email-masked]>
Sent: Saturday, March 26, 2011 11:24 AM
Subject: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00

Tom, AVTCORE,

[Qin]: Agree.

[Qin]: Yes, I can help with this if it does worth being defined.
We have one RAMS use case in draft-ietf-avtcore-feedback-suppression which briefly discuss how
to deal with the second loss due to retramission. I believe it is relevant and would like to draw your attention.

[Qin]: As for SSM use case, the interesting part I can see is selective reflection
and selective forward described in this draft. It looks like some improvement that needs WG document
to take a look at. I would like to draw WG to pay attention to these.
to see any tradeoff needed for the WG document?

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Sat, 26 Mar 2011 18:16:23 +0100

Hi Magnus,

Thanks you for reviewing the draft and the comments.

The main initial reason I submitted this draft was to provide some structured feedback on the existing WG draft document http://tools.ietf.org/html/draft-wu-avt-retransmission-supression-rtp-08 . I must say  I am still quite puzzled how a WG item can address FB suppression for multiparty session without even mentioning the existing AVTF suppression rule of RFC 4585. 
But as I tackled the topic with focus on SSM, it became apparent to me that FB suppression and the actions triggered or system knowledge gathered on the basis of RTCP FB messages need to be addressed together. In this draft I focus on the impact of FB supression on the retransmission action/service (but this could be easily made more generic). 
So, I agree with you that this draft has material that should be addressed in the scope of the FB suppression/3rd party loss WG item, and it could also be fed into a WG item addresssing "retransmission" in SSM. But it is a fact that RAMS does cover some retransmission aspects as well. We need to see how we address this.

Tom  

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: zaterdag 26 maart 2011 11:24
To: IETF AVTCore WG; Van Caenegem, Tom (Tom)
Subject: Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00

Tom, AVTCORE,

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

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 28 Mar 2011 04:09:53 -0500

Correlated loss in a multicast RTP system is a real problem, particularly in commercial IPTV systems. Tom's draft begins the discussion of this important area, and the small section on distributed repair is particularly important. We need to continue to think about standard mechanisms to have the FT/RS device handle loss to large populations of receivers. 

The topology that is most interesting to me is when there is a well-defined mapping from a set of SSM receivers to combined FT/RS devices. In other words, IPTV systems often use SSM and put a repair/RAMS device at the edge of the service provider network. The FT and RS devices are co-resident in a single physical device. This device is the focus point for error recovery and thus NACK suppression. This is not the only topology that we should consider, but it should be strongly considered.

I have some experience in this area and would like to help with this analysis.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Saturday, March 26, 2011 11:24 AM
To: IETF AVTCore WG; VAN CAENEGEM Tom
Subject: [AVTCORE] Comments ondraft-vancaenegem-avtcore-fb-supp-and-retransm-00

Tom, AVTCORE,

Cheers

Magnus Westerlund