Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2011-01-14 19:33:
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
>> Sent: Friday, January 14, 2011 6:09 PM
>> To: IETF AVT WG; [e-mail]
>> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior
>>
>> Hi,
>>
>> In Section 4, there is some statement about resending. I want to come to
>> some conclusion on this topic that was brought up before.
>>
>> The basic issue is the question on how one detects packet loss for RTCP.
>> There is no other mechanism than detecting lack of response / action
>> from the corresponding peer.
> 
> Indeed and that is what we do.
>  
>> The issue I have is that the RTT + server delay in responding can easily
>> be many times the minimal sending interval that RTCP configure to serve
> 
> Hmm, why unless you have an awfully slow server? If the server is really that slow, then I guess the system has more major issues than just losing the token request messages.

The problem isn't really in that. The issue is that the minimum interval
period for sending RTCP can be configured to not exist, "immediate"
mode. Also even in early mode AVPF can you configure an RTCP bandwidth
that allows you to send packets very often and rapidly.


> 
>> even 1 mbit/s stream. Thus the formulation in the draft:
>>
>> "When a client sends a
>>    Port Mapping Request or Token Verification Request message but it
>>    does not receive a response back from the server (either a Port
>>    Mapping Response or Token Verification Failure message), it MAY
>>    resend its request by following the timer rules defined for RTCP
>>    feedback messages in Section 3.5 of [RFC4585] as a good practice."
>>
>> Might not be sufficient. Because the issue is how one detects the packet
>> loss and how quickly the packet is considered lost.
> 
> Well, we cannot say "wait X seconds before you ask again" unless you wanna propose a value of X.
> 

The algorithm I have in mind would be 1.5*RTT to the server in question
+ Y server processing delay. I think Y can be fairly small a few ms,
like 5 ms. Unless you know that the processing delay is going to be
bigger. Then add exponential backoff for detecting additional
consecutive packet losses.



If you don't know RTT, then at least 100 ms in a managed network
situation, otherwise I would go with TCP's 500 ms as initial backoff.
And for the initial mapping request, using 500 ms may not be a big issue.

However, it is problematic to measure the RTT using RTCP in this
setting. This as the client can't include an SR that the server can
respond to. One would need to use XR's extensions for RTT measurement to
achieve that.

> I understand this is not perfect but I don’t think there exists anything better than the rules we have in place. Re-using them is easy for implementation as well.

The issue is that with RTCP bandwidth values configured differently,
then you can have a lot of spurious retransmissions.

>  
> BTW, the same problem exists with NACKs or other RTCP packets that can actually create a lot of traffic. Ours is merely a corner case IMO.
> 

Agreed, and this is probably something that a future update should
strongly consider to discuss.


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