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

["Ali C. Begen (abegen)" <[e-mail]>]

OK, I see your concern, however, should not we still follow 4585 as it is and once it gets updated, it will be reflected here? If the immediate mode is chosen, the NACK/RAMS could result in many more spurious transmissions whereas the token stuff only results in one such transmission. So putting some extra rules here for the tokens only will not get us much.

Maybe, we can add some text to disallow the immediate mode?

-acbegen

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Monday, January 17, 2011 5:31 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [e-mail]
> Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior
> 
> 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]
> ----------------------------------------------------------------------