Subject: RE: [nemo] Next steps in RO

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 4 Nov 2005 14:15:47 +0100

Dear Carlos: 

>> [<PT>] I guess that item 2) is very broad in its description. So it could cover the 2 approaches
>that I detailed. And RO for your user in the bus could be handled in both fashions.
>
>	RO can be handled in both fashions if the communication peers are both
>attached to NEMOs. If one peer is an LFN and the other one is a video
>streaming server in the fixed Internet, then only one of the both
>approaches aforementioned is valid. And if you want not to change or add
>any special support in the LFNs, then, as Chan-Wah said, the MR seems to
>be the natural entity to put special functionality into.
>
[<PT>] I'm not challenging the fact that the MR is a good position for doing this on the LFN side :)
In some case it surely is. Some other times, it might be simpler for security reasons to place that feature in a proxy that is part of a trust domain in the infrastructure.

What I'm considering is the correspondent side. In the example you give, and if RO is desirable, I'd think that the CR is the logical place to terminate a tunnel started at the MR. There might be more ten one LFN in the bus going to the same 'site' behind a same CR, and there's a benefit in doing MR-CR as soon as you get a second connection.

Note that I did not challenge the examples themselves but on the side:

- in the case of a bus, Home might be very close (same city) and RO might be less important than, say, for planes

- If the correspondent is a video streaming server in the fixed Internet, I doubt it will want to support CN, which is an additional burden on its resources, and a source of DOS attacks even if the protocol is as safe as can be. Also, there is a good chance that a load balancer is placed in front of a large server site, and that load balancer could be a *very* good place for a CR function :)

Pascal