Transport independent SDP bandwidth modifier: was Re: [MMUSIC] Draft MMUSIC minutes from Atlanta

[Magnus Westerlund <[e-mail]>]

Hi Colin,

I have one comment on the reporting of below item:

Colin Perkins wrote:

>A Transport Independent Bandwidth Modifier for SDP
>
>   Magnus Westerlund outlined draft-westerlund-mmusic-sdp-bwparam-01.txt,
>   on a new set of SDP bandwidth modifiers that signal session bandwidth in
>   a transport independent manner. These are intended to solve problems due
>   to NATs and protocol translation, that make the existing parameters less
>   than useful.
>
>   Steve Casner noted that biggest open issue is whether we really need to
>   make the change at all? Magnus noted that the bandwidth can increase by
>   25% with IPv6, compared with the value currently signalled, a compelling 
>   argument for the new parameters. Steve disagreed, noting that the RTCP
>   bandwidth doesn't have to be that accurate, and that this level of
>   inaccuracy is unlikely to be problematic. He also said that a stronger
>   point is bandwidth allocaton for links, where it seems likely that for
>   tightly controlled channels, header compression will be used, so the
>   difference between v6 and v4 goes away. 
>
>  
>
To my understanding Steve did not comment on the general usefulness of the attribute, only the RTCP part. I have thought about it a bit and think I can satisfy with a note in the draft explaining the RTCP issue and what normal cost will be and that it is normally not significant enough to warrant any fix. 


Some numbers and explanation on how the RTCP bandwidth and fairness is affected by transition between IPv4 and IPv6. 

Worst Case:
The worst case is a large group where a single user sits on a IPv6 network and all other participants uses IPv4. In this case when the number of participants increase towards infinity the bandwidth share coming from IPv4 network will become 1.0. In this case the bandwidth will increase with the IPv6 overhead compared to IPv4 times the number of packets. The number of packets is depending on the RTCP packet size. The smallest possible RTCP packet including IPv4/UDP overhead is 46 bytes which is a correctly formed with RR and SDES CNAME, but information wise an empty packet. With a full utilization of the assigned bandwidth the increase in overhead is 20/46 = 43.5%. A bit more realistic RTCP packet with a useful CNAME tag of 14 chars and a Receiver Report the packet size for IPv4/UDP/RTCP is 80 bytes. A 80 byte packet gives the 25% increase in RTCP bandwidth. The larger the average RTCP packet becomes ,the less effect on the total bandwidth the IPv6 overhead has. For a 120 byt!
es packet the increase in bandwidth has dropped to 20/120 = 16.7%

A common unicast case:
In the case of two sources communicating with unicast between a IPv4 and a IPv6 domain the number becomes different. The packet size from above still applies but the communication frequencies are different. In this case only half of the RTCP bandwidth is assigned to the IPv4 located participant. Also in cases with at least moderate session bandwidths the participants will not full utilize it unless the minimum interval rule of 5 second is removed. All this given that the bandwidth is used fully the increase on the IPv6 side will be 21.75% for minimal packets. For more realistic packets its only at most a 12.5% increase.

Summary of increase on IPv6 side:

		Packet sizes
Communication | Worst case    Realistic
--------------|-------------------------
Worst Case    |  43.5 %       21.75 %
Unicast       |  25 %         12.5 %


Fairness:
The fairness seen over longer time is that a IPv6 host will send avg_rtcp_size/(20+avg_rtcp_size) as often as the IPv4 host. On a short time scale this will not become evident due to the 0.5 wide randomization of sending intervals.


The fairness factor for different sizes is:
avg_rtcp_size   Fairness
46              0.70
80              0.8
120             0.86

Conclusion:
Seen from the above figures an IPv6 host can in absolute worst case get a 44% increase, i.e. compared to a session with 5% RTCP bandwidth the total session bandwidth increase will be 2.1 %. In a more realistic case the figures would result in 0.6% increase. This is rather marginal compared both to variations in media bitstream rate and what the RTCP randomization rule can result in. 



-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic