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

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 18 Oct 2010 18:08:15 +0200

Hi Qin,

I have some comments (look for TOM below) on the new draft version 4.
Thx for addressing them,
Tom

Section 2 Terminology

 Loss Detector:

      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.

 The function of the loss reporter may be collocated with
      or integrated into the same entity.

TOM (1): ..same entity as what? i guess you mean the DS?

TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that?

section 3

(..)

In order to detect packet loss before the receivers perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.

TOM (3) : ...based on the two above definitions ...is an intermediate node hence equal to a "Loss detector"?
+ How does a Loss detector differ from an RTP receiver?

Section 6.1

In order to avoid the forms of NACK implosion described in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.

TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)".

TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.

TOM (6):  What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?

Section 6.1.1

If there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.

TOM (7) : how will the DS send only a copy of the RTCP FB report packet to the group impacted by packet loss. Is this done over the SSM?

In your example you seem to focus only on architectures with a DS which also hosts the FT and the loss reporter.  There should be sections covering cases where the DS is disjoint from the FT, with several FTs and also several loss reporters disjoint from the FT and the DS.

TOM (8) : what do you mean in above text with "RTCP FB report".. is that the suppression message you define in this draft?

TOM (9) : In section  "6.1.2.  Distribution Source Feedback Summary Model" it is not clear what your architecture looks like. You talk about multiple distribution sources.. whcih implies multiple SSMs.. Can you elaborate on that?

Tom (10) :  In section  6.3.  Multipoint Control Unit (MCU) use case,  typically an overlay of unicast is used... will the Feedback suppression message be sent over unicast as well? If so, what is gain compared to just having each RTCP receiver providing each their NACK to the MCU, even in case of a packet loss impacting all receivers?

Tom (11) : coming back to my previous comment on SDP description in this draft : if this draft defines a RTCP feedback suppression message, why is there need for a "announcement" in the SDP for the receivers, that indicates they may receive such feedback suppression messages?  If a receiver supports the message, it will  simply act accordingly as described in the draft, no need to announce that!..

Regards
Tom

---

From: Qin Wu <[email-masked]>
Date: Tue, 19 Oct 2010 11:04:05 +0800

Hi, Tom:
Thank for your comments, please see my reply inline.

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

  Hi Qin,

  Section 2 Terminology
 Loss Detector:

      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.
 The function of the loss reporter may be collocated with
      or integrated into the same entity.TOM (1): ..same entity as what? i guess you mean the DS?[Qin]: Your are right.  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.TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that?[Qin]:  Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port.section 3 (..)In order to detect packet loss before the receivers perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.
TOM (3) : ...based on the two above definitions ...is an intermediate node hence equal to a "Loss detector"?  
  + How does a Loss detector differ from an RTP receiver?
  [Qin]: The loss detector is just one functionality of Distribution Source in the SSM use case.
  Maybe we should interpret it as "Loss detection functionality". How the packet loss is detected is out of scope of this document.
  Different from dedicated RTP receiver, the intermediate node does not depend on existing NACK message for Retransmission request for packet loss.
  the intermediate node can create message by itself.

  Section 6.1
   receivers.TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it.TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.[Qin]: As I said above,  Loss detector is just functionality of some Distribution sources.  Also what it said here in section 6.1 is just one example use case.TOM (6):  What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?[Qin]: As I explained in the last IETF presentaion,  this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation.Section 6.1.1If there are multiple Loss Detectors looking at the same RTP stream,

  [Qin]: Sorry, maybe I sould say 
  "
  Section 6.1.1
  If there are multiple Distrbitution Source with the loss detection support looking at the same RTP stream.....
  "
  Yes,  in the SSM use case, DS send only a copy of the RTCP Feedback Suppression Report packet the group via SSM.

  [Qin] I am not sure we need to address all the possible SSM use cases. In this draft, we just give some examples of SSM use case.

  [Qin]: Yes,  RTCP Feedback Suppression Report. 

  [Qin]:  The scenario we are talking about in  the section 6.1.2, is to  allow multiple Distrbituion source between media source and the receiver. I will look at the this case as one special SSM case. because  each of distrbituion source resides at the upstream direction or downstream direction of other distributions souces. Does it make sense?

  [Qin]: First The MCU case will not cause NACK Implosion, instead, it may cause FIR implosion.
             Second, using Feedback suppression message can restrict the FIR message sent from receivers behind MCU and liberate the media source from  FIR implosion.

  [Qin]: Okay, I get your point. I would like to put this as open issue, discuss it in the face to face IETF meeting.

  Regards
  Tom

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 19 Oct 2010 10:26:45 +0200

Hi Qin,

Thank you for your reply.

Reading your responses,you seem to focus really on the SSM  case with an architecture where the single DS (there can be only one DS per SSM) hosts the sole feedback target, which also hosts the loss detector function. My interpretation is also that in your draft the loss detector sends the FIR or NACK supression message to the DS, which then forwards/relays this message over the SSM to all receivers, right?

My main comment remains the same: you should at least incorporate the architecture of RAMS (where there can be several FT  colocated with the BRS, which are disjoint from the DS). In this case the FT/BRS should be able to provide a suppression indication to all receivers that report to this FT (which is a subset of all receivers that connect to the SSM), which means one should not make use of the (original) SSM for providing the suppression indication.  Your draft provides a possible solution for only a limited use case, and not the most interesting one, IMO.

Further down some responses to your answers below.

Tom

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

Hi, Tom:

Regards!
-Qin
----- Original Message -----
From: Van Caenegem, Tom (Tom)<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; Qin Wu<mailto:[email-masked]>
Sent: Tuesday, October 19, 2010 12:08 AM
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,

Section 2 Terminology

 Loss Detector:

[Qin]: Your are right.  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.

[Qin]:  Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port.

section 3

(..)

Section 6.1

[Qin]:Sorry, I can't get it.

TOM: this is really a detail. If you want to keep the sentence, you should e.g. say: "How the loss detector can detect the packet loss...

[Qin]: As I said above,  Loss detector is just functionality of some Distribution sources.  Also what it said here in section 6.1

is just one example use case.

[Qin]: As I explained in the last IETF presentaion,  this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation.

TOM: As your assumption is that the loss reporter is part of the FT that is part of the DS, then there is even no need to specify how the loss detector

reports the packet loss.  In the more generic case, it makes more sense to me that the loss reporter just uses a NACK (or a FIR) if it detects packet loss, sent towards its FT or to the DS if this one hosts the FT that the loss detector reports to . It is then up to the FT or the DS to decide whether this message triggers a NACK or FIR suppression

indication to (s subset of) the receivers.  This suppression indication does not necessarly require a new message format. A NACK/FIR  that is sent to a RTP receiver can be defined as a feedback suppression indication. I do not see a good use case why NACKs from  receivers  would be reflected back in e.g. SSM use case by DS or FT  to all the connected receivers.

If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression indication, there is no ambiguity possibly.

Section 6.1.1

TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that, you probably need to address and define this architecture in a better way in your draft.

TOM: it is not important whether this is about FIR or NACK. My point is that iso having each receiver sending a NACK/FIR, you will now have to send to each receiver a NACK/FIR  suppression in the given scenario. There are no differences in terms of Bandwdith overhead or server load in the two cases, so why bother to send suppression messages?

Regards
Tom

---

From: Qin Wu <[email-masked]>
Date: Tue, 19 Oct 2010 18:50:01 +0800

Hi, Tom:

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

  Hi Qin,

  [Qin]: SSM case is just one example case in this draft. We have also discussed Transport translator use case and MCU use case. This draft focus on how the feedback suppression works in these different use cases.
  For the SSM use case, we may consider multiple distribution sources placed between media source and the receiver. The loss detector is just one functionality of Distribution source, or Retransmission Server or MCU, or Transport Translator. It does not have to be put as part of feedback target. I propose to remove the stuff of "Loss detector" from this draft, instead, using Distribution source with loss detection support. What do you think of it?

  [Qin]: I think RAMS case is just one special case of SSM use case. how Feedback suppression works for SSM use case therfore is quite similar to RAMS, the only difference is Distrbituion source in the SSM case is replaced with
  BRS in the RAMS. As regarding another RAMS case where several FTs separated from BRS,   we can address this case if there are strong interests. 
  But to be clear, this draft focus on how Feedback suppression message works in different use case, not for one specific use case.

  Tom

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

  Hi, Tom:

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

    Hi Qin,

    Section 2 Terminology
 Loss Detector:

    Section 6.1
   receivers.TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it. TOM: this is really a detail. If you want to keep the sentence, you should e.g. say: "How the loss detector can detect the packet loss... [Qin]Okay.TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.[Qin]: As I said above,  Loss detector is just functionality of some Distribution sources.  Also what it said here in section 6.1 is just one example use case.TOM (6):  What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?[Qin]: As I explained in the last IETF presentaion,  this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation. TOM: As your assumption is that the loss reporter is part of the FT that is part of the DS, then there is even no need to specify how the loss detector reports the packet loss.  In the more generic case, it makes more sense to me that the loss reporter just uses a NACK (or a FIR) if it detects packet loss, sent towards its FT or to the DS if this one hosts the FT that the loss detector reports to . It is then up to the FT or the DS to decide whether this message triggers a NACK or FIR suppression indication to (s subset of) the receivers.  This suppression indication does not necessarly require a new message format. A NACK/FIR  that is sent to a RTP receiver can be defined as a feedback suppression indication. I do not see a good use case why NACKs from  receivers  would be reflected back in e.g. SSM use case by DS or FT  to all the connected receivers. If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression indication, there is no ambiguity possibly.    [Qin]: To me, NACK is uesed to request packet loss retransmission from the server, NACK has no scemantics for feedback suppression. the intermediate node e.g., distributionsource will confus whether the NACK should be forwarded to the server or the receiver.unlike NACK, Feedback Suppression message defined in this draft is used by the intermediate node/middlebox to notify all the receiver that sending NACK may be not necessary and harmful.the intermediate node will know how to deal with the Feedback Suppression message and will not cause scemantics confusion like receiving NACK.One important thing is Feedback suppression can be used without receiving ANY NACKs. that is why many people think we should define new message althugh the new message has the similar format as NACK.Therefore I think using NACK sent from some dedicated receiver is just one way for the distribution source to know packet loss happen. But not the only way.Section 6.1.1If there are multiple Loss Detectors looking at the same RTP stream,

    [Qin]: Okay.

    [Qin]: No, one effective use case is suppose packet loss can not repaired, the MCU can use feedback suppression message to tell the receiver not ask for lost packet.

    Regards
    Tom

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 19 Oct 2010 15:26:18 +0200

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

Sent: dinsdag 19 oktober 2010 12:50

Hi, Tom:

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

Hi Qin,

Tom

Hi, Tom:

Regards!
-Qin
----- Original Message -----
From: Van Caenegem, Tom (Tom)<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; Qin Wu<mailto:[email-masked]>
Sent: Tuesday, October 19, 2010 12:08 AM
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,

Section 2 Terminology

 Loss Detector:

section 3

(..)

Section 6.1

 [Qin]Okay.

 [Qin]: To me, NACK is uesed to request packet loss retransmission from the server, NACK has no scemantics for feedback suppression. the intermediate node e.g., distribution

source will confus whether the NACK should be forwarded to the server or the receiver.

unlike NACK, Feedback Suppression message defined in this draft is used by the intermediate node/middlebox to notify all the receiver that sending NACK may be not necessary and harmful.

the intermediate node will know how to deal with the Feedback Suppression message and will not cause scemantics confusion like receiving NACK.

One important thing is Feedback suppression can be used without receiving ANY NACKs.

that is why many people think we should define new message althugh the new message has the similar format as NACK.

Therefore I think using NACK sent from some dedicated receiver is just one way for the distribution source to know packet loss happen. But not the only way.

Section 6.1.1

[Qin]: Okay.

Regards
Tom

---

From: Roni Even <[email-masked]>
Date: Tue, 19 Oct 2010 16:45:50 +0200

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Van
Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27 AM
To: Qin Wu; [email-masked]
Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,

Reading your responses,you seem to focus really on the SSM  case with an
architecture where the single DS (there can be only one DS per SSM) hosts
the sole feedback target, which also hosts the loss detector function. My
interpretation is also that in your draft the loss detector sends the FIR or
NACK supression message to the DS, which then forwards/relays this message
over the SSM to all receivers, right?  

My main comment remains the same: you should at least incorporate the
architecture of RAMS (where there can be several FT  colocated with the BRS,
which are disjoint from the DS). In this case the FT/BRS should be able to
provide a suppression indication to all receivers that report to this FT
(which is a subset of all receivers that connect to the SSM), which means
one should not make use of the (original) SSM for providing the suppression
indication.  Your draft provides a possible solution for only a limited use
case, and not the most interesting one, IMO.  

Tom

  _____  

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

Hi, Tom:

Regards!

-Qin

----- Original Message ----- 

From:  <mailto:[email-masked]> Van Caenegem, Tom (Tom) 

To:  <mailto:[email-masked]> [email-masked] ;  <mailto:[email-masked]> Qin
Wu 

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

Hi Qin,

Thx for addressing them,

Tom

Section 2 Terminology

 Loss Detector:
 
      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.
 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same entity as what? i guess you mean the DS?
[Qin]: Your are right.  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.
TOM (2): I do not understand how you associate the port k to a loss
detector.. what do you mean with that?
[Qin]:  Sorry for ambiguity of the description here. It actually means that
the loss reporter is part of feedback target and share the same address and
port.
section 3
 
(..)

TOM (3) : ...based on the two above definitions ...is an intermediate node
hence equal to a "Loss detector"?  

[Qin]: The loss detector is just one functionality of Distribution Source in
the SSM use case.

Maybe we should interpret it as "Loss detection functionality". How the
packet loss is detected is out of scope of this document.

Different from dedicated RTP receiver, the intermediate node does not depend
on existing NACK message for Retransmission request for packet loss.

Section 6.1

TOM (4) : You probably do not want to have normative language in section
6.1, like "How the loss detector SHOULD (..)". 
TOM: this is really a detail. If you want to keep the sentence, you should
e.g. say: "How the loss detector can detect the packet loss...

TOM (5) : It is pretty clear how a Loss detector will detect packet loss on
its upstream link, I guess.
[Qin]: As I said above,  Loss detector is just functionality of some
Distribution sources.  Also what it said here in section 6.1 
is just one example use case.
TOM (6):  What is the rationale for a loss detector to send a Feedback
suppression message to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained in the last IETF presentaion,  this cause NACK
scematics mismatch. That's why many people in the last IETF meeeting suggest
to create new RTCP message during presentation. 
 
TOM: As your assumption is that the loss reporter is part of the FT that is
part of the DS, then there is even no need to specify how the loss detector 
reports the packet loss.  In the more generic case, it makes more sense to
me that the loss reporter just uses a NACK (or a FIR) if it detects packet
loss, sent towards its FT or to the DS if this one hosts the FT that the
loss detector reports to . It is then up to the FT or the DS to decide
whether this message triggers a NACK or FIR suppression 
indication to (s subset of) the receivers.  This suppression indication does
not necessarly require a new message format. A NACK/FIR  that is sent to a
RTP receiver can be defined as a feedback suppression indication. I do not
see a good use case why NACKs from  receivers  would be reflected back in
e.g. SSM use case by DS or FT  to all the connected receivers. 
If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP
receiver, if this is for suppression indication, there is no ambiguity
possibly.   

Section 6.1.1

TOM (7) : how will the DS send only a copy of the RTCP FB report packet to
the group impacted by packet loss. Is this done over the SSM? 

"

Section 6.1.1

If there are multiple Distrbitution Source with the loss detection support
looking at the same RTP stream.....

"

Yes,  in the SSM use case, DS send only a copy of the RTCP Feedback
Suppression Report packet the group via SSM.

In your example you seem to focus only on architectures with a DS which also
hosts the FT and the loss reporter.  There should be sections covering cases
where the DS is disjoint from the FT, with several FTs and also several loss
reporters disjoint from the FT and the DS.

[Qin] I am not sure we need to address all the possible SSM use cases. In
this draft, we just give some examples of SSM use case.

TOM (8) : what do you mean in above text with "RTCP FB report".. is that the
suppression message you define in this draft?

TOM (9) : In section  "6.1.2.  Distribution Source Feedback Summary Model"
it is not clear what your architecture looks like. You talk about multiple
distribution sources.. whcih implies multiple SSMs.. Can you elaborate on
that?

[Qin]:  The scenario we are talking about in  the section 6.1.2, is to
allow multiple Distrbituion source between media source and the receiver. I
will look at the this case as one special SSM case. because  each of
distrbituion source resides at the upstream direction or downstream
direction of other distributions souces. Does it make sense? 

TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that,
you probably need to address and define this architecture in a better way in
your draft. 

Tom (10) :  In section  6.3.  Multipoint Control Unit (MCU) use case,
typically an overlay of unicast is used... will the Feedback suppression
message be sent over unicast as well? If so, what is gain compared to just
having each RTCP receiver providing each their NACK to the MCU, even in case
of a packet loss impacting all receivers?

[Qin]: First The MCU case will not cause NACK Implosion, instead, it may
cause FIR implosion.

           Second, using Feedback suppression message can restrict the FIR
message sent from receivers behind MCU and liberate the media source from
FIR implosion. 

TOM: it is not important whether this is about FIR or NACK. My point is that
iso having each receiver sending a NACK/FIR, you will now have to send to
each receiver a NACK/FIR  suppression in the given scenario. There are no
differences in terms of Bandwdith overhead or server load in the two cases,
so why bother to send suppression messages?

Tom (11) : coming back to my previous comment on SDP description in this
draft : if this draft defines a RTCP feedback suppression message, why is
there need for a "announcement" in the SDP for the receivers, that indicates
they may receive such feedback suppression messages?  If a receiver supports
the message, it will  simply act accordingly as described in the draft, no
need to announce that!.. 

[Qin]: Okay, I get your point. I would like to put this as open issue,
discuss it in the face to face IETF meeting.

Regards

Tom

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 19 Oct 2010 17:30:50 +0200

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Van Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27 AM
To: Qin Wu; [email-masked]
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,

Tom

Regards!
-Qin
----- Original Message -----
From: Van Caenegem, Tom (Tom)<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> ; Qin Wu<mailto:[email-masked]>
Sent: Tuesday, October 19, 2010 12:08 AM
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,

Section 2 Terminology

 Loss Detector:

section 3

(..)

   specification.

Section 6.1

   receivers.

Section 6.1.1

   loss.

Regards
Tom

---

From: Roni Even <[email-masked]>
Date: Tue, 19 Oct 2010 18:00:33 +0200

Hi Tom,

In the current RAMS there is no way for the BRS to send a suppression
indication , the only available way is in the main SSM stream. I think that
such BRS will be reporting nodes to the DS in the simple case. Are you
suggesting that we define a new SSM session that will be initiated by the
BRS. I think this will make more sense if we also address the retransmission
support you described since the SSM session will serve for the
retransmission.

Currently this part is not in scope but we may ask the WG if they want to
add this specific scenario

Roni Even

From: Van Caenegem, Tom (Tom) [mailto:[email-masked]] 
Sent: Tuesday, October 19, 2010 5:31 PM
To: Roni Even; 'Qin Wu'; [email-masked]
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

  _____  

Subject: RE: [AVT] New Version Notification for

Hi Tom,

Can you clarify

Roni Even

Hi Qin,

Tom

  _____  

Hi, Tom:

Regards!

-Qin

----- Original Message ----- 

Hi Qin,

Thx for addressing them,

Tom

Section 2 Terminology

 Loss Detector:

(..)

Section 6.1

 

Section 6.1.1

"

Section 6.1.1

"

 

Regards

Tom

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Oct 2010 22:54:10 +0100

Roni, Tom,

I'd recommend moving the discussion away from specific scenarios to the extent possible, and focussing on the general mechanism. Yes, the draft should give examples of how retransmission suppression is used with the RAMS scenario, and probably with other scenarios, but those are just examples of how to use the general mechanism. If the semantics of that general mechanism are well-defined, then how it's used for the specific scenarios should become clearer.

Colin

On 19 Oct 2010, at 17:00, Roni Even wrote:
> Hi Tom,
> In the current RAMS there is no way for the BRS to send a suppression indication , the only available way is in the main SSM stream. I think that such BRS will be reporting nodes to the DS in the simple case. Are you suggesting that we define a new SSM session that will be initiated by the BRS. I think this will make more sense if we also address the retransmission support you described since the SSM session will serve for the retransmission.
> Currently this part is not in scope but we may ask the WG if they want to add this specific scenario
>  
> Roni Even
>  
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/