Subject: RE: [Rmt] Reliable Multicast techniques

From: <[email-masked]>
Date: Tue, 13 Jun 2006 16:15:58 +0300

Hi Renata and everyone

One issue with server replication and the LCT family (inc. ALC and
FLUTE) is that session identification explicitly includes the sender IP
address. Such that for a single transport session there is only one IP
source.

Of course you can bind multiple LCT sessions into some other higher
level session (e.g. a multiple "transport session" single "announcement
carousel session" is along the lines of what was proposed for the FLUTE
based SAP replacement (MUPPET) a long time ago in a working group far
far away (MMUSIC:) ).

However, this means that there's no clear standards way (at this point)
to do this for allowing multiple IP sources to redundantly serve the
same LCT session.

You could of course use the same IP source in packet headers from the
replicated servers but there "might" be some local network admin issues
to deal with, and your servers may simply not like that idea when they
have perfectly good IP address in the first place. A address translating
box is an option but I won't sully this mail list with such a topic
(i.e. I don't have the IETF credo to survive proposing a NAT scheme :)

On your exact question: today I guess server replication for LCT-based
RMT is not widely used as the deployment of commercial services is small
(e.g. compared to email, browsing, etc.). However, the simple failover
server with the same configuration (and IP address) and some integrated
or separate unit functionality to handle the switch over is the natural
hack to handle this (and is likely to accompany any non-trial paid-for
service). Distributing these between sites need not be overly complex
(IP addressing and routing on different subnets along with firewall
admin are solvable admin issues) - though I guess the only benefit would
be avoiding geographically local power outages). It's also worth
considering the application impact for switch-over (are packet streams
continued from the same point; packets lost or repeated?).

I admit my embarrassment that I don't know NORM semantics in this
matter, so someone else will have to volunteer commentary on server
replication issues for NORM.

Cheers, Rod.

PS Occasional student questions into IETF work groups are the excepted
norm, though it's normal to move the discussion then into private emails
(my excuse for CC'ing everyone is the very real limitation above is an
issue for any LCT use - I think it was in the Paris IETF when I last
mentioned this, some things are worth repeating :)

>-----Original Message-----
>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 12 May, 2006 12:00
>To: [email-masked]
>Subject: [Rmt] Reliable Multicast techniques
>
>Hi all,
>
>I am a brazilian M.Sc. student and I am doing research on 
>Reliable Multicast.
>I would like to study the techniques currently employed to 
>provide Multicast transmission over the Internet. More 
>specifically, I would like to know if Server Replication is 
>widely deployed and recognized as a successful technique.
>
>Any pointers will be strongly appretiated.
>
>Sorry if this mailing list is not the proper place to ask for help.
>
>Renata Milagres
>---------------
>M.Sc. candidate
>Computing Institute - Fluminense Federal University (UFF) Rio 
>de Janeiro, Brazil
>
>
>_______________________________________________
>Rmt mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rmt
>

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt