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

[Roni Even <[e-mail]>]

Hi Tom,
I see two separate issues as I mentioned in my other email. My commentes
were about the ssm and not about the fb-supp-and-retansm

The first comment is that the ssm draft should be in line with the WG
suppression draft where the issue of when NACKs can be sent is explained. 

The second comment is that the ssm draft focus on the case where the RS is
located with the FT which is one case for SSM (this is more the RAMS
architecture). THe RS can reside with the DS or be a separate entity. Also
the retransmission can be done using unicast or multicast. If the draft want
to address the general retransmission issue for SSM all these options should
be discussed.

Roni

> -----Original Message-----
> From: Van Caenegem, Tom (Tom) [mailto:tom.van_caenegem@alcatel-
> lucent.com]
> Sent: Monday, June 20, 2011 6:57 PM
> To: Roni Even; 'IETF AVTCore WG'
> Cc: 'Magnus Westerlund'
> Subject: RE: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-
> and-retransm-00
> 
> 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:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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  [phone]
> > Färögatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > ---------------------------------------------------------------------
> -
> > _______________________________________________
> > Audio/Video Transport Core Maintenance [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt