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

[Roni Even <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Van
Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27 AM
To: Qin Wu; [e-mail]
Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

 

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:[e-mail]] 
Sent: dinsdag 19 oktober 2010 5:04
To: Van Caenegem, Tom (Tom); [e-mail]
Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:

Thank for your comments, please see my reply inline.

 

Regards!

-Qin

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

From:  <mailto:[e-mail]> Van Caenegem, Tom (Tom) 

To:  <mailto:[e-mail]> [e-mail] ;  <mailto:[e-mail]> 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,

 

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?
[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

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 (..)". 
[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...
 
 
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
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? 

 

[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.

 

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?

 

[Qin]: Yes,  RTCP Feedback Suppression Report. 

 

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