Subject: [SAM] Some issues about labelcast protocol

From: "wanghuinudt" <[email-masked]>
Date: Mon, 18 Apr 2011 00:10:52 +0800

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.

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. 

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.

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.

Long for your advices. And more feedback is needed by SAMRG members!
Best regards.

                                                                                 Wanghui

2011-04-17 

 WangHui
 Ph.D. Student
 Lab 609
 School of Computer
 National University of Defense Technology
 ChangSha, HuNan, China 410073
 Email:  [email-masked]   or
           [email-masked]   or
           [email-masked] 
 Tel:13467578342

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 17 Apr 2011 21:29:34 +0200

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.
> 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: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °