[AG-TECH] Listing Venue Server addresses

[Christoph Willing]

On 17/02/2007, at 5:51 AM, Derek Piper wrote:

>
> 	This is good stuff to talk about.
> 	If you only have 2 addresses though, wouldn't it be better to  
> divide the 2 IPs between venues and keep the same IP within a venue  
> since, like you said, all traffic goes to clients regardless of port?
>
> i.e.
> Scenario 1:
>
> Venue 1
> 	Audio: 233.100.100.1 / 20000
> 	Video: 233.100.100.1 / 20002
>
> Venue 2
> 	Audio: 233.100.100.2 / 30000
> 	Video: 233.100.100.2 / 30002
>
> Venue 3
> 	Audio: 233.100.100.1 / 40000
> 	Video: 233.100.100.1 / 40002
>
> Venue 4
> 	Audio: 233.100.100.2 / 50000
> 	Video: 233.100.100.2 / 50002
>
> is better than
> (Scenario 2)
>
> Venue 1
> 	Audio: 233.100.100.1 / 20000
> 	Video: 233.100.100.2 / 20002
>
> Venue 2
> 	Audio: 233.100.100.1 / 30000
> 	Video: 233.100.100.2 / 30002
>
> Venue 3
> 	Audio: 233.100.100.1 / 40000
> 	Video: 233.100.100.2 / 40002
>
> Venue 4
> 	Audio: 233.100.100.1 / 50000
> 	Video: 233.100.100.2 / 50002
>
> since clients connected to Venue 1 would ALSO receive data from all  
> the other venues, even if it was filtered by port?
>
> 	So, if you have limited addresses then dividing them wholely  
> between venues (i.e. NOT doing what you mentioned, Chris) would be  
> the smarter configuration because if you have 2 meetings running  
> simultaneously then you can support 2 separations, i.e. Venue 1 &  
> 3, and Venue 2 & 4 with Scenario 1. With Scenario 2 because we  
> spread our addresses over ALL the venues trying to have a different  
> IP for audio and video if we have 2 meetings at once we're always  
> going to be sending data to ALL participants over both meetings and  
> using more bandwidth.
> 	Of course, if you have the addresses then it's smarter not to have  
> any overlap, I agree. But, for static addressing when there may not  
> be many addresses available then it is probably wiser to organize  
> things so that simultaneous meetings are separated, not necessarily  
> audio/video sources.

Derek,

Thats quite correct, I am separating audio & video in the context  
"unlimited" address space availability.


Another problem with having so few addresses available is how AG3's  
built in multicast beacon will work; its address is normally assigned  
dynamically. Even if you can set it explicitly, I'm not sure what  
sort of results it will produce when multiple beacons (for different  
venues) are using the same address.

That beacon address problem would apply to all services with  
dynamically assigned streams.


chris



> Thomas D. Uram wrote:
>> Chris makes a good point, one that I applied when assigning addresses
>> to the vv3/ivs servers.  The simplifications I applied were to  
>> have the
>> audio and video addresses be sequential, and have the ports always  
>> the
>> same (20000 for audio, 20002 for video).
>> On 2/16/07 12:16 AM, Christoph Willing wrote:
>>>
>>> On 16/02/2007, at 3:16 AM, Derek Piper wrote:
>>>
>>> [snip]
>>>>     While talking about the venue management tool it would be  
>>>> nice to be able to restrict it to a single IP address for  
>>>> multicast (and just let it dynamically assign ports). As it is,  
>>>> the mask only allows for 0-31, where I need '32' in order to  
>>>> lock it down as such. I was given two addresses but they do not  
>>>> fit within one /31 CIDR range (of course :>).
>>>
>>>
>>> Derek,
>>>
>>> There may be problems for clients when using that strategy (using  
>>> a single IP, but different ports for different venues) for  
>>> bandwidth challenged clients. Even when they're only connected to  
>>> a single venue, the traffic from all the other venues sharing the  
>>> same IP address would flow to the client as well. A client can  
>>> filter based on port number, but all other (unwanted) traffic on  
>>> the same IP address has also arrived regardless of using a  
>>> different port (only to be filtered out anyway). Using different  
>>> multicast IP addresses means that only the requested streams flow  
>>> to the client. In fact, we now configure our server to use  
>>> different IP addresses for audio & video in the same venue.
>>>
>>>
>>> chris
>>>
>>>
>>>
>>> Christoph Willing                       +61 7 3365 8350
>>> QCIF Access Grid Manager
>>> University of Queensland
>>>
>>>
>>>
>>>
>
> -- 
> Derek Piper - dcpiper at indiana.edu - (812) 856 0111
> IRI 323, School of Informatics
> Indiana University, Bloomington, Indiana

Christoph Willing                       +61 7 3365 8350
QCIF Access Grid Manager
University of Queensland