Re: [SAM] Some issues about labelcast protocol

["Thomas C. Schmidt" <[e-mail]>]

Hi Wanghui,

thanks for your reply. Please see inline:

On 17.04.2011 18:10, wanghuinudt wrote:
> Hi Thomas,
> I'm sorry to respond too late. We have been back for a few days, and we 
> discussed some issues which met at IETF80 in Prague.
> The main ideas about Labelcast protocol are:
> 1.Maybe the idea of Labelcast is a little ahead, but IRTF is for 
> long-term research. It is the trend to add some network-aware function 
> in the Internet itself. Meanwhile, there are some cases which have added 
> some service provider interface in the switching equipment, such as 
> Openflow. In Openflow, the forwarding policy is controlled by a center 
> completely.

No problem about strong ideas and out-of-the-box thinking. The issue of
course is about arguments. If you propose to do things (i.e.,
group-oriented forwarding) in a completely different manner, it is
important to identify the shortcomings of the current state of the art
and to present solid arguments, why and how your approach is resolving
these issues. This was my question on changing the transport layer ...

> 2.In RTP/RTCP, aggregated RTCP feedback is used to monitor the IPTV 
> transmission (See the paper "On the Use of RTP for Monitoring and Fault 
> Isolation in IPTV",IEEE Network ). In spired by this, we need more 
> functions in the network inside to diagnose the network states. Now the 
> IP routing is mainly based on the shortest path. The forwarding routing 
> can not be adjusted and controlled by the network provider.

We all know about RTP/RTCP and its capabilities. The question is: what
else do you believe is needed (and why)? And yes, IP multicast routing
works on shortest weighted paths (better: reverse paths). A network
provider can influence by weights (intra-domain) and policies
(inter-domain). What is needed instead? What is the role of transport
for routing in your scenario?

> 3.Transparence to applications are very important, now we are 
> considering adding some gateways, which can translate Labelcast to 
> RTP/UDP and the applications will not be changed for a different 
> transport protocol.

O.K., hiding labelcast behind gateways is an approach to keep
transparency. But how about complexity? Does your network model
easily/statelessly transform RTP/UDP streams to the specifics of Labelcast?

> 4. Why not use the existing protocols? Because Labelcast can provide 
> information for monitoring and controlling. In other mechanisms, such as 
> IP multicast, it is not flexible in the routing. And we want to do some 
> work in the internet architecture itself.

Please let me ask again for the details: what information/flexibility
does Labelcast provide that are not present in RTP/UDP and what are the
objectives?

Overall, it is very important to gain a very clear picture of targets
and mechanisms addressed. Also, clear objectives are needed to verify
the suitability of your proposed solutions ...

Kind regards,

Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °