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

[Qin Wu <[e-mail]>]

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


> Hi,
> 
> I think the discussion has become so convoluted that it is difficult to
> 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.


> 
> On 2011-09-19 07:36, Qin Wu wrote:
>> 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.
>> 
> 
> 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.
> 

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



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


[Qin]:Yes, Agree. 


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


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



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




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



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



[Qin]: Agree.


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


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


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