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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 18:08:40 +0100

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.

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

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:33:09 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Friday, January 14, 2011 6:09 PM
> To: IETF AVT WG; [email-masked]
> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior
> 
> Hi,
> 

Indeed and that is what we do.
 
> 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.

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

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

-acbegen

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 11:30:36 +0100

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

> 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