Subject: [AVT] Fw: New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

From: Qin Wu <[email-masked]>
Date: Wed, 20 Oct 2010 10:27:03 +0800

Tom,
 Look at the new version of draft, you will find we focus on defining more general mechanism of "feedback suppression" to address different use cases of "feedback implosion".

SSM case is just one example use case we look at. We can address the case you suggested below(which assumes a single DS, one or multiple disjoint FTs, where a FT is co-positioned with a BRS (same IP address))
But I am not sure this case is referred to as "RAMS case". And also what confuse to me in the RAMS case is Retransmission Server is usually used for channel switching in the RAMS case and just used to send unicast RTP stream to one receiver when this receiver requests a unicast burst from Retransmission server. Suppose there is two Retransmission server (i.e., RS1 and RS2 )behind the DS,if the packet loss happens between the DS and  RS1 but there is no packet loss happened between DS and RS2, do you think RS1 should report the packet loss to its upstream DS.
This is not allowed in our draft.  In my understand, maybe there is only one receiver requesting unicast burst, it is not necessary to suppress such RAMS message for one receiver.

In our draft, one similar case is we allow multiple DSs in the SSM case, in such case, packet loss always happens at the upsteam of each DS, each DS should not report packet loss to the upstream DS, in this way, even DS is connected to a different branch of the SSM tree, it is not necessary to send feedback suppresion to all the receiver if some didn't suffer from packet loss.

If there is one downstream DS or intermediate node placed at the downstream of its upstream DS, the downstream may either simply forward the Feedback Suppression message received from upstream, or augment (or replace) it with a  feedback suppression message that reflects the loss pattern they have themselves seen. they should not initiate their own  additional feedback suppression messages for the same packet sequence numbers.  The role of such downstream DS has been clearly defined in the section 3 of draft-wu-avt-retransmission-suppression-rtp-04 as follows:
"
   RTCP Feedback Suppression follows the same semantic model as RTCP
   NACK - it conveys the packet receipt/loss events at the sequence
   number level and considers missing packets as unrepaired.  But unlike
   RTCP NACK, the Feedback Suppression messages can be generated at
   intermediate nodes who are not RTP receivers and sent to the
   corresponding receivers.  Intermediaries downstream of an
   intermediary detecting loss obviously SHOULD NOT initiate their own
   additional feedback suppression messages for the same packet sequence
   numbers.  They may either simply forward the Feedback Suppression
   message received from upstream, or augment (or replace) it with a
   feedback suppression message that reflects the loss pattern they have
   themselves seen.
"

As for why we creat new message instead of using existing NACK, 
NACK lacks scemantics for suppression and NACK as one feedback message terminate at the server, the intermediate node e.g., distribution
source as the server receiving NACK will confuse whether the NACK should be forwarded to the server or the receiver. And the distribution source
has no behavior to be defined for dealing with NACKs.
Also Feedback Suppression message can work without receiving NACKs sent from receiver. Using NACK for packet loss report from some dedicated receiver is
just a way for the distribution source or intermediate node to detect packet loss. But it is not the only way.

Regards!
-Qin
  ----- Original Message ----- 
  From: Van Caenegem, Tom (Tom) 
  To: Qin Wu ; [email-masked] 
  Sent: Tuesday, October 19, 2010 9:26 PM
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

  Qin,

  focusing on just SSM arch: I quote from your earlier response:

  In this draft, the loss detector is just functionality of DS.  Furthermore we only consider the loss detector as part of feedback target within the distribution source. Also this is just one example use case to explain how feedback suppression works in SSM use case.

  Again, your draft does explain in detail how feedback suppression works for a SSM as described here above, but does not address the RAMS case (which assumes a single DS, one or multiple disjoint FTs, where a FT is co-positioned with a BRS (same IP address). 

  Just consider a DS with multiple disjoint FTs (as in RAMS, and also permitted by RFC 5760). Typically each FT is connected to a different branch of the SSM tree. 

  Currently your draft imposes that the feedback suppression message is sent by the DS over the SSM. This is not a good solution as you either restrict the solution to packet losses that are common to all SSM RTP receivers (covering packet loss between media source and DS ) or you will send suppression indications (and optionally forthcoming retransmission) to all receivers even if some did not suffer from packet loss. Therefore the draft should also define how suppression information is sent to (a subset of) the receivers. It does not make sense to me that IETF would define FB suppression for a architecture that does not take into account deployed SSM architectures for IPTV.

  Even within the SSM architecture you are focusing on, I am very much confused: you say there is one DS that hosts the FT and loss reporting function. What is then the role of the intermediate sources downstream of the DS? I really would appreciate you illustrate with some more architecture drawings.

  The other point I still am not convinced of, is  the use of NACK versus dedicated suppression message. There should be more clarity in the different architectures you consider before we can make any statements on whether having a NACK or FIR  that is used as suppression message towards the SSM receivers, is confusing or not. I do not disagree that NACK as defined in RFC 4588 cannot be used as suppression message. But if we define it this way in a this "suppression"  draft/RFC, and no confusions can occur, I do not see the issue, especially as the syntax of the suppression message is completely the same as a NACK/FIR. 

  Regards
  Tom

------------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Wed, 20 Oct 2010 11:46:08 +0800

Tom:
I get your concern now. The RAMS architecure in your mind is one media source-> one distribution source -> multiple BRS in parallel-> the recievers behind each BRS.
In this scenario one distribution source is placed between media source and BRS for relaying SSM stream from media source. The BRS will receive the SSM stream from the DS. Suppose there are several BRSes behind the distribution source or media source, there may be just one BRS that detects packet loss on its upstream link between the distribution source and BRS, but the others will perhaps not, as the packet loss took place on SSM tree branch that does not impact the other BRSes. 

In this case, event the distribution source with loss detection functionality support can not detect packet loss at the downstream of itself, therefore the distribution source SHOULD NOT create new Feedback Suppression message and send it to all the BRS. In order to address this case, If BRS has loss detection support, the BRS MAY choose to create new  Feedback Suppression message and send it to the receivers behind this BRS.

In this way, the packet loss took place on SSM tree branch will not impact other BRSes.
Hope this clarifies.

BTW: I can add this use case to address your concern in the new version.

Regards!
-Qin
  ----- Original Message ----- 
  From: Van Caenegem, Tom (Tom) 
  To: Roni Even ; 'Qin Wu' ; [email-masked] 
  Sent: Tuesday, October 19, 2010 11:30 PM
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

  Hi Roni,

  In the typical RAMS architecture, the BRS will receive the SSM stream from the DS. If there are several BRS-es, there may be just one BRS that detects packet loss on its upstream link, but the others will perhaps not, as the packet loss took place on SSM tree branch that does not impact the other BRSes. In that case those RTP receivers associated to the other BRS-es in general will not be impacted and do not need to receive the suppression indication, while the one BRS that did sense the packet loss should probably best send a suppression indication (although there is a chance that only this BRS is impacted by packet loss, and not a single RTP receiver in the field reporting to this BRS/FT... this all depends on the considered topologies). 

  As a BRS is 1-to-1 associated with a FT, this calls for consideration of architectures with (multiple) disjoint FT (and associated BRS in RAMS applications)  in the suppression draft. Such disjoint FT/BRS in general cannot act as so-called "intermediate nodes" or "translators" because they are not on the direct SSM path between the DS and the RTP receivers. 

  Another aspect I want to highlight is that feedback suppression is closely aligned with retransmission. In the case described above, the one BRS that detected packet loss on its upstream link, may try to recover the missing packet (outside the scope of the draft) and retransmit over multicast to the receivers that report to the FT. This retransmission towards the receivers is also outside the current scope of the current draft, but the two are somehow linked.  In DVB IPTV, we introduced dedicated SSMs sourced by the BRS for sending NACK suppression and the (optional) retransmission. In the considered scenario, having a DS sending a missing packet -reported by a FT downstream in the SSM tree- over the original SSM is not a good approach IMO, as it results in general in unnecessary retransmissions for most receivers.

  Hope this clarifies.

  Tom

  From: Roni Even [mailto:[email-masked]] 
  Sent: dinsdag 19 oktober 2010 16:46
  To: Van Caenegem, Tom (Tom); 'Qin Wu'; [email-masked]
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

  Hi Tom,

  I want to clarify your example since I am not sure what is special here. The BRS sends separate unicast streams to each participant so there is reason for suppression on these unicast streams. As for the primary multicast stream from the DS it goes to all receivers. Now if the BRS identify packet loss on the primary stream it should send suppression indication to all members of the multicast group regardless to which FT they report.

  Can you clarify

  Roni Even