Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

[Roni even <[e-mail]>]

Magnus,
The report has the maximum and minimum values, so the receiver can use the maximum value or estimate his RTT based on his position between the minimum and maximum
Roni

________________________________________
From: Magnus Westerlund [[e-mail]]
Sent: Thursday, November 03, 2011 15:27
To: Roni even
Cc: Qin Wu; 'IETF AVTCore WG'; [e-mail]
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

On 2011-10-24 16:42, Roni Even wrote:
> Hi Magnus,
> Maybe we can add a recommendation for SSM to use the round trip sub report
> block specified in section 7.1.6 of RFC 5760
> (http://tools.ietf.org/html/rfc5760 ) to distribute the RTT from the
> distribution source to the receivers.

Well, that report is really the distribution for the whole session. If
one actually want that it can't be combined with only reporting the
distribution for a subset of the participants.

Cheers

Magnus

>
> Roni
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Magnus Westerlund
>> Sent: Wednesday, October 19, 2011 11:09 AM
>> To: Qin Wu
>> Cc: IETF AVTCore WG; draft-ietf-avtcore-feedback-supression-
>> [e-mail]
>> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-
>> supression-rtp-07
>>
>> Hi,
>>
>> Sorry for the delay in following up.
>>
>> I have removed the issues which don't need further discussion.
>>
>>
>> On 2011-10-11 03:40, Qin Wu wrote:
>>> Hi, Magnus,
>>> Thank for your valuable review, please see my replies belows.
>>> ----- Original Message -----
>>> From: "Magnus Westerlund" <[e-mail]
>>
>>> 2. Section 3.
>>>   "The timer value shall be
>>>    based on the observed round-trip time.  A receiver should compute
>> an
>>>    estimate of the round-trip time (RTT) to the sender of TPLR from
>> RTCP
>>>    report round-trip time if available, or its reception time of the
>>>    reflected RTCP FB message (e.g.,NACK), or any other means."
>>>
>>> We hade the discussion before but now that you clarified which RTT to
>> be
>>> used, I think it is worth having a discussion if that RTT is the
>> right
>>> one. So you suggest that the RTT between the sender of the TPLR and
>> the
>>> receiver of the message is the most appropriate to use when
>> suppressing
>>> the message. I am not certain that is the case.
>>>
>>> Lets consider the use cases. In the case of an intermediary in a
>>> distribution tree sending the TPLR and at the same time sending a
>> NACK
>>> upstream. Then the time until the retransmission reaches the
>> suppressed
>>> receiver is the time from the sending of the NACK up to the
>>> retransmitting entity and all the way down past the TPLR sender to
>> the
>>> suppressed receiver. The receiver may not have a true RTT to the
>>> original media sender as that source appears to live at the TPLR
>> sender,
>>> not further upstream.
>>>
>>> Yes, the sender of the TPLR and the receiver might at least have
>> mutual
>>> knowledge of each other, thus the TPLR sender is able to determine
>> the
>>> lowest RTT in the set of receviers thus determining how often to
>> repeat
>>> it to cover additional time requried for the upstream part of the
>>> request. But I do note that these times aren't matching what appear
>> to
>>> be the delays in the systems.
>>>
>>> Can we find a better solution?
>>>
>>>
>>> [Qin]: It looks to me the round trip time between media source and
>>>
>>>  intermediary is trivial if we assume the intermediary is much
>>>
>>> closer to the source, that is why I put the last paragraph in the
>>>
>>> section 3 as follows:
>>>
>>> “
>>>
>>> In order not to incur a lot of NACK requests due to additional TPLR
>>>
>>> described above, it is recommended that the RTP system sending
>>>
>>> TPLR should be implemented more closer to the source. Also when
>>>
>>>  the loss was detected and repair initiated much closer to the
>> source,
>>>
>>> the delay for the receiver to recover from packet loss can be reduced
>>>
>>> through the combination of intermediary feedback to the source and
>>>
>>> Third Party Loss Report downstream.
>>>
>>> ”
>>>
>>>
>>>
>>> If we look for a better solution, I think we have two possible ways:
>>>
>>> The first way is to rely on sender report from media sender to
>>>
>>> calculate the more approximate RTT from media sender to the receiver.
>>>
>>> RTT measurement method follows the same way described in the
>>>
>>> figure 2 of RFC3550.
>>>
>>>
>>>
>>> The second way is to we can allow the intermediary tell the receiver
>> the
>>>
>>> RTT from media source to intermediary itself by sending a new message
>>>
>>> since the intermediary can measure such RTT based on past observation
>>>
>>> and estimation. However for the second way we need to define new
>>>
>>> message or extend TPLR message to carry such RTT.
>>>
>>>
>>>
>>> What do you think?
>>>
>>
>> From follow up email:
>>> Hi,Magnus: As regarding if there is better solution, I have some
>>> corrections and additional thoughts.
>>> I think If the media source is the repair server, the receiver should
>>> set timer to T1=max(the RTT from media source to middlebox sending
>>> TPLR, 1/2 of RTT from middlebox to receiver) when the receiver
>>> receives first TPLR. When the receiver receive addtional TPLR within
>>> T1, the receiver should reset the timer to the RTT from media source
>>> to middlebox sending TPLR.
>>>
>>> If the middlebox is the repair server, the receiver should set the
>>> timer to T2=1/2 of RTT from middlebox to receiver when the receiver
>>> receives first TPLR. When the receiver receive addtional TPLR within
>>> T2, the receiver should reset the timer to the T2.
>>>
>>
>> Can you express these rules for the receiver as something that is based
>> on what is observable from the RTP and RTCP traffic? Is when media
>> server being repair server equal to TPLR sender SSRC = Media SSRC the
>> TPLR applies on? And if they are not the same it is the second case?
>>
>>
>>
>>>
>>>
>>> 3. Section 3:
>>>   "To increase the robustness to the loss of a TPLR or of a
>> transmission
>>>    packet, a receiver is allowed to receive additional TPLR for the
>> same
>>>    packet.  In the case the first TPLR is lost and the additional
>> TPLR
>>>    arrives at the receiver, the receiver should immediately refresh
>> the
>>>    timer."
>>>
>>> In the second sentence I don't see how the receiver can know that it
>> is
>>> a retransmission. It is simply a TPLR from its perspective if that is
>> lost.
>>>
>>> Robustness reasons is only one reason for repeating them the other is
>>> clearly to renew the timer. Thus I think the formulation should be
>> more
>>> generic to make it clear that all receivers should upon reception of
>> a
>>> TPLR refresh the timer for the packets indicated.
>>>
>>>
>>>
>>> [Qin]: If the receiver does not keep state for the times the TPLR is
>>>
>>>  retransmitted, we can add repetition count field in each FCI entry
>>>
>>>  of TPLR feedback message to indicate the times TPLR is
>> retransmitted.
>>>
>>>  Particularly in PSLEI Feedback Message, we can reuse seq nr. Field
>> to
>>>
>>>  indicate if additional TPLR is retransmitted, which one you think
>> better?
>>>
>>>
>>
>> How, can the receiver keep state for something it has not seen due to
>> the initial packet not having been received?
>>
>> I don't think we need new packet extensions, just clarified rules that
>> correctly describe what the RTP end-point should do when it sees the
>> TPLR message.
>>
>>
>>>
>>> 7. Section 4.2:
>>>    Seq nr:8bits  Command sequence number.  It is used by the Command
>>>       receiver to check if the Command is repeated.  The sequence
>> number
>>>       space is unique for each pairing of the SSRC of command sender
>> and
>>>       the SSRC of the command receiver.  The sequence number SHALL
>>>       increase by 1 modulo 256 for each new Command.  A repetition
>> SHALL
>>>       NOT increase the sequence number.  The initial value is
>> arbitrary.
>>>
>>> Based on that it is defined that upon receiving one of the PSLEI
>>> request, one shouldn't send a FIR or PLI message for a time interval
>>> equal to the RTT between the receiver and the sender of the PSLEI
>>> message does the sequence number field have any meaning? From my
>>> perspective it doesn't matter if it is a new request or not. You are
>>> suppressed from the reception of the message, nothing else.
>>>
>>> [Qin]: I think we can use seq nr field to indicate the times the TPLR
>> is
>>> retransmitted, e.g.,
>>>
>>> If the additional TPLR with the same SSRC and different Seq Number is
>>> received, the
>>>
>>> receiver knows that it is a retransmission if the receiver keeps
>> state
>>> for the previous
>>>
>>> TPLR with the same SSRC.
>>>
>>> Also we can replace seq nr. Field with Repetition count field to
>>> indicate how many time
>>>
>>> the TPLR is retransmitted.
>>>
>>>
>>
>> That is possible, but is the repetition count really providing
>> anything?
>> What is the simplest most straight forward that can work? I think that
>> is that one simple suppress the source for X time after having receives
>> a TPLR message indicate that source. So, as long as you get repeat
>> messages more often than X you continue to be suppressed. Will the
>> receiver work better to know that it is now suppressed for Y times in a
>> go because of the same event?
>>
>> 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]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>
>


--

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