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

From: Roni Even <[email-masked]>
Date: Sun, 19 Jun 2011 16:46:31 +0300

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: [email-masked] [mailto:[email-masked]] 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: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 19 Jun 2011 11:07:17 -0700

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

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

---

From: Roni Even <[email-masked]>
Date: Sun, 19 Jun 2011 23:36:38 +0300

Hi Ali,
Sorry about my email,
I read the retransmission-for-ssm and my comments are on that draft.
Roni

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Sunday, June 19, 2011 9:07 PM
> To: Roni Even; IETF AVTCore WG; VAN CAENEGEM Tom
> Cc: Magnus Westerlund
> Subject: RE: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp-
> and-retransm-00
> 
> Did you check
> Roni Even

---

From: Roni Even <[email-masked]>
Date: Mon, 20 Jun 2011 00:12:14 +0300

Hi,
Here are more detailed comments on the draft. Still I think that part of it
should be in the WG draft on feedback suppression while I am not sure about
the RAMS with retransmission case.

1. The draft starts in the introduction with general view but talks about
SSM with unicast retransmission where the RS is co-located with FT and the
Burst Source. 

2. The third paragraph of the introduction " it will particularly focus on
the impact of packet loss events experienced in an SSM distribution , and
how the elements in the SSM architecture interact best to ensure impacted
RTP_Rx's are provided with appropriate RTP retransmissions." But reading the
draft I think that the focus is on the case where there is also a RS with
the FT and this is not the general SSM but more the RAMS case or at least
the case of SSM with unicast retransmission support from the FT and not from
the DS.

3.In the introduction the third bullet should also mention the third party
packet loss report

4. the introduction says " This document describes the behavior for all
entities defined in an SSM architecture with unicast feedback as described
in [RFC5760] (DS,
   FT, RS  and RTP_Rx) addressing feedback implosion (avoidance),
retransmission efficacy and congestion concerns.". this is what being
discussed in the WG retransmission suppression f=draft and no need to repeat
it here. RFC5760 does not discuss the retransmission which is what I assumed
is the focus of this draft.

5. I am not sure why section 4.1 and 4.2 repeat text that is in suppression
draft (section 3 and 6). If it is not complete there than suggest text
update to the draft.

6. In section 5.1 " When the DS is capable of recovering the lost packet in
due time, it may send an unsolicited retransmission to all RTP_Rx's". I was
wondering if the DS cannot send the recovered packets as regular packets if
did not receive and NACKs from down stream. No need for retransmission at
all.

7.in section 5.3 "Note that we again assume that the RTP_Rx's behave
compliant to [RFC4585], inclusive conformance to the feedback suppression
rule. " I think it will be good to reference also the suppression draft to
explain the conformance. 

8. Section 6 title is " Rules for SSM with Retransmissions" I think it
should be "Rules for SSM with Retransmissions where RS is collocated with
FT"

9. In section 6.2 for the in-band mode how does the DS know the ssrcs of the
FT when sending the in-band message.

10. In section 6.3 the draft says " Unsolicited retransmissions can be
provided over each of the established unicast retransmission sessions or
only once in a
   single multicast retransmission session, sourced either by the DS or  by
the RS.". the discussion before was talking about the RS with FT and not DS.
I think that when the DS sends the retransmission there is no need to add
text to the current drafts.

11.in section 6.3 second bullet, it is generally true but unicast will work
in the RAMS case.

12. In section 6.3 the second requirement for unsolicited retransmission.  I
think that for the multicast case the RS will not know what the receivers
support but it can send the retransmission anyhow since my assumption is
that it got at least one NACK message that will trigger the retransmission.

13. On the editor note in 6.3. For the unicast case the RTP-Rx will need to
support the port mapping draft. 

Regards
Roni

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 20 Jun 2011 17:56:37 +0200

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

> 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.
> 
> appeared to be a need for defining this properly, including this 
> aspect. Do we have anyone that is interested in defining this?
> 
> 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.
> 
> Audio/Video Transport Core Maintenance [email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 21 Jun 2011 00:27:06 +0300

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

> 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'
> 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
> 
> 
> 
> 
> 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
> 
> 
>

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 21 Jun 2011 10:36:09 +0200

Hi Roni,

See also my previous post on the subject. Please, find below my responses on your comments.

Tom 

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: zondag 19 juni 2011 23:12
To: 'Ali C. Begen (abegen)'; 'IETF AVTCore WG'; Van Caenegem, Tom (Tom)
Cc: 'Magnus Westerlund'
Subject: RE: [AVTCORE] Comments ondraft-vancaenegem-avtcore-retransmission-for-ssm

Hi,
Here are more detailed comments on the draft. Still I think that part of it should be in the WG draft on feedback suppression while I am not sure about the RAMS with retransmission case.

1. The draft starts in the introduction with general view but talks about SSM with unicast retransmission where the RS is co-located with FT and the Burst Source.

Tom: not sure where you see a  conflict? 

2. The third paragraph of the introduction " it will particularly focus on the impact of packet loss events experienced in an SSM distribution , and how the elements in the SSM architecture interact best to ensure impacted RTP_Rx's are provided with appropriate RTP retransmissions." But reading the draft I think that the focus is on the case where there is also a RS with the FT and this is not the general SSM but more the RAMS case or at least the case of SSM with unicast retransmission support from the FT and not from the DS.

Tom: the draft only considers retransmission-capable RFC 5760 architectures , that is SSM with unicast feedback. This includes the case where the FT is integrated within the DS, and in that case also the RSo is hosted at the DS. Then of course retransmission is sourced from the DS. 
But even if FTs are disjoint from the DS and which host also a Rso, nothing prevents a DS to also host a RSo providing retransmissions over multicast as indicated in section 6.3    

Question: What is for you the general SSM architecture with retransmission enabled? Is this an architecture where an FT is not co-located with a Retransmission Source? I do not see which advantage that brings, but we can add text that mentions this possibility.

3.In the introduction the third bullet should also mention the third party packet loss report

Tom: the 3rd party loss report is a RTCP FB message, so it is covered by the third bullet

4. the introduction says " This document describes the behavior for all entities defined in an SSM architecture with unicast feedback as described in [RFC5760] (DS,
   FT, RS  and RTP_Rx) addressing feedback implosion (avoidance), retransmission efficacy and congestion concerns.". this is what being discussed in the WG retransmission suppression f=draft and no need to repeat it here. RFC5760 does not discuss the retransmission which is what I assumed is the focus of this draft.

Tom: (nearly) the whole point of this draft is that the behaviour as prescribed in RFC5760 is not well suited for retransmission-enabled SSM architectures with unicast feedback. We describe some rules here that are different from RFC 5760. Moreover the WG suppression draft is not about retransmission.

5. I am not sure why section 4.1 and 4.2 repeat text that is in suppression draft (section 3 and 6). If it is not complete there than suggest text update to the draft.

Tom: see my previous point.

6. In section 5.1 " When the DS is capable of recovering the lost packet in due time, it may send an unsolicited retransmission to all RTP_Rx's". I was wondering if the DS cannot send the recovered packets as regular packets if did not receive and NACKs from down stream. No need for retransmission at all.

Tom: The situation is that the DS has already sent the original packet(s) and RTP Rx did detect the original packet(s) as missing. So, we are talking about retransmission

7.in section 5.3 "Note that we again assume that the RTP_Rx's behave compliant to [RFC4585], inclusive conformance to the feedback suppression rule. " I think it will be good to reference also the suppression draft to explain the conformance.

Tom: The WG draft -for some reason- expresses that an RTP Rx should suppress its FB, whereas RFC 4585 has a MUST indication

8. Section 6 title is " Rules for SSM with Retransmissions" I think it should be "Rules for SSM with Retransmissions where RS is collocated with FT"

Tom: I can add that, but I do not want to exclude that also the DS hosts a retransmission source.

9. In section 6.2 for the in-band mode how does the DS know the ssrcs of the FT when sending the in-band message.

Tom: the different modes I listed relate to informing the RTP receivers (not the DS) of the SSRC of their FT.  The DS can be configured with an out-of-band method.

10. In section 6.3 the draft says " Unsolicited retransmissions can be provided over each of the established unicast retransmission sessions or only once in a
   single multicast retransmission session, sourced either by the DS or  by the RS.". the discussion before was talking about the RS with FT and not DS.
I think that when the DS sends the retransmission there is no need to add text to the current drafts.

Tom: I do not see the problem here? Unsolicited retransmission AFAIK have not been addressed in other drafts/RFCs.

11.in section 6.3 second bullet, it is generally true but unicast will work in the RAMS case.

Tom: OK

12. In section 6.3 the second requirement for unsolicited retransmission.  I think that for the multicast case the RS will not know what the receivers support but it can send the retransmission anyhow since my assumption is that it got at least one NACK message that will trigger the retransmission.

Tom: this rule is there in order to make sure that unsolicited retransmission are in the majority of cases only sent to receivers that really "require" this retransmission, but they suppressed their FB, so the RS does not always know whether receivers have detected a missing packet. 

13. On the editor note in 6.3. For the unicast case the RTP-Rx will need to support the port mapping draft. 

Tom: I agree, but how is this related to the note?

Regards
Roni