Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 1 Sep 2011 16:52:19 +0200

Hi,

I have reviewed this last version and have some comments.

1. Why is the copyright boilerplate indicating that there is copyrighted
material that is from prior to 2008 change of the boiler plate? Can you
please point to what material that exist in the document that is prior
to this change and where the authors has been unable to acquire the rights?

I think we really should avoid using the exception if there is no reason
for it. Otherwise we just make the future reference puzzle that more
difficult.

2. Section 3, second paragraph.
Lack of space after RFC4585 reference.

3. Section 3, third paragraph:
Systems that
   receive a Third Party Loss Report SHOULD NOT initiate their own
   additional Third Party Loss Report messages for the same packet
   sequence numbers.

Is it really systems, isn't it rather Intermediaries that this sentence
applies to? If you are an end-point you have no down stream direction to
send the TPLR message to. And if you sent it upstream or to a feedback
target that is a different action. OR should system say "RTP node" if it
truly should apply to all RTP nodes?

4. Third paragraph:

or they may generate their own Third Party Loss
   Report that reports a set of the losses they see, which are different
   from ones reported in the Third Party Loss report they received.

What about the original Third party loss report message, should that be
suppressed, or still be forwarded?

5. Section 3, fourth paragraph:
I am trying to get my head around the implications of not being explicit
about the time feedback suppression lasts. And I don't quite get how it
works from either side.

As the sender of of Third party loss report, the first message is pretty
straight forward. It suppresses all receiver that get it for one of
their Retransmission timeout intervals. As a sender I have no idea how
long that interval are in the various receivers implementations. It is
likely a RTT + some fudge time for the source being reported. The issue
is that the RTT to the orignal source, rather than the third party
reporting the loss is quite different, thus not reflecting the interval
before the Third party expects to get the packet for forwarding.

The next question is if and in that case when the node should send an
additional TPLR message. Should it wait for receiving a first NACK and
expect a storm of others before the suppression has reached the others.
Should it try to estimate the lowest suppression time to any of the down
stream receivers?

As a receiver, when I receive an additional TPLR message, do I
immediately restart the timer, or do I wait until the timer expires and
then refreshes it for one new interval?

I think there need to be significant clarification on the nodes behavior
regarding how long the suppression works and how to deal with additional
messages.

6. Section 4.1, second paragraph:

   The FCI field MUST contain one or more entries of transport layer
   third party loss Early Indication (TLLEI).  Each entry applies to a
   different media source, identified by its SSRC.

Something is wrong here. There is no SSRC field in the FCI format
depicted in figure 1. Despite that each entry reports on different media
streams. So there needs to either a clarification that the entry formats
are an SSRC plus the PID+BLP word. Or the last sentence in above quote
needs to be changed.

In addition this section is clearly missing clarification on how the
SSRC field in the feedback header is used. Although I have to say for
once the fields name is quite suitable and reasonably clear.

7. Section 4.2:

The FCI part specification is not updated to reflect the PSLEI usages.
First of all the SSRC field, would be of the source for which it is not
necessary to request video fast update from. Secondly, I don't see how
the sequence number is used in this case. It made quite a lot of sense
in the case of requesting video updates as one needs to distinguish
retransmissions that might be in flight from new updates. I don't see
that being necessary here, where a suppression is a suppression.

A third question is, does the same timing rules apply to this case
compared to loss? If one only uses this format and not retransmission,
then one may not have the same retransmission request logic.

8. Section 8.

The registrations that needs to happens are first of all the FMT values
for the two formats. One in "FMT Values for RTPFB Payload Types"
registry, the second one in "FMT Values for PSFB Payload Types".

Then the three registrations provided seems to be in the wrong format.
What I understand they are intended for the registries on the
http://www.iana.org/assignments/sdp-parameters page.

The first one is for "rtcp-fb" Attribute Values". The second and third
that currently exist, should be part of a registry creation request,
similar to what is in Codec Control Messages RFC 5104 IANA considerations.

9. Section 10.1:

I wonder is really RFC 5117 a normative reference? The reason is that is
an informational RFC.

I haven't finished reviewing section 6 and 7 and will send a follow up
when that is done.

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 05 Sep 2011 12:06:48 +0800

Hi, Magnus:
Thank for your valuable review. please see my replies below.

>----- Original Message ----- 
>From: "Magnus Westerlund" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Thursday, September 01, 2011 10:52 PM
>Subject: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

>for it. Otherwise we just make the future reference puzzle that more

[Qin]:Your are right. I am using the wrong copyright boilerplate. 
 IPR attribute in the "<rfc>" tag  within boilerplat should be set to 
"trust200902"instead of "pre5378Trust200902"

>Lack of space after RFC4585 reference.

[Qin]: fixed, thanks.

>truly should apply to all RTP nodes?

[Qin]:Firstly, I do not think it is important, the system can be RTP node. Secondly , 
I think TPLR message was not meant to be sent from downstream host end-point in upstream
Direction since sending TPLR message is used to suppress all the downstream host end points 
from sending unnecessary RTCP messages. The example of the system here can be media source 
or intermediaries. The RTP end device that is receiving RTP packet is not necessary to be counted
 as System. In order to avoid ambiguity, how about change system as
"RTP system in the network or RTP node in the network"?

>suppressed, or still be forwarded?

[Qin]: The original TPLR message receiving from upstream direction should be forwarded. 
But for the loss that is not reported in the original TPLR message, the intermediary should 
generate new TPLR to convey them.
It looks the current descrption doesn't reflect this very well. How about change as follows:
Original text:
"
They may either simply forward the Third Party
   Loss Report message, or they may generate their own Third Party Loss
   Report that reports a set of the losses they see, which are different
   from ones reported in the Third Party Loss report they received. 
"
New text:
"
They should simply forward the Third Party
   Loss Report message received from upstream direction, additionally, they may generate their own Third Party Loss
   Report that reports a set of the losses they see, which are different
   from ones reported in the Third Party Loss report they received. 
"

>before the Third party expects to get the packet for forwarding.

[Qin]: Firstly, the normal behavior of TPLR sender is the same as for sending a NACK and not
receiving a repair. I think that the paragraph was about the case when the
downstream receiver received a suppression message but expected to get a
repair packet w=even though it did not sent a NACK.

Secondly, it is true that the interval to get TPLR varies from different receivers implementation. 
However the senders of TPLR does not need to know how long it take for receiver to get TPLR 
message, instead the receiver should more concerns the interval to recieve TPLR from the sender 
of TPLR. In other words, upon being told about the packet loss, TPLR senders should immediately 
create, send TPLR to the recievers. The other intermediary between sender and receiver just simply 
forward TPLR message to the recievers. 

For reciever who concerns the interval, they should know how to choose appropirate interval for timer. 
one way is to choose the longest time to receive TPLR, i.e., one RTT to recieve TPLR from source since
 the media source also can be the sender of TPLR. Does this clarification make sense to you? 

>Should it try to estimate the lowest suppression time to any of the down

[Qin]: 
 In most case, the node in the middle does not need to send additional 
TPLR if upstream node has been told about all the packet loss event.
 Unless the upsteam node miss one or more than one packet loss, the
 node in the middle between upstream node and the receive may send 
additional TPLR. However same as the upstream node sending TPLR,
 the node in the middle does not need to wait for a certain time to send 
TPLR. upon been told about the loss and make sure the loss is not reported 
by upstream node, the node should create and send additional TPLR immediately. 
Does it make sense?

>then refreshes it for one new interval?

[Qin]: First, I think the reciever behavior follows the feedback suppression
 rule defined in RFC4585. secondly, I think the timer is restarted per each new loss, if the
 reciever receive additinal TPLR message, which report the different loss, the
 reciever should restart the timer immediately. However if additinal TPLR report 
the same loss as the previous TPLR, the receiver should wait untile the timer expires 
and then refreshes it for one new interval.

>are an SSRC plus the PID+BLP word. Or the last sentence in above quote

[Qin]:I believe it should be latter. 
Adding SSRC plus the PID+BLP is not as in
 http://tools.ietf.org/html/rfc4585#section-6.2.1
. My proposed change to the second paragraph of section 4.1
 is to remove the last sentence in second paragraph.

>once the fields name is quite suitable and reasonably clear.

[Qin]: If we agree all the entries in FCI format share the same SSRC of 
media source, then it is clear the SSRC field in the feedback header is 
set to what it is.
However if you think we can add multiple entries of TLLEI, each entry 
is identified by an SSRC,
Then I think SSRC of media source field should not be used and set to 
zero. So the open question is we may have two choice for the format of transport layer feedback:
1.  No SSRC field in FCI format and all the entries share the same SSRC 
defined in the SSRC of media source field of Feedback header
2. FCI contain multiple entries, each entry is identified by an SSRC. The 
SSRC of media source field of Feedback header is set to zero. 

Which one is more appropriate?

>The FCI part specification is not updated to reflect the PSLEI usages.

[Qin]: The PSLEI usages is reflected in the section 6.2 as an example.

>that being necessary here, where a suppression is a suppression.

[Qin]: You are right, the intermediary knows the SSRC of the source
from which it request to send a decoder refresh point and will tell the 
receivers to not send a FIR to this source. The sqn is not needed.

>then one may not have the same retransmission request logic.

[Qin]: The receiver should not send a FIR but behave as if it did
expecting to get a synchronization point the same as if it did sent a FIR
(no behavior change for receiver)
Does this answer your question?

>similar to what is in Codec Control Messages RFC 5104 IANA considerations.

[Qin]:I think you are right and will follow your advice.

>I wonder is really RFC 5117 a normative reference? The reason is that is

[Qin]: Okay, I will put it as informative reference.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Sep 2011 09:58:53 +0200

> "trust200902"instead of "pre5378Trust200902"

good.

> "RTP system in the network or RTP node in the network"?

I agree with the intention of not sending them upstream. Which boils
this down to finding the right place and right wording to ensure that
this is captured in a clearly understandable form.

I don't like RTP system in the network. Maybe keeping it simple and
replacing "Systems" with "RTP node" is the most straight forward in this
sentence.

>    from ones reported in the Third Party Loss report they received. 

Much clearer.

>  the media source also can be the sender of TPLR. Does this clarification make sense to you? 

Well, but if you are a Intermediary that forwards upstream RTP packets
onto a multicast segment and at the same time buffers them for
retransmission. Then when that Intermediary detects a loss upstream of
itself it might want to send a TPLR as soon as it is pretty certain of
that loss downstream to avoid the receivers sending NACK on something it
can't repair. And in that case, it is difficult to determine how often
it should be repeated while it is still not received or repaired.

> by upstream node, the node should create and send additional TPLR immediately. 

I still don't know how often I need to send them to ensure that I don't
get NACKs from my receivers.

> and then refreshes it for one new interval.

I personally think refreshing the timer immediately in both cases might
be both simpler and work better. Especially as the sender of an update
then knows that it is one interval from the reception of the new TPLR,
and not two intervals since the first one. As the length of the interval
is not known it is difficult to know when receivers will approximately
resume sending NACKs.

>  is to remove the last sentence in second paragraph.

That is fine with me.
> Which one is more appropriate?

I think 1 is the most appropriate in this case. Most of the application
scenarios for TPLR is where you will have few SSRCs but potentially a
lot of packets.

> [Qin]: The PSLEI usages is reflected in the section 6.2 as an example.

I think the above was intended as general comment and then diving into
the details.

> receivers to not send a FIR to this source. The sqn is not needed.

Agree

> Does this answer your question?

Yes, but you might have to point out the timing rules that applies.

>> I haven't finished reviewing section 6 and 7 and will send a follow up

Still not done with this part. Will try to follow up soon.

cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Wed, 07 Sep 2011 11:28:17 +0800

Hi,Magnus:
Please see my replies below. Hope it address your remaining comments.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 06, 2011 3:58 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin]: Okay.

[Qin]: I get your point. As I said, the behavior of intermediary for sending TPLR could be the same as one for sending a NACK.

In case of the loss of TPLR, the intermediary may send another TPLR for the same packet loss event. 

Before sending the another TPLR, the intermediary may rely on a timer to ensure that the attempt to send first TPLR for suppression

has failed and so avoid unnecessary resending new TPLR for the same packet loss. 

The timer can be based on observed round-trip time measured from intermediary to the receiver. The estimate of the round-trip time 

(RTT) to the receiver can be calculated based on past observations, RTCP report round-trip time. Does this address your comment?

Another case in my mind is how often to send a TPLR for different packet loss in case there is no loss of TPLR or of retransmission packet. 

In this case, the intermediary can follow the same timing rule of sending NACK defined in RFC4585. i.e., The TPLR message may be sent 

in a regular full compound RTCP packet or in an early RTCP packet, as per AVPF.

[Qin] See above.

[Qin]: I agree with you. In the case the first TPLR is lost and the second TPLR arrives 
at the receiver, the receiver should immediately refresh the timer. In the case the first 
TPLR is not lost and the second TPLR for different packet loss event arrives at the receiver, 
the receiver should immediately start a new timer for the second TPLR. The length of the interval 
can be estimated based on past observation or RTCP report round-trip time or other means. 
Does it make sense to you?

That is fine with me.

[Qin]: Okay, I will do some wordsmith to this part.

[Qin]: Agree and will follow option (1).

[Qin]: I see.

Agree

[Qin]: Okay, I will remove sqn field from the message format.

[Qin]: Okay.

cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Wed, 7 Sep 2011 22:10:50 +0100

On 1 Sep 2011, at 15:52, Magnus Westerlund wrote:
...
> I am trying to get my head around the implications of not being explicit about the time feedback suppression lasts. And I don't quite get how it works from either side.
> 
> As the sender of Third party loss report, the first message is pretty straight forward. It suppresses all receiver that get it for one of their Retransmission timeout intervals. As a sender I have no idea how long that interval are in the various receivers implementations. It is likely a RTT + some fudge time for the source being reported. The issue is that the RTT to the orignal source, rather than the third party reporting the loss is quite different, thus not reflecting the interval before the Third party expects to get the packet for forwarding.
> 
> The next question is if and in that case when the node should send an additional TPLR message. Should it wait for receiving a first NACK and expect a storm of others before the suppression has reached the others. Should it try to estimate the lowest suppression time to any of the down stream receivers?

A TPLR is generally sent by a middlebox in response to a received NACK, in the case where that middlebox can't simply forward the NACK to other downstream receivers. Viewed this way, the TPLR takes the place of the NACK on the downstream path, and is sent when the NACK is received. The suppression of other NACKs would work in exactly as-if the middlebox forwarded the NACK, and the middlebox needs keep no special timers for the TPLR.

> As a receiver, when I receive an additional TPLR message, do I immediately restart the timer, or do I wait until the timer expires and then refreshes it for one new interval?

Doesn't the receiver just behave as if it had received a NACK? A TPLR is form of NACK packet, it's just slightly indirected. 

> I think there need to be significant clarification on the nodes behaviour regarding how long the suppression works and how to deal with additional messages.

Cheers,
Colin

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 9 Sep 2011 13:25:34 +0200

Hi,

Hera are my comments on section 6 and 7.

1. In 6.1 there are several cases of misplaced "." and commas.

2. Section 6.1, Second and Third paragraph: I find these paragraph far
from straight forward to interpret and not focused on the case when you
need to send TPLR. I think a better paragraph structure between the
cases would make this easier to read.

3. Section 6.2:

First of all the figure 3 doesn't make it clear that there are N RTP
receivers to the right in the figure.

4. Section 6.2:
"If the BRS impacted by packet loss has been told
   the actual packet loss, the BRS MAY choose to create new Third Party
   Loss Report message and send it to the receivers in the downstream
   link. "

I don't understand how the BRS can inject any message into the SSM tree,
as the source anchor of the SSM tree is up at the multicast source. Thus
a BRS needs to tell the distribution source to send something down
stream on its behalf.

5. Section 6.3:

I think some assumptions are missing in this case. If the translator
receive a NACK for a missing packet, why can't that be forwarded? I
don't see why you need a TPLR in this case.

6. Section 6.4:

As this is a poorly supported model in RTP, why is a use case built on
that? Shouldn't a RTP Mixer case be a better basis for building a FIR
suppression usage?

My understanding of a video stream switching RTP mixer is that it in
fact sends a FIR to the media source it is going to switch to prior to
actually switching. It doesn't switch until it actually has an I-frame
or similar decoder refresh point to switch on. Thus the actually
switching shouldn't be the cause for downstream FIR suppression. If the
receiver has packet loss, it should in fact send PLI, rather than FIR.

So I do wonder do we have a use case for suppressing FIR?

7. Section 7: "Sending the Third Party Loss Report with wrong sequence
number of
   lost packet that makes missing RTP packets can not be compensated."

What is the intention of this sentence? Is it to say that a erronous
TPLR will result in suppressing possibly lost packets that aren't
currently being attempted to be retransmitted or repaired?

8. Section 7:
"Also note that endpoints that receive a Third Party Loss Report would
   be well-advised to ignore it, unless it is authenticated via SRTCP or
   similar.  Accepting un-authenticated Third Party Loss Report can lead
   to a denial of service attack, where the endpoint accepts poor
   quality media that could be repaired."

Is this really a realistic limitation? Shouldn't it rather say that
don't use this unless you have security in place to authenticate the
sender of this type of RTCP Feedback messages?

Cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Sat, 10 Sep 2011 18:29:49 +0800

Hi, Magnus,
Thank for your comments, a quick reply below.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 09, 2011 7:25 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

Hi,

[Qin]: Fixed, thanks.

[Qin]: I Agree. Will restructure it in the new version.

3. Section 6.2:

[Qin]:True, Does it make sense to remove it? If not, will redraw it.

4. Section 6.2:

[Qin]: It is possbile for BRS to tell the distrbution source to send TPLR down on its BRS.
My question is
Is the BRS similar to Distribution source as an intermediary between multicast source and

 downstream receivers? Why BRS can not inject in between while Distribution Source can?

5. Section 6.3:

[Qin]: How about the following rephrasing:
OLD text:
"
   The translator can identify packet loss
   using co-located monitor [I-D.ietf-avtcore-monarch] by receiving a
   NACK from another system and then the monitor can use it's own SSRC
   as packet sender SSRC for transmitting the Third Party Loss Report
   message and send this message to the unicast receivers that is not
   aware of packet loss.

"
New Text:
"
The translator acting as quality monitoring may suffer a loss of 
important video packets. In this case, the translator may trigger
 repair by the media sender and tt the same time ,use it's own SSRC 
as packet sender SSRC to create a new Third Party Loss Report message 
and send it to the receivers that is not aware of packet loss.
"

6. Section 6.4:

[Qin]: I agree we can have a mixer use case for Feedback suppression.

 but I am a little confused. do you think MCU is poorly supported model 

or MCU use case for Feedback suppression is a poorly supported model?

[Qin]: It is true FIR SHALL NOT be sent as a reaction to picture losses
However according to four paragraph, section 4.3.1.2 of RFC5104, FIR 

can beSHOULD be used in situations where not sending a decoder refresh 

point would render the video unusable for the users. Therefore large number of

participants may send FIR to ask for decoder reshresh point rather than packet

 loss at the same time. Am I wrong?

[Qin]: Do you think we need a use case for suppressing PLI?

[Qin]:Yes.

8. Section 7:

[Qin]:Yes, it makes sense to me. Will reword it.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Sep 2011 16:22:53 +0200

Hi,

Removed the issues where I have no more comments.

See inline

On 2011-09-07 05:28, Qin Wu wrote:
> From: "Magnus Westerlund" <[email-masked]
> <mailto:[email-masked]>>
> To: "Qin Wu" <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>;
> <[email-masked]
> <mailto:[email-masked]>>
>>> From: "Magnus Westerlund" <[email-masked]
> <mailto:[email-masked]>>
>>> To: <[email-masked] <mailto:[email-masked]>>;
> <[email-masked]
> <mailto:[email-masked]>>

> [Qin]: I get your point. As I said, the behavior of intermediary for
> sending TPLR could be the same as one for sending a NACK.
> 
> Before sending the another TPLR, the intermediary may rely on a timer to
> ensure that the attempt to send first TPLR for suppression
> 
> The timer can be based on observed round-trip time measured from
> intermediary to the receiver. The estimate of the round-trip time
> 
> (RTT) to the receiver can be calculated based on past observations, RTCP
> report round-trip time. Does this address your comment?
> 

I think using observed RTTs is a good thing. However, one needs to
answer the question of who's RTT are one using. A SSM receiver has no
RTT measurements performed, as they are sending no SRs. So unless the
summary Report is provided the receiver have no knowledge of any RTTs in
the system.

This is likely true also for intermediaries unless they send data using
their own SSRC, like unicast RTX.

Thus, it becomes difficult to know how the entities will behave with
these retransmission timers.

In addition as the receiver reaction to additional TPLRs aren't
documented it becomes difficult to determine how big impact spurious
TPLRs have on the system.

But lets assume that a TPLR simply resets the timer each time it is a
received. Then it makes sense for an intermediary that are awaiting
retransmission upstream to send TPLR periodically on an interval that is
guaranteed to be shorter than any participants retransmission timer
until it receives the retransmission request. Yes, sending one and if
the receiver populations timer is as long or longer than the
intermeediary's timer to the media source, then that is more optimal.
But if that results in a lot of NACK requests, then I would claim it
might be less efficient from a network resource perspective.

Thus different implementation choices exist. And with the current lack
of clarity I guess different implementation choices will be made and
with poor performance as result.

>  
> 
> Another case in my mind is how often to send a TPLR for different packet
> loss in case there is no loss of TPLR or of retransmission packet.
> 
> In this case, the intermediary can follow the same timing rule of
> sending NACK defined in RFC4585. i.e., The TPLR message may be sent
> 

Yes, I think the normal rules fro sending AVPF packets should be
followed. I don't think you need to have the "full" rule for something
that is in fact a new Feedback event. Just use the rules for sending
feedback events.

> Does it make sense to you?

I am fine with individual timers for each TPLR report.

As before, I think how a receiver truly can estimate a reasonable timer
needs discussion.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Sep 2011 16:26:55 +0200

On 2011-09-07 23:10, Colin Perkins wrote:
> On 1 Sep 2011, at 15:52, Magnus Westerlund wrote: ...
>> 5. Section 3, fourth paragraph: I am trying to get my head around
>> the implications of not being explicit about the time feedback
>> suppression lasts. And I don't quite get how it works from either
>> side.
>> 
>> As the sender of Third party loss report, the first message is
>> pretty straight forward. It suppresses all receiver that get it for
>> one of their Retransmission timeout intervals. As a sender I have
>> no idea how long that interval are in the various receivers
>> implementations. It is likely a RTT + some fudge time for the
>> source being reported. The issue is that the RTT to the orignal
>> source, rather than the third party reporting the loss is quite
>> different, thus not reflecting the interval before the Third party
>> expects to get the packet for forwarding.
>> 
>> The next question is if and in that case when the node should send
>> an additional TPLR message. Should it wait for receiving a first
>> NACK and expect a storm of others before the suppression has
>> reached the others. Should it try to estimate the lowest
>> suppression time to any of the down stream receivers?
> 
> A TPLR is generally sent by a middlebox in response to a received
> NACK, in the case where that middlebox can't simply forward the NACK
> to other downstream receivers. Viewed this way, the TPLR takes the
> place of the NACK on the downstream path, and is sent when the NACK
> is received. The suppression of other NACKs would work in exactly
> as-if the middlebox forwarded the NACK, and the middlebox needs keep
> no special timers for the TPLR.
> 

I agree, just needs to be made clear in the document.

>> immediately restart the timer, or do I wait until the timer expires
>> and then refreshes it for one new interval?
> 
> Doesn't the receiver just behave as if it had received a NACK? A TPLR
> is form of NACK packet, it's just slightly indirected.

Maybe, if I remember correctly the rules are like this. You determine a
loss event. Schedule the transmission of a NACK feedback event. If you
receive a NACK or TPLR that covers the whole event you intended to send
then you deschule it. That is the suppression mechanism. Then something
in your stack which I don't think is well defined will trigger a new
feedback event due to the loss still being outstanding.

The issue is the interaction if any between the TPLR and this mechanism.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Sep 2011 16:43:28 +0200

Hi,

See inline. Removed the resolved bullets.

On 2011-09-10 12:29, Qin Wu wrote:
> Hi, Magnus, Thank for your comments, a quick reply below. -----
> Original Message ----- From: "Magnus Westerlund"
> <[email-masked]> To: <[email-masked]> Cc:
> <[email-masked]> Sent:
> Friday, September 09, 2011 7:25 PM Subject: Re: [AVTCORE] Comments on
> draft-ietf-avtcore-feedback-supression-rtp-06.txt
> 

> [Qin]:True, Does it make sense to remove it? If not, will redraw it.

I think the question is how much the text needs the support of the
figure to explain the context.

> 
> 4. Section 6.2: "If the BRS impacted by packet loss has been told the
> actual packet loss, the BRS MAY choose to create new Third Party Loss
> Report message and send it to the receivers in the downstream link.
> "
> 
> I don't understand how the BRS can inject any message into the SSM
> tree, as the source anchor of the SSM tree is up at the multicast
> source. Thus a BRS needs to tell the distribution source to send
> something down stream on its behalf.
> 
> 
> 
> 
> [Qin]: It is possbile for BRS to tell the distrbution source to send
> TPLR down on its BRS. My question is Is the BRS similar to
> Distribution source as an intermediary between multicast source and
> 

My understanding what that the BRS is in fact not owner of their own SSM
session, only help nodes that are receiver of the SSM session but not DS
in it. And having the BRS send something to the DS which is only valid
for its little part of a large SSM session is strange.

But RAMS authors view would be appreciated.

> [Qin]: How about the following rephrasing: OLD text: " The translator
> can identify packet loss using co-located monitor
> [I-D.ietf-avtcore-monarch] by receiving a NACK from another system
> and then the monitor can use it's own SSRC as packet sender SSRC for
> transmitting the Third Party Loss Report message and send this
> message to the unicast receivers that is not aware of packet loss.
> 
> 
> " New Text: " The translator acting as quality monitoring may suffer
> a loss of important video packets. In this case, the translator may
> trigger repair by the media sender and tt the same time ,use it's own
> SSRC as packet sender SSRC to create a new Third Party Loss Report
> message and send it to the receivers that is not aware of packet
> loss. "

Much clearer.

> 
> 6. Section 6.4:
> 
> As this is a poorly supported model in RTP, why is a use case built
> on that? Shouldn't a RTP Mixer case be a better basis for building a
> FIR suppression usage?
> 
> 
> 

I think MCU as described in RFC 5117 is a broken device and should not
taken into account when designing RTP/RTCP solutions.

> fact sends a FIR to the media source it is going to switch to prior
> to actually switching. It doesn't switch until it actually has an
> I-frame or similar decoder refresh point to switch on. Thus the
> actually switching shouldn't be the cause for downstream FIR
> suppression. If the receiver has packet loss, it should in fact send
> PLI, rather than FIR.
> 
> 
> 
> [Qin]: It is true FIR SHALL NOT be sent as a reaction to picture
> losses However according to four paragraph, section 4.3.1.2 of
> RFC5104, FIR
> 

No, you quote the RFC correctly. However, I think one needs to ask one
self if this issue occurs in an MIXER/MCU setup at all. As the Mixer are
sitting between each session participant it can suppress the the FIR
most naturally for most use cases.

I agree in cases where the video gets badly screwed up between media
source and mixer and the system doesn't use retransmission, suppression
of FIR and I would say PLI also could have its points.

So it occur in two cases. One where the mixer analyses the video enough
so that it can determine that the packet loss will result in PLI or FIR
transmissions from most of the group, and thus initiate it on it own accord.

The second case is when it starts to receive FIR or PLI from some
participants and like to suppress the rest by sending out a message.

> [Qin]: Do you think we need a use case for suppressing PLI?

Yes, there exist a case for this, but I would consider it not supper
strong. Also I think it apply equally to PLI as to FIR.

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 13 Sep 2011 16:11:06 +0200

Magnus,

If you want a view of the RAMS' authors, please check:
http://tools.ietf.org/html/draft-vancaenegem-avtcore-retransmission-for-ssm-00 

I did ask Qin to refer to this draft which provides a detailed description on how feedback suppression can work for RAMS topology.

In summary: 

The BRS sends a NACK or TPLR message to the DS, where the SSRC in this NACK or TPLR message is the one of the BRS. The DS forwards/reflects this message down on the primary SSM. This procedure will allow isolated feedback suppression, when RTP receivers only trigger FB suppression when recognising the SSRC as belonging to the BRS to which they report.

Tom  

> downstream receivers? Why BRS can not inject in between while 

My understanding what that the BRS is in fact not owner of their own SSM session, only help nodes that are receiver of the SSM session but not DS in it. And having the BRS send something to the DS which is only valid for its little part of a large SSM session is strange.

---

From: Roni Even <[email-masked]>
Date: Tue, 13 Sep 2011 17:23:40 +0300

Hi Tom,
I reviewed this section in the 6.2 and mostly agree with your suggestion.
I also suggested to Qin to look also at the difference when there is
retransmission or not and also if the retransmission is in unicast or
multicast. 

Regards
Roni 

> -----Original Message-----
> From: Van Caenegem, Tom (Tom) [mailto:tom.van_caenegem@alcatel-
> lucent.com]
> Sent: Tuesday, September 13, 2011 5:11 PM
> To: Magnus Westerlund; Qin Wu
> Cc: [email-masked]; draft-ietf-avtcore-feedback-supression-
> [email-masked]
> Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-
> supression-rtp-06.txt
> 
> Magnus,
> 
> I did ask Qin to refer to this draft which provides a detailed
> description on how feedback suppression can work for RAMS topology.
> 
> In summary:
> 
> The BRS sends a NACK or TPLR message to the DS, where the SSRC in this
> NACK or TPLR message is the one of the BRS. The DS forwards/reflects
> this message down on the primary SSM. This procedure will allow
> isolated feedback suppression, when RTP receivers only trigger FB
> suppression when recognising the SSRC as belonging to the BRS to which
> they report.
> 
> Tom
> 
> My understanding what that the BRS is in fact not owner of their own
> SSM session, only help nodes that are receiver of the SSM session but
> not DS in it. And having the BRS send something to the DS which is only
> valid for its little part of a large SSM session is strange.
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Sep 2011 18:18:21 +0800

Hi,Magnus:
Sorry for late feedback, please see my reply below.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 12, 2011 10:22 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

> these retransmission timers.

[Qin]: This is not true. Look at the section 7.1.6 of RFC5760, in SSM summary feedback case, the distribution source can use Round-Trip time sub-report block defined in section 7.1.6 to tell the receiver about the round-trip time from the distribution source to the receivers. This round-trip time can be calculated based on the SR from media source, RR from receiver and the current time according to the section 7.1.6. So this round-trip time calculation also applies to the other use cases.

> TPLRs have on the system.

[Qin]: Agree. I think we may follow the similar rules made for multiple retransmission described in the section 6.3 of RFC4588 if we document additional TPLRs.

> with poor performance as result.

[Qin]: We don't need to support various implementation choices.

Assume the intermediary sits between media source and receiver, we can ask intermediary to measure the round trip time between media source and intermediary, the round trip time between intermediary and receiver to make sure the media source is more near to the intermediary than the receiver.

Therefore we can guarantee that the receiver populations timer to intermediary is set as long or longer than the intermediary's timer to the media source. 

In this case, we will not introduce a lot of NACK when additional TPLR is used.

Does this make sense to you?

[Qin]: Okay.

> I am fine with individual timers for each TPLR report.

[Qin]:Okay.

> As before, I think how a receiver truly can estimate a reasonable timer

[Qin]:See above.

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Sep 2011 18:24:33 +0800

Hi, Magnus:
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 12, 2011 10:43 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin]: Yes, I propose to remove the last paragraph since Tom argues this is more related to Retransmission. Also I propose to rewrite the left texts in RAMS use case. So there will be not so much text to support the figure any more.

[Qin]: According to RAMS specification in RFC6285, the Retransmission server also joins the multicast session, that is why it can cache the most recent packets from the primary multicast.

But you are right, having the BRS send something to the DS which only affect little part of a large SSM session is weired. So I propose to revise the text in RAMS case as:

"

The typical RAMS architecture [RFC6285] may have several Burst/

   Retransmission Sources(BRS) behind the multicast source (MS) placed

   at the same level.  These BRSes will receive the primary multicast RTP stream from the media source after joining multicast session.  If packet loss happens at the upstream of all the BRSs. one of the BRSes or all the BRSes may identify packet loss and send a NACK to the distribution source. Similar to the Distribution Source Feedback Summary model, the distribution source doesn't want to redistribute the duplicated NACK for the same loss event from multiple BRSes. In this case, the distribution source may send a Third Party Loss Report to the systems that were unable to receive the NACK.

"

Does it make sense?

Much clearer.

[Qin]: Okay.

[Qin]: I guess you are saying content switching is not common deployed compared to content mixing. However we can not deny its existence.

According to RFC4587,section 5, it said:

"

Image refreshment may be needed due to packet loss or due

   to application requirements.  An example of application requirement

   may be the change of the speaker in a voice-activated multipoint

   video switching conference.  There are two methods that can be used

   for requesting image refreshment.  The first method is by using the

   Extended RTP Profile for RTCP-based Feedback and sending RTCP generic

   control packets, as described in RFC 4585 [RFC4585].  The second

   method is by using application protocol-specific commands, such as

   H.245 [ITU.H245] FastUpdateRequest.

"

In this case, they are talking about a use case using MCU, i.e., the change of the speaker in a voice-activated multipoint video switching conference.

So I proposed to revise MCU use case as follows:

"

When the speaker is changed in a voice-activated multipoint video switching conference [RFC4587], video switching MCU can be used to select the available input streams and forward one to each participant. However in some case, the receiver may lose synchronization with the video stream and send a FIR to ask for the new decoder refresh point. when the MCU starts to receive FIR from some participants and like to suppress the rest session participants sending FIR by sending out a Third party Loss report message. As suggested in RFC 5117, the MCU is better implemented as an Topo-Mixer, in which case the mixer's SSRC is used as packet sender SSRC for transmitting the Third Party Loss Report message.

"

What do you think of it?

[Qin]: Good inputs. How about rephrase it as a new mixer use case like this:

"

A Mixer, in accordance with [RFC5117], aggregates multiple RTP streams

from other session participants and generates a new RTP stream 

sent to the session participants. In some cases, the video may get badly

screwed up between media source and the mixer. In such case, the mixer need to check if the packet loss will result in PLI or FIR transmissions from most of the group by analyzing the received video. If so the mixer initiate it on behalf of all the session participants sending PLR or FIR and at the same time send the third part loss report to these session participants. Another possible way for mixer to deal with, is when the mixer starts to receive FIR or PLI from some

participants and like to suppress the rest session participants sending FIR or PLI by sending out a Third party Loss report message.

"

[Qin]: See above.

Cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Sep 2011 18:33:09 +0800

Hi, Tom:
Thank for your suggestion. Please see my comments below.
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 13, 2011 10:11 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Magnus,

[Qin]: Okay. I will think about it. 

In summary: 

[Qin]: What do you mean about isolated feedback suppression, do you mean DS control which BRS it will redistribute Feedback suppression message from BRS or just flood the message to all the BRSes.

Tom

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 16 Sep 2011 13:00:28 +0200

Qin,

Tom: no. As explained above a BRS that wants FB suppression will send NACK or TPLM to the DS, which then re-distributes to ALL RTP receivers via the SSM. Only receivers that report to the BRS that sent the TPL or NACK message to the DS, will suppress feedback. Other receivers will ignore this NACK/TPL message. Whether the feedback suppression is activated or not, is hence determined by the SSRC identifier value (the one of the BRS) in the TPLM or NACK that is received by the RTP receiver. See the draft document.

Regards

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 17:04:30 +0200

On 2011-09-16 12:18, Qin Wu wrote:
>> answer the question of who's RTT are one using. A SSM receiver has
>> no RTT measurements performed, as they are sending no SRs. So
>> unless the summary Report is provided the receiver have no
>> knowledge of any RTTs in the system.
>> 
>> This is likely true also for intermediaries unless they send data
>> using their own SSRC, like unicast RTX.
>> 
>> Thus, it becomes difficult to know how the entities will behave
>> with these retransmission timers.
> 
> 
> [Qin]: This is not true. Look at the section 7.1.6 of RFC5760, in SSM
> summary feedback case, the distribution source can use Round-Trip
> time sub-report block defined in section 7.1.6 to tell the receiver
> about the round-trip time from the distribution source to the
> receivers. This round-trip time can be calculated based on the SR
> from media source, RR from receiver and the current time according to
> the section 7.1.6. So this round-trip time calculation also applies
> to the other use cases.

I think we are in full agreement when the summary feedback mode is used.
But what if it isn't. What if one uses the simple feedback. Sure, the
receiver can measure the time until its RTCP packet comes back to it.
But that doesn't measure the Media source to receiver RTT which I
believe is the relevant here.

And I think the question is still what RTT one uses in these
measurements. The one related to the media server, or one related to the
SSRC injecting the TPLR. They don't need to be the same.

>> documented it becomes difficult to determine how big impact
>> spurious TPLRs have on the system.
> 
> 
> [Qin]: Agree. I think we may follow the similar rules made for
> multiple retransmission described in the section 6.3 of RFC4588 if we
> document additional TPLRs.
> 
> 
>> But lets assume that a TPLR simply resets the timer each time it is
>> a received. Then it makes sense for an intermediary that are
>> awaiting retransmission upstream to send TPLR periodically on an
>> interval that is guaranteed to be shorter than any participants
>> retransmission timer until it receives the retransmission request.
>> Yes, sending one and if the receiver populations timer is as long
>> or longer than the intermeediary's timer to the media source, then
>> that is more optimal. But if that results in a lot of NACK
>> requests, then I would claim it might be less efficient from a
>> network resource perspective.
>> 
>> Thus different implementation choices exist. And with the current
>> lack of clarity I guess different implementation choices will be
>> made and with poor performance as result.
> 

Ok, but from my perspective is then to make it clear how you are
supposed to implement the features so that the choices doesn't affect
the system behavior.

> 
> Assume the intermediary sits between media source and receiver, we
> can ask intermediary to measure the round trip time between media
> source and intermediary, the round trip time between intermediary and
> receiver to make sure the media source is more near to the
> intermediary than the receiver.

Yes, that makes sense. But what method(s) of measuring are you proposing
for the intermediary?

> 
> Therefore we can guarantee that the receiver populations timer to
> intermediary is set as long or longer than the intermediary's timer
> to the media source.
> 

Yes, but can you please try to write it up in spec text including
pointing to the methods of measuring the RTT that you expect the
intermediary to use.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Sep 2011 17:24:55 +0200

On 2011-09-16 12:24, Qin Wu wrote:
> Hi, Magnus: ----- Original Message ----- From: "Magnus Westerlund"
> <[email-masked]> To: "Qin Wu" <[email-masked]> 
> Cc: <[email-masked]>;
> Monday, September 12, 2011 10:43 PM Subject: Re: [AVTCORE] Comments
> on draft-ietf-avtcore-feedback-supression-rtp-06.txt
> 
>> Friday, September 09, 2011 7:25 PM Subject: Re: [AVTCORE] Comments
>> on draft-ietf-avtcore-feedback-supression-rtp-06.txt
>> 
> 
>> 3. Section 6.2:
>> 
>> First of all the figure 3 doesn't make it clear that there are N
>> RTP receivers to the right in the figure.
>> 
> [Qin]: Yes, I propose to remove the last paragraph since Tom argues
> this is more related to Retransmission. Also I propose to rewrite the
> left texts in RAMS use case. So there will be not so much text to
> support the figure any more.

Ok, do what you think best here.

> 
> 
> 
>> 
>> 4. Section 6.2: "If the BRS impacted by packet loss has been told
>> the actual packet loss, the BRS MAY choose to create new Third
>> Party Loss Report message and send it to the receivers in the
>> downstream link. "
>> 
>> [Qin]: It is possbile for BRS to tell the distrbution source to
>> send TPLR down on its BRS. My question is Is the BRS similar to 
> not DS in it. And having the BRS send something to the DS which is
> only valid for its little part of a large SSM session is strange.
> 
> [Qin]: According to RAMS specification in RFC6285, the Retransmission
> server also joins the multicast session, that is why it can cache the
> most recent packets from the primary multicast.
> 
> But you are right, having the BRS send something to the DS which only
> affect little part of a large SSM session is weired. So I propose to
> revise the text in RAMS case as:
> 
> "
> 
> at the same level.  These BRSes will receive the primary multicast
> RTP stream from the media source after joining multicast session.  If
> packet loss happens at the upstream of all the BRSs. one of the BRSes
> or all the BRSes may identify packet loss and send a NACK to the
> distribution source. Similar to the Distribution Source Feedback
> Summary model, the distribution source doesn't want to redistribute
> the duplicated NACK for the same loss event from multiple BRSes. In
> this case, the distribution source may send a Third Party Loss Report
> to the systems that were unable to receive the NACK.
> 
> "
> 
> Does it make sense?
> 

Hmmm, this is strange. If the BRS can send the NACKs then I would expect
the DS to retransmit the missing packet, rather than sending a TPLR as
they will not arrive to the receivers any prior to the actual repair
packet.

In the same way I don't see how a TPLR works well in this use case if is
only targeted to a part of the multicast tree. This as there isn't
really anyway of controlling who interpret the TPLR.

I don't know what I think of Tom's idea that the receiver should filter
the TPLR based on the source SSRC of it and only react on the ones that
matches its configured BRS. Then I think this needs to be well defined,
rather than just discussed here for that particular use case.

>> 
>> 6. Section 6.4:
>> 
>> As this is a poorly supported model in RTP, why is a use case
>> built on that? Shouldn't a RTP Mixer case be a better basis for
>> building a FIR suppression usage?
>> 
>> 
>> 
> I think MCU as described in RFC 5117 is a broken device and should
> not taken into account when designing RTP/RTCP solutions.
> 
> [Qin]: I guess you are saying content switching is not common
> deployed compared to content mixing. However we can not deny its
> existence.
> 

No, that is not what I am saying. The fact is that stream switching can
be implemented in the RTP mixer model just as well as actually
composited video streams. It is still an RTP mixer, rather then the
broken MCU topology that butchers the RTCP reporting for the RTP session.

> In this case, they are talking about a use case using MCU, i.e., the
> change of the speaker in a voice-activated multipoint video switching
> conference.
> 
> 
> 
> When the speaker is changed in a voice-activated multipoint video
> switching conference [RFC4587], video switching MCU can be used to
> select the available input streams and forward one to each
> participant. However in some case, the receiver may lose
> synchronization with the video stream and send a FIR to ask for the
> new decoder refresh point. when the MCU starts to receive FIR from
> some participants and like to suppress the rest session participants
> sending FIR by sending out a Third party Loss report message. As
> suggested in RFC 5117, the MCU is better implemented as an
> Topo-Mixer, in which case the mixer's SSRC is used as packet sender
> SSRC for transmitting the Third Party Loss Report message.
> 
> "
> 
> What do you think of it?
> 

I would claim that the correct way of implementing the functionality
they are talking about in RFC 4587 is to use an RTP mixer. Thus I would
modify the text to say:

When the speaker is changed in a voice-activated multipoint video
switching conference [RFC4587], an RTP mixer can be used to
select the available input streams and forward one to each
participant. However in some case, the receiver may lose
synchronization with the video stream and send a FIR to ask for the
new decoder refresh point. When the RTP Mixer starts to receive FIR from
some participants it can suppress the rest of the session participants
from sending FIR by sending out a Third party Loss report message.

> 
> 
>> 
>> My understanding of a video stream switching RTP mixer is that it
>> in fact sends a FIR to the media source it is going to switch to
>> prior to actually switching. It doesn't switch until it actually
>> has an I-frame or similar decoder refresh point to switch on. Thus
>> the actually switching shouldn't be the cause for downstream FIR 
>> suppression. If the receiver has packet loss, it should in fact
>> send PLI, rather than FIR.
>> 
>> 
>> 
> No, you quote the RFC correctly. However, I think one needs to ask
> one self if this issue occurs in an MIXER/MCU setup at all. As the
> Mixer are sitting between each session participant it can suppress
> the the FIR most naturally for most use cases.
> 
> source and mixer and the system doesn't use retransmission,
> suppression of FIR and I would say PLI also could have its points.
> 
> So it occur in two cases. One where the mixer analyses the video
> enough so that it can determine that the packet loss will result in
> PLI or FIR transmissions from most of the group, and thus initiate it
> on it own accord.
> 
> screwed up between media source and the mixer. In such case, the
> mixer need to check if the packet loss will result in PLI or FIR
I would change "need to" to "may"

> transmissions from most of the group by analyzing the received video.
> If so the mixer initiate it on behalf of all the session participants

Change it to what it is, I guess FIR or PLI towards the media source

> sending PLR or FIR and at the same time send the third part loss
> report to these session participants. 

I think the above is a bit confused. I don't see the receivers having
sent a FIR or PLI yet. As they may not have been reached by the broken
video packets. The goal is after all to try to get the receivers to
suppress their sending before they actually send something.

Another possible way for mixer
> to deal with, is when the mixer starts to receive FIR or PLI from
> some
> 
> participants and like to suppress the rest session participants
> sending FIR or PLI by sending out a Third party Loss report message.

I guess "rest" here should be remaining. And I think there is missing
"from" before sending.

cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 16 Sep 2011 18:00:34 +0200

Magnus,

> at the same level.  These BRSes will receive the primary multicast RTP 
> stream from the media source after joining multicast session.  If 

Hmmm, this is strange. If the BRS can send the NACKs then I would expect the DS to retransmit the missing packet, rather than sending a TPLR as they will not arrive to the receivers any prior to the actual repair packet.

Tom: I think you are mixing up two things : a NACK can be sent by the BRS to the DS with the aim to result in feedback suppression relying on the fact that the DS reflects this NACK down on the SSM. However, the DS may also host a RS, and then it could respond additionally with a retransmission to the BRS, which a BRS could send to receivers in existing retransmission sessions. However, this is not what this draft is about. You are right that both will result in FB suppression, but there is no mandate that a DS also hosts a RS.  

In the same way I don't see how a TPLR works well in this use case if is only targeted to a part of the multicast tree. This as there isn't really anyway of controlling who interpret the TPLR.

I don't know what I think of Tom's idea that the receiver should filter the TPLR based on the source SSRC of it and only react on the ones that matches its configured BRS. Then I think this needs to be well defined, rather than just discussed here for that particular use case.

Tom: well , again,  that's exactly why I want Qin to refer to "draft-vancaenegem-avtcore-retransmission-for-ssm-00". Can we defer the discussion on this item towards that draft? I will provide a second version in due time.

---

From: Qin Wu <[email-masked]>
Date: Mon, 19 Sep 2011 13:36:23 +0800

Hi, Magnus:
Please see my reply below.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 16, 2011 11:04 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

> But what if it isn't. What if one uses the simple feedback. 

[Qin]: As described in draft-ietf-avtcore-feedback-suppression-rtp, 

in simple feedback case, DS will not send TPLR instead it send NACK.

I am not sure the timing rule for sending NACK is the scope of this document.

>Sure, the

[Qin]Unlike Summary Feedback model case, in simple feedback model,

 as described in section 6.1 of RFC5760, the DS create its own Sender

 report which includes round trip time calculation between DS and 

receiver.

If the DS want to know the RTT between media source and itself, the DS

 can estimate it based on the SR sent from media source to the DS and

 current time as measured from its own system clock.

I don't understand why in this case the receiver still needs to know the RTT 
between media source and receiver since the SR sent from DS rather than media source 
carries the round trip time calcualtion.

> measurements. 

[Qin]: See above.

>The one related to the media server, or one related to the

[Qin]: In all these case, I think SSRC of source is still from media server or media source.

The SSRC of sender is generated by the middlebox.
In TPLR format described in section 4.2 of draft-ietf-avtcore-feedback-suppression-rtp, SSRC in FCI format
is SSRC of media source. Since media source may change, so does SSRC of media source.
am I wrong?

[Qin]: Okay.

> Yes, that makes sense. But what method(s) of measuring are you proposing

[Qin]: The intermediary may Use the same measurement method described in 

the section 7.1.6 ,first paragraph of RFC5760 in SSM summary feedback model case.

Is that clear?

[Qin]: Okay.

---

From: Qin Wu <[email-masked]>
Date: Mon, 19 Sep 2011 13:45:10 +0800

Hi, Magnus:
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 16, 2011 11:24 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin]: Okay.

> rather than just discussed here for that particular use case.

[Qin]: Just for clarification. The data cached from the primary multicast at the BRS is only for unicast retransmission.

Therefore I think we need look at RAMS use case in two cases supposing multiple BRSes placed in between at the same level.

Case 1: multicast packet loss happens at the upstream of all the BRSes

Case 2: multicast or unicast packet loss happens at the aggregating downstream of one BRS

For case 1, multicast packet loss is targeted to all the BRSes and their downstream receivers, in this case,

 one or all BRS may be aware of upstream multicast packet loss and tell the DS to send TPLR to suppress 

NACK from each BRS downstream receiver. Also in this case, BRS can send TPLR, DS forward this TPLR to 

the downstream. Is this case clear or well defined to you?

For case 2, packet loss is only targeted to one BRS and will not affect other BRSes and relevant downstream

 receiver in that branch. Also packet loss includes unicast packet loss and multicast packet loss. In unicast 

packet loss, the BRS will send unicast retransmitted packet from its cache to the affected receiver upon receiving 

NACK from downstream receiver. If downstream multicast packet loss happens at the downstream of this BRS, 

this BRS (in the multicast path between media source and receiver) needs to check if the multicast packet loss need 

to be told to DS. 

In draft-ietf-avtcore-feedback-suppression-rtp, we only talking about the first case(i.e., upstream loss case).  

For case 2, I guess Tom's draft is mostly used to deal with this case. Am I wrong?

Also In my understanding, Tom's idea on SSRC declaring is just to help receiver to know how to deal with unnecessary TPLR or 
NACK from network.

> broken MCU topology that butchers the RTCP reporting for the RTP session.

[Qin]: I see and agree.

> from sending FIR by sending out a Third party Loss report message.

[Qin]: I am okay with this rephrasing, thanks.

> I would change "need to" to "may"

[Qin] Okay.

> Change it to what it is, I guess FIR or PLI towards the media source

[Qin] Okay and Yes.

> suppress their sending before they actually send something.

[Qin]: My mistake for introducing such confustion. How about change the texts from

"

"

to

"

If so, the mixer initiates FIR or PLI towards the media source

on behalf of all the session participants and send out a Third party Loss report message

to these session participants

early before they are reached by the broken video packets from the upstream of mixer 

and going to send PLR or FIR.

"

> I guess "rest" here should be remaining. And I think there is missing

[Qin] Yes, thanks for catching.

---

From: Qin Wu <[email-masked]>
Date: Mon, 19 Sep 2011 16:34:29 +0800

Hi,
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 16, 2011 7:00 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Qin,

[Qin]: It is not clear to me how this is different from FB suppression rule defined in RFC4585.
it looks to me the receiver behavior for FB suppression in your draft document is not compliant with what it described in RFC4585,
Fist of all,  ome receivers doesn't follow FB suppression rule defined in RFC4585 when they receive NACK or TPL with unkonw SSRC value.

However according to RFC4585, if NACK or TPLM is allowed to send to all the receivers, all the receivers should react to the receiving NACK or TPLM following rule defined in RFC4585
rather than ignore  or discard it when SSRC in NACK or TPLM is unknow.

Secondly If one receiver didn't report the loss to the BRS, however the DS may still send NACK or TPLM to this receiver. In your undersanding, this receiver should not activate feedback suppression.
However according to RFC4585, the receiver receiving NACK or TPLM should suppress FB message if it see the same loss.

So in my understanding, additional rule you proposed is like conditional FB suppression for receivers, in other words, the receiver selectively does FB suppression based on the SSRC delcared. My question is does it conflict with RFC4585? Is it optional choice or 
mandatory choice for FB suppression? e.g., only the number of receivers exceeds the threshold, then conditional FB suppression applies.

Regards=

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Sep 2011 17:27:57 +0200

Hi,

I think the discussion has become so convoluted that it is difficult to
understand what applies to which deployment.

> I am not sure the timing rule for sending NACK is the scope of this document.

I guess we are back to what "it" says in the following sentence.
One example is the middle box gets
   the retransmitted packet by sending a NACK upstream and sent it
   downstream.

If it is "the NACK". But I have to say that I am confused by this test
if it is one SSM group that continues all the way to the ultimate
receiver and the Intermediary is just a on route monitoring and help
device.

>  current time as measured from its own system clock.

I think I missed something important in this case. In simple feedback
model, also the receivers RTCP are feed back into the group. Thus the
combination of the SR and the receivers RRs should enable each
participant to have a view of the delay between the DS and each receiver.

> carries the round trip time calcualtion.

Well, if the goal is to determine the amount of time a TPLR or for that
matter a NACK suppresses new NACKs I think one have to take into account
the RTTs to be expected before receiving a repair packet or know that it
has been lost.

But with this each session participant clearly has the information it
needs.

> is SSRC of media source. Since media source may change, so does SSRC of media source.

The above question was really about whose delays in the system one
should consider. If an Intermediary sends the NACK to the DS. Then there
is one RTT between the intermediary and the DS. The downstream receiver
will have another RTT with the DS. In that context I think one do need
to consider which time intervalls that makes sense. What legs of the
system does the messages need to traverse before getting the reaction,
or having to retransmit.

When it comes to the SSRCs, don't forgett that you do have two SSRC isn
the common packet format for feedback messges. One of the source of the
feedback message and one that is the media source that the message
relate to.

> the section 7.1.6 ,first paragraph of RFC5760 in SSM summary feedback model case.

Well, does that work? Is the intermediary receving the RTCP RRs from the
receivers. And what way have they taken to reach the intermediary.

But I have to say that I have become confused in which model we are
discussing here.

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Sep 2011 17:43:52 +0200

On 2011-09-19 07:45, Qin Wu wrote:
>>>> 
>>>> 4. Section 6.2: "If the BRS impacted by packet loss has been
>>>> told the actual packet loss, the BRS MAY choose to create new
>>>> Third Party Loss Report message and send it to the receivers in
>>>> the downstream link. "
>>>> 
>>>> I don't understand how the BRS can inject any message into the
>>>> SSM tree, as the source anchor of the SSM tree is up at the
>>>> multicast source. Thus a BRS needs to tell the distribution
>>>> source to send something down stream on its behalf.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> [Qin]: It is possbile for BRS to tell the distrbution source
>>>> to send TPLR down on its BRS. My question is Is the BRS similar
>>>> to Distribution source as an intermediary between multicast
>>>> source and
>>>> 
>>> My understanding what that the BRS is in fact not owner of their
>>> own SSM session, only help nodes that are receiver of the SSM
>>> session but not DS in it. And having the BRS send something to
>>> the DS which is only valid for its little part of a large SSM
>>> session is strange.
>>> 
>>> [Qin]: According to RAMS specification in RFC6285, the
>>> Retransmission server also joins the multicast session, that is
>>> why it can cache the most recent packets from the primary
>>> multicast.
>>> 
>>> But you are right, having the BRS send something to the DS which
>>> only affect little part of a large SSM session is weired. So I
>>> propose to revise the text in RAMS case as:
>>> 
>>> "
>>> 
>>> at the same level.  These BRSes will receive the primary
>>> multicast RTP stream from the media source after joining
>>> multicast session.  If packet loss happens at the upstream of all
>>> the BRSs. one of the BRSes or all the BRSes may identify packet
>>> loss and send a NACK to the distribution source. Similar to the
>>> Distribution Source Feedback Summary model, the distribution
>>> source doesn't want to redistribute the duplicated NACK for the
>>> same loss event from multiple BRSes. In this case, the
>>> distribution source may send a Third Party Loss Report to the
>>> systems that were unable to receive the NACK.
>>> 
>>> "
>>> 
>>> Does it make sense?
>>> 
>> 
>> Hmmm, this is strange. If the BRS can send the NACKs then I would
>> expect the DS to retransmit the missing packet, rather than sending
>> a TPLR as they will not arrive to the receivers any prior to the
>> actual repair packet.
>> 
>> In the same way I don't see how a TPLR works well in this use case
>> if is only targeted to a part of the multicast tree. This as there
>> isn't really anyway of controlling who interpret the TPLR.
>> 
>> I don't know what I think of Tom's idea that the receiver should
>> filter the TPLR based on the source SSRC of it and only react on
>> the ones that matches its configured BRS. Then I think this needs
>> to be well defined, rather than just discussed here for that
>> particular use case.
>> 
> 
> [Qin]: Just for clarification. The data cached from the primary
> multicast at the BRS is only for unicast retransmission.
> 
> Therefore I think we need look at RAMS use case in two cases
> supposing multiple BRSes placed in between at the same level.
> 
> For case 1, multicast packet loss is targeted to all the BRSes and
> their downstream receivers, in this case,
> 

Not entirely. As I don't see how a BRS can determine on its own if a
loss upstream of itself will affect only the part of the tree it is
responsible to service with repair, or if it affects all. Thus, I don't
see how we currently can define a suppression that involves BRSs at all.

> 
> 
> For case 2, packet loss is only targeted to one BRS and will not
> affect other BRSes and relevant downstream
> 
> receiver in that branch. Also packet loss includes unicast packet
> loss and multicast packet loss. In unicast
> 
> packet loss, the BRS will send unicast retransmitted packet from its
> cache to the affected receiver upon receiving
> 
> this BRS (in the multicast path between media source and receiver)
> needs to check if the multicast packet loss need
> 
> to be told to DS.
> 
> 
> In draft-ietf-avtcore-feedback-suppression-rtp, we only talking about
> the first case(i.e., upstream loss case).
> 

I think that is likely the right place. That draft will have to extend
the suppression behavior in those cases to include the "targeting" to
downstream of a certain repair node. Otherwise the suppression will have
whole SSM wide scope, which will be wrong.
> 
> 
> Also In my understanding, Tom's idea on SSRC declaring is just to
> help receiver to know how to deal with unnecessary TPLR or NACK from
> network.

I see it as necessary to avoid receivers that has no loss at the BRS
level of the multicast tree from suppressing their repair requests
unnecessary.

>> I think the above is a bit confused. I don't see the receivers
>> having sent a FIR or PLI yet. As they may not have been reached by
>> the broken video packets. The goal is after all to try to get the
>> receivers to suppress their sending before they actually send
>> something.
> 
> If so the mixer initiate it on behalf of all the session
> participants sending PLR or FIR and at the same time send the third
> part loss report to these session participants.
> 
> "
> 
> to
> 
> "
> 
> on behalf of all the session participants and send out a Third party
> Loss report message to these session participants early before they 
> are reached by the broken video packets from the
> upstream of mixer and going to send PLR or FIR.

I think this is better but still not clear. Two issues with the text.

1. " early before they
> are reached by the broken video packets"

Are you assuming that the mixer will not have sent the broken RTP packet
prior to sending the suppression message? or that the mixer will detect
the case and be able to send a suppression message that cancel the
transmission of a NACK or PLI requrest?

2. " and going to send PLR or FIR."

Maybe formulate it so that it is clear that the receivers may or are
expected to send a PLI or FIR?

Cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Sep 2011 15:57:03 +0800

Hi, Magnus:
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 21, 2011 11:43 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin]: Sorry, I am not looking at this deeply. Yes, Your argument is valid to me. 
 See my proposal below.

[Qin]: Yes. 

Howe about taking Tom's proposal and just reference Tom's draft regarding RAMS use case and say:

"

If multicast packet loss happens at the upstream of all the BRSs or the downstream of one or  more 

BRSes. one of the BRSes or all the BRSes may send a NACK or TPLR message to the DS, where the 

SSRC in this NACK or TPLR message is the one of the BRS. The DS forwards/reflects this message 

down on the primary SSM. The details on how DS deal with this message is specified in 

[I.D-vancaenegem-avtcore-retransmission-for-ssm]

"

Does this make sense? Or you have better suggestion?

[Qin]: Yes, I think the BRS should also distinguish between multicast packet loss and unicast packet loss.
 Since BRS may cache the unicast burst and compensate directly the unicast packet loss by sending the
 cached unicast burst packet to the receiver .

1. " early before they

[Qin]: I think the latter is more close to what it said. 

[Qin]: Yes, it is reasonable to formulate to what you suggest.

So how about rephrasing the total paragraph above as follows:

"

If so,the mixer initiates FIR or PLI towards the media source

Loss report message to these session participants that may or are

expected to send a PLI or FIR

"

Does this make sense?

Cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Sep 2011 17:26:56 +0800

Hi, Magnus:
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 21, 2011 11:27 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

> understand what applies to which deployment.

[Qin]: Sorry, I think there is some misunderstanding on a few issues we are talking about.

I am working on the restructuring of section 3. I believe we are on the same page and our

 discussion is approaching convergence rather than going into loop.

> receiver and the Intermediary is just a on route monitoring and help

[Qin]: I think there is some misunderstanding.

In Simple feedback case, the DS may send SR including round-trip time 

calculation. So it is also not difficult for DS to behave with the retransmission 

timer.

In this example mentioned above, the NACK sent to upstream is just for 

asking for lost packet on behalf of receivers. I am not saying how to deal 

the timing rule of this NACK sent to upstream is out scope of this document.

What I am saying is in simple feedback case, DS only reflect NACK to the receivers, 

however this document focus on defining the use of TPLR, that's why I am saying 

how to deal with retransmission timer when NACK 

sent to downstream may not be the scope of this document, but I am okay if you think

we should.

Does this clarify?

> participant to have a view of the delay between the DS and each receiver.

[Qin]:Yes, Agree. 

> But with this each session participant clearly has the information it

[Qin]: Agree, but I believe you misunderstand what I said above. What I am saying is

RTT measurement method for simple feedback case is different from RTT measurement 

method for Summary Feedback case, am I right?

> system does the messages need to traverse before getting the reaction,

[Qin]: Agree, I am not sure which case you are talking about, SSM case or RAMS case.

For SSM case, I am going to remove the text about "intermediary send NACK to DS", so

 there is only one DS in SSM case, the only RTT with DS needs to be taken into account.

For RAMS case, please see my previous email on the suggestion, i.e., reference Tom's draft.

> feedback message and one that is the media source that the message

[Qin]: Agree.

> But I have to say that I have become confused in which model we are

[Qin]: I agree it depends on the model since different model may use different measurement method. 

E.g., in Summary Feedback case, the DS may be disjointed from media soure, or may be itself media source. 

the measurement method differs apparently. Therefore I agree we can't apply one measurement method to 

all the use cases. So the general questions here are what's your suggestion about how to document measurement

 method in this draft? shall we need to specify common text in section 3 to talk about this?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 17:34:17 +0200

On 2011-09-22 11:26, Qin Wu wrote:
> Wednesday, September 21, 2011 11:27 PM Subject: Re: Comments on
>> I think the discussion has become so convoluted that it is
>> difficult to understand what applies to which deployment.
> 

Yes, thus I think it might be simplest that you update the document to
your understanding of the discussion and then I can check the update to
determine if we still have any ambiguities.

>>> Hi, Magnus: Please see my reply below. ----- Original Message
>>> ----- From: "Magnus Westerlund" <[email-masked]> 
>>> To: "Qin Wu" <[email-masked]> Cc: <[email-masked]>;
>>> Friday, September 16, 2011 11:04 PM Subject: Re: Comments on
>>>>>> I think using observed RTTs is a good thing. However, one
>>>>>> needs to answer the question of who's RTT are one using. A
>>>>>> SSM receiver has no RTT measurements performed, as they are
>>>>>> sending no SRs. So unless the summary Report is provided
>>>>>> the receiver have no knowledge of any RTTs in the system.
>>>>>> 
>>>>>> This is likely true also for intermediaries unless they
>>>>>> send data using their own SSRC, like unicast RTX.
>>>>>> 
>>>>>> Thus, it becomes difficult to know how the entities will
>>>>>> behave with these retransmission timers.
>>>>> 
>>>>> 
>>>>> [Qin]: This is not true. Look at the section 7.1.6 of
>>>>> RFC5760, in SSM summary feedback case, the distribution
>>>>> source can use Round-Trip time sub-report block defined in
>>>>> section 7.1.6 to tell the receiver about the round-trip time
>>>>> from the distribution source to the receivers. This
>>>>> round-trip time can be calculated based on the SR from media
>>>>> source, RR from receiver and the current time according to 
>>>>> the section 7.1.6. So this round-trip time calculation also
>>>>> applies to the other use cases.
>>>> 
>>>> I think we are in full agreement when the summary feedback mode
>>>> is used. But what if it isn't. What if one uses the simple
>>>> feedback.
>>> 
>>> [Qin]: As described in
>>> draft-ietf-avtcore-feedback-suppression-rtp,
>>> 
>> One example is the middle box gets the retransmitted packet by
>> sending a NACK upstream and sent it downstream.
>> 
>> If it is "the NACK". But I have to say that I am confused by this
>> test if it is one SSM group that continues all the way to the
>> ultimate receiver and the Intermediary is just a on route
>> monitoring and help device.
>> 
> 

If the conclusion is that TPLR is not applicable to this case I think we
are in agreement.

>>> 
>>> 
>>> I don't understand why in this case the receiver still needs to
>>> know the RTT between media source and receiver since the SR sent
>>> from DS rather than media source carries the round trip time
>>> calcualtion.
>> 
>> Well, if the goal is to determine the amount of time a TPLR or for
>> that matter a NACK suppresses new NACKs I think one have to take
>> into account the RTTs to be expected before receiving a repair
>> packet or know that it has been lost.
>> 
>> But with this each session participant clearly has the information
>> it needs.
> 
> 

Well, to some extent yes.

In both cases the DS can do RTT measurements as intended for anyone
sending SRs in basic RTP.

In the simple feedback model any SSM session recipient can first measure
its RTT to the DS. That by determing the time it takes from it sends its
RTCP RR to get it back. Yes, there is some component of undetermined
processing in that.

With that knowledge it can determine the RTT values for any receiver by
determine its reception time of the reflected RTCP RR and then deduct
the time from the DS to one self. Use that to derive both the RTCP SR
sending time and the time the RTCP RR was received by the DS. Thus
calculating the delay.

In the summary session, the receiver have no way of measuring the RTT.
It can only use the RTT distribution received from the DS based
measurements.

>>>> The one related to the media server, or one related to the SSRC
>>>> injecting the TPLR. They don't need to be the same.
>>> 
>>> The SSRC of sender is generated by the middlebox. In TPLR format
>>> described in section 4.2 of
>>> draft-ietf-avtcore-feedback-suppression-rtp, SSRC in FCI format 
>>> is SSRC of media source. Since media source may change, so does
>>> SSRC of media source. am I wrong?
>> 
>> 
>> should consider. If an Intermediary sends the NACK to the DS. Then
>> there is one RTT between the intermediary and the DS. The
>> downstream receiver will have another RTT with the DS. In that
>> context I think one do need to consider which time intervalls that
>> makes sense. What legs of the system does the messages need to
>> traverse before getting the reaction, or having to retransmit.
>> 
> 
> 
> 
> 

I tried to understand if there was any usage of the TPLR in the SSM
case. Which I think it is for the summary mode.

And in that case that what RTT(s) should be used when determing the time
of suppression.

> For RAMS case, please see my previous email on the suggestion, i.e.,

Yes, lets deal with RAMS usage in Tom's draft.

> 
> 
>> 
>>>>> 
>>>>> Assume the intermediary sits between media source and
>>>>> receiver, we can ask intermediary to measure the round trip
>>>>> time between media source and intermediary, the round trip
>>>>> time between intermediary and receiver to make sure the media
>>>>> source is more near to the intermediary than the receiver.
>>>> 
>>>> Yes, that makes sense. But what method(s) of measuring are you
>>>> proposing for the intermediary?
>>> 
>> Well, does that work? Is the intermediary receving the RTCP RRs
>> from the receivers. And what way have they taken to reach the
>> intermediary.
>> 
>> But I have to say that I have become confused in which model we
>> are discussing here.
> 
> 
> all the use cases. So the general questions here are what's your
> suggestion about how to document measurement
> 

I think you need to discuss the general cases with summary and simple
feedback modes being very different. In fact simple feedback seems to
have very little use of the TPLR as long as the MS and DS are the same
entity.

I think the reasonable thing is to ensure that all cases are covered.

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 22 Sep 2011 23:04:06 +0200

Qin,

Hope this answers your questions.
Tom 

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: maandag 19 september 2011 10:34
To: Van Caenegem, Tom (Tom); Magnus Westerlund
Cc: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Hi,
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 16, 2011 7:00 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Qin,

Tom: well, my STARTING assumption is that receivers receiving a NACK, do implement FB suppression, independent from the SSRC inside. Is RFC 4585 saying that if SSRC is not known, the NACK  is ignored by receiver (and FB suppression is cancelled)?

Tom: indeed. And that's where FB suppression has an unfortunate side-effect for a RAMS like topology with multiple BRS-es. And that's one of the reasons why I submitted the draft.

So in my understanding, additional rule you proposed is like conditional FB suppression for receivers, in other words, the receiver selectively does FB suppression based on the SSRC delcared. 

Tom: indeed, selective -or conditional- feedback suppression is the (desired) result.

My question is does it conflict with RFC4585? 

Tom: it does "conflict" with the RFC 4585 rules with respect to a receiver's behaviour, but this new receiver behaviour for SSM with RAMS architecture is to make the overal system (retransmission service) work better without increasing risk on FB storm. The driver for creating new IDs and RFCs is making things better, no? 

Is it optional choice or 

Tom: RFC 4585  disallows the receiver to send a NACK when receiving a NACK. What the retransmission for ssm -ID says is that receiver MAY send a NACK, when the NACK or TPLM has an SSRC identifier that is not the one of its BRS (nor of the DS). This is independent from the number of receivers reporting to this BRS or the total number of receivers in the SSM group.

Regards=

---

From: Qin Wu <[email-masked]>
Date: Fri, 23 Sep 2011 10:53:21 +0800

Hi, Tom:
Thank for your clarifications, which do answer my questions. please see my suggestions below.
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 23, 2011 5:04 AM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Qin,

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: maandag 19 september 2011 10:34
To: Van Caenegem, Tom (Tom); Magnus Westerlund
Cc: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Hi,
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, September 16, 2011 7:00 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Qin,

[Qin]: I think this is not clear from reading RFC4585, however if you look at the section 3.5.2, Step 5b),  it said:
"
If R understands the received FB message's semantics and the
 message contents is not a superset of the feedback R wanted to
send, then R SHOULD transmit its own FB message as scheduled.
"
I think you need to expand Receiver behavior based on this paragraph regarding FB suppression.

However according to RFC4585, if NACK or TPLM is allowed to send to all the receivers, all the receivers should react to the receiving NACK or TPLM following rule defined in RFC4585 rather than ignore  or discard it when SSRC in NACK or TPLM is unknow.

[Qin]: Agree. In RAMS session, if BRS cache the packet which the receiver is ask for,it is better not to suppress receiver sending unicast NACK to ask for its lost packet. if BRS does not cache that packet due to upstream packet loss, such packet loss affect all the receiver, therefore it is better to supress receiver sending unicast NACK.  

[Qin]: True.

[Qin]: As I said above, if the receiver is allowed to send unicast NACK to RS to ask for lost packet if RS keep that packet for retransmission,  it think this is reasonable to have independent document to talk about such optimization. In this case, if RS has already cached that packet, NACK for that packet should not be sent from DS to all the receivers, rather than RS itself compensate this lost packet by sending retransmission packet in response to each retransmission request. However if RS does not have that packet, the RS can choose to forward NACK or send TPLR via DS to the remaining receiver.

My suggestion is to be clear about this in your draft.
Another suggestion is your draft should more focus on RAMS case.In the introduction it is better to clarify what the downside of using FB suppression rule defined in RFC4585 in the RAMS session.

Is it optional choice or 

[Qin]:I think this is another optimization you can do. Since BRS know how many receivers it has and it can determine if sending NACK or TPLR via DS to the receivers to avoid uncessary NACK or TPLR.

Regards=

---

From: Qin Wu <[email-masked]>
Date: Fri, 23 Sep 2011 15:04:18 +0800

Hi, Magnus:
I agree with your comments below and will issue new version to address these comments soon.
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 22, 2011 11:34 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Qin]:Okay.

> If the conclusion is that TPLR is not applicable to this case I think we

[Qin]: Yes, that is what I said.

> It can only use the RTT distribution received from the DS based

[Qin]: Exactly.

[Qin]: Yes.

[Qin]: Okay.

> I think the reasonable thing is to ensure that all cases are covered.

[Qin]:Yes. Fully agree.