Subject: [AVT] Delaying media sender action on increased TMMBR values

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Mar 2007 17:37:54 +0200

Hi,

During the TMMBR offline discussion there was discussion regarding a 
media sender delaying increasing its bit-rate until other session 
participants has had the possibility to signal a new TMMBR message. This 
occur after either a current owner has timed out or indicated that it 
raises its limitation. If the media sender allows enough time for the 
receiver to send their TMMBR messages one can avoid overtaxing other 
known limitations. Thus the question is what sufficient time is.

The minimal time needed to ensure that all participants has had a 
reasonable chance of responding is to wait 1*Longest_RTT + T_dither_max 
after the TMMBN indicated a raise in a limit has been sent, where 
T_dither_max is defined in RFC 4585. In early RTCP feedback it is either 
0 for point to point sessions or 0.5* T_rr (regular RTCP reporting 
interval). To allow the receiver some processing time and handling of 
network jitter I propose we say 2*longest_RTT + T_dither_max to help 
ensure that the media sender waits long enough. Thus I would propose 
that we add the following recommendation to the TMMBR draft:

A media sender, receiving a TMMBR message from an owner raising a 
limitation or having an owner time-out from the session, will send a 
TMMBN message notifying the session about this fact. After having sent 
the TMMBN the media sender is RECOMMENDED to delay acting on the removal 
of the limitation for 2 * Longest_RTT + T_dither_max. "Longest_RTT" is 
the largest by the media sender measured RTT to any of the session 
participants in the session. T_dither_max is defined in Section 3.4 of 
RFC 4585. This allow the session participants to react to the changed 
limitation and give them time to transmit an TMMBR message of its own to 
the media sender if it has a more restrictive limitation.

Comments?

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Randell Jesup <[email-masked]>
Date: Tue, 27 Mar 2007 13:32:16 -0400

Magnus Westerlund <[email-masked]> writes:
>Thus I would propose that we add
>the following recommendation to the TMMBR draft:
>
>limitation or having an owner time-out from the session, will send a TMMBN
>message notifying the session about this fact. After having sent the TMMBN
>the media sender is RECOMMENDED to delay acting on the removal of the
>limitation for 2 * Longest_RTT + T_dither_max. "Longest_RTT" is the largest
>by the media sender measured RTT to any of the session participants in the
>session. T_dither_max is defined in Section 3.4 of RFC 4585. This allow the
>session participants to react to the changed limitation and give them time
>to transmit an TMMBR message of its own to the media sender if it has a
>more restrictive limitation.
>
>Comments?

Seems good to me; but wouldn't this only apply to a multipoint session
(i.e. more than one receiver, whether unicast or multicast)?  While that
might be obvious, it may not hurt to mention that (unless it's implied by
the subsection this appears within).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Mar 2007 10:56:40 +0200

> the subsection this appears within).

Yes, in general I agree with this notion. The only problem is that it is 
sometimes hard to determine that you are having a true point to point 
session where all other sources not present in your application instance 
are directly located on the other side of the path rather than being on 
different peers behind a translator or mixer. Going for a session where 
the rule is based on SSRCs is of course simpler but not correctly 
reflecting all cases. T_dither_max also becomes 0 in some case according 
to AVPF. I have some small issues with the wording, but I think the 
intent is clear in RFC 4585.

Lets see what we can word smith in.

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 28 Mar 2007 18:12:36 +0200

Hi,
I think this is why you have RECOMMENDED in the text.
To me the explanation about why to wait looks good
Roni 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2007 10:57 AM
> To: Randell Jesup
> Cc: IETF AVT WG
> Subject: Re: [AVT] Delaying media sender action on increased TMMBR values
> 
> Randell Jesup skrev:
> TMMBN