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

[Qin Wu <[e-mail]>]

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


> On 2011-09-16 12:18, Qin Wu wrote:
>>>>> 
>>>>>> 5. Section 3, fourth paragraph:
>>> 
>>> 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, 

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

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

> And I think the question is still what RTT one uses in these
> measurements. 

[Qin]: See above.


>The one related to the media server, or one related to the
> SSRC injecting the TPLR. They don't need to be the same.

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

> 
>> 
>> 
>> 
>> 
>>> 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.
>> 
>> 
>> [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.
>> 
>> [Qin]: We don't need to support various implementation choices.
> 
> 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.

[Qin]: Okay.

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

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

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

[Qin]: Okay.

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