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

["Ali C. Begen (abegen)" <[e-mail]>]

Did you check
https://datatracker.ietf.org/doc/draft-vancaenegem-avtcore-retransmission-for-ssm/
? It addresses at least some of the points you made below.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Roni Even
> Sent: Sunday, June 19, 2011 6:47 AM
> To: 'IETF AVTCore WG'; 'VAN CAENEGEM Tom'
> Cc: 'Magnus Westerlund'
> Subject: Re: [AVTCORE] Commentson 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
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt