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

[Qin Wu <[e-mail]>]

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


On 2011-09-05 06:06, Qin Wu wrote:
> Hi, Magnus:
> Thank for your valuable review. please see my replies below.
> 
>> ----- Original Message ----- 
>> From: "Magnus Westerlund" <[e-mail]>
>> To: <[e-mail]>; <[e-mail]>
>> Sent: Thursday, September 01, 2011 10:52 PM
>> Subject: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

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

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.

[Qin]: Okay.

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

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.


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


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

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

[Qin] See above.

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

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.

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

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

That is fine with me.

[Qin]: Okay, I will do some wordsmith to this part.
> 
> 
>> 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.
> 
> 
> [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?

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]: Agree and will follow option (1).

> 
>> 7. Section 4.2:
>> 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.

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

[Qin]: I see.

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

Agree

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

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

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

[Qin]: Okay.

> 
>> 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.
> 
> [Qin]:I think you are right and will follow your advice.
> 
>> 9. Section 10.1:
> 
>> I wonder is really RFC 5117 a normative reference? The reason is that is
>> an informational RFC.
> 
> [Qin]: Okay, I will put it as informative reference.
> 
>> I haven't finished reviewing section 6 and 7 and will send a follow up
>> when that is done.

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

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------