Mixer Operation

The mixer is an application level program that is table driven. Basically, it is a cousin of the NV to CUSeeMe reflector program (or monstermash program), that receives multicast, and forwards to unicast, and receives on unicast and forwards to multicast based on maplets based on table entries created and deleted by RLJMP messages.

The mixer may optionally apply priorities to the traffic (a la Class Based Queuing). For example a site might be down the end of a 64kbps ISDN dial up uncast link to the remote mbone. A default might be that a mixer priorities audio, then whiteboard, then video. An implementation hack might be that the forwarding loop of the mixer simply ignores overlimit input queues (this is tricky if people multiplex media on the same port and the same multicast address or we want to treat different sources differently, but will be easy otherwise).

  

Table 7.4: Mixer Operation

As well as configured defaults at the mixer, we may want to specify priorities. One possibility is to implement an RSVP client in the modified session descriptor client and an RSVP server in the mixer. Easier might be a simply mix-to-priority.

To decide on overlimit actions, the mixer also needs to know the bandwidth between it and the unicast client. This can be configured or monitored through spying on RR messages perhaps.

Finally, a refinement of the model above might permit a user to specify priorities w.r.t sources of traffic (Source Descriptor fields or source IP address + port if available can be used to decide which class a flow belongs to).

The bandwidth (shared link) between the mixer and the unicast site is gleaned through some other process (e.g. configured through management). For further study is how an overlimit action might trigger demand for more bandwidth, again through some other configured information (basically derived from policies at the mixer and user site concerning costs and so forth).

Soft State

The mixer MUST fail to not forwarding to a unicast site, since the act of forwarding uses possibly expensive bandwidth. This is achieved by timing out maplets in the table. Though the entry can be kept, it is marked as "idle" after timeout T1, and only deleted after a longer timeout T2. The entry is refreshed by repeated RLJMP messages from the modified SD client at the unicast site. The refresh time (T3) is hopefully shorter than the idle timeout T1. Typical values of T1 will be set long enough to not incur costly control traffic on the link, and T2 short enough to close the link after application failure or abort/hangup by abrupt user without incurring costly forwarding of multicast traffic down the unicast link.

Unicast Hop

The mixer and session directory server may be co-located. Further, they may be co-located on the unicast router immediately at the end of the unicast hop from the user site to the mbone. More likely, they are a little way off from this. If the unicast hop is a bandwidth on demand circuit, the RLJMP is a way of implicitly controlling whether traffic goes to and from on this hop (keeping any potentially costly call open). T3 can be set high (its really a resource protection timeout). Example values might be T3 = 3600 secs, T2 = 120 secs and T1 = 60 secs.