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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 05:24:00 -0800

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:[email-masked]]
> Sent: Monday, January 17, 2011 5:31 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [email-masked]
> 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: [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,
> >>
> >> 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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 16:04:24 +0100

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

You seem to be punting on this issue. I think Immediate mode needs to be
allowed, it makes all the sense for these type of applications in
certain environments. However, what is needed is a separation of the
"packet loss" / "failure for server to act on event" detection mechanism
and the RTCP transmission rate limiting.

I think despite our discussion of these things in CCM (RFC 5104) we did
fail to take all the AVPF cases into account. I have to say that 3.5.1.1
do rely on repeating FIR messages until you get an result. It does fail
to say in which mode and what type of transmission should be used for
the repetitions. This as one in early mode, this is either classified as
an event that are allowed to send early, or as a regular transmission.

There need to be some sanity checking in this, and going forward being
aware that what we specify can be seriously broken is not the best
thing. In addition RAMS can be fixed. And the NACK still doesn't have a
spec for this use case.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 05:10:47 -0800

> Sent: Monday, January 17, 2011 10:04 AM
> > 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.
> >

Did not even cross my mind :)

> and the RTCP transmission rate limiting.

Well said, but with RTCP one can do so much.
 
> thing. In addition RAMS can be fixed. And the NACK still doesn't have a

OK, let me ask you this. Even if we come up with a miracle solution for the token stuff, that still does not fix the bigger issue that one might have with NACKs (I am omitting RAMS here since RAMS has some other natural limits, e.g., a client would not really have multiple outstanding RAMS requests unless it is attacking the system).

So, maybe we should actually talk about fixing this in general for 4585?

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 15:27:25 +0100

> Well said, but with RTCP one can do so much.

Ok, can we at least point out that this issue exist and that
implementations needs to do something reasonable about detecting loss,
and not soley rely on sane configuration values of the RTCP bandwidth.

> So, maybe we should actually talk about fixing this in general for 4585?

I do agree that RFC 4585 should be updated to take this issue into
consideration.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 19 Jan 2011 07:24:06 -0800

> Sent: Wednesday, January 19, 2011 9:27 AM

OK, we will mention this and add a warning.
 
> > OK, let me ask you this. Even if we come up with a miracle solution for the token stuff, that still does not fix the bigger issue
> that one might have with NACKs (I am omitting RAMS here since RAMS has some other natural limits, e.g., a client would not
> really have multiple outstanding RAMS requests unless it is attacking the system).
> >

Cool. That will help us in the long term.
-acbegen