Hi Chris,
The A/V Edge enables relaying of real time media traffic (RTP packets), which can be carried over UDP or TCP. UDP is preferred because when one packet is lost, delivery of subsequent packets is not disturbed and the OCS media stack can surprisingly large number of dropped packets without noticible audio quality degredation. With TCP, losing one packet will cause the TCP stack to halt delivery of subsequent packets to the media stack until that packet is retransmitted and received. This introduces higher latency in environments with higher packet loss, which is why UDP is preferred and TCP is used only if UDP isn't available.
Because of this need to relay UDP, the AV Edge looks different than a typical web server that listens only on TCP. All load balancers support TCP affinity due to the connection oriented nature of TCP, and the OCS clients do rely on this for TCP connections. Specifically, when OC makes a TCP connection to the A/V Edge via the load balancer, the connection remains through the load balancer.
With UDP, some load balancers can do UDP "stickiness", but it's not as deterministic because UDP is a connectionless protocol. So when we designed the A/V Edge load balancing architecture (when I was on the OCS product team), we implemented a design that did not rely on UDP affinity for load balancers. When clients send the first UDP packet through the load balancer, it'll get forwarded to a particular AV Edge instance. In the response UDP packet, the AV Edge includes its own IP address as a parameter. The client receives the IP address of this AV Edge instance in the response packet and sends subsequent packets directly to that IP address instance.
You can see how this UDP behavior differs considerably from a typical load balanced server that only listens on TCP. This is what trips people up usually with load balancers in OCS. In a two-armed topology, the load balancer must be configured to act both as load balancer exposing the appropriate VIPs AND as a router so traffic can be sent directly to the AV Edge. The requirement for this router behavior is one reason why you can't do NAT in a load balanced AV Edge deployment. (Another reason is if you need to expose the 50,000 port range, those ports need to be reached directly by clients without any NAT taking place.)
You may wonder why NAT is supported in non-load balanced environments. Remember that "self" IP address that the AV Edge instance returns on the first UDP packet? Well, in OCS 2007 R2, the AV Edge now exposes a setting that tells the AV Edge to change that IP from a "self" IP to the IP resolved by the external AV Edge FQDN. So subsequent UDP requests go to that same public IP instead of the NATed IP address. This works in a non load balanced environment because the there's only one AV Edge instance to forward to. (Now in theory, an admin could configure this setting in a load balanced environment and rely on the load balancer’s UDP stickiness behavior to do the right thing. This is not a supported configuration, and I have never heard of anyone trying this. But it would be an interesting exercise to do in a lab environment.)
I haven't figured out how to attach diagrams to these responses, but here is a link to a mirrored post on my blog that shows a couple sample topologies for load balancing the edge in a one-armed and two-armed topology. Where needed, you can see that the router symbol on the Load Balancer indicates you need to configure routing functionality in addition to VIP functionality. Here are the direct links to the JPGs.
http://www.unifysquare.com/blog/file.axd?file=2009%2f10%2fLoad+Balanced+One-armed.jpg
http://www.unifysquare.com/blog/file.axd?file=2009%2f10%2fLoad+Balanced+Two-armed.jpg
Hope that helps…
Thanks,
Alan
MVP and OCS MCM
