[SAM] Some issues about labelcast protocol
"wanghuinudt" <wanghuinudt@gmail.com> Sun, 17 April 2011 16:04 UTC
Return-Path: <wanghuinudt@gmail.com>
X-Original-To: sam@ietfc.amsl.com
Delivered-To: sam@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4B62E06DE for <sam@ietfc.amsl.com>; Sun, 17 Apr 2011 09:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqgxvh-jYBdI for <sam@ietfc.amsl.com>; Sun, 17 Apr 2011 09:04:52 -0700 (PDT)
Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by ietfc.amsl.com (Postfix) with ESMTP id ADCD3E06B5 for <sam@irtf.org>; Sun, 17 Apr 2011 09:04:52 -0700 (PDT)
Received: by pvg11 with SMTP id 11so2381668pvg.13 for <sam@irtf.org>; Sun, 17 Apr 2011 09:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:x-mailer :mime-version:content-type; bh=fASxt4Z11vnw1xhRdFFcAfEQrldzwTNwlgrD91d583w=; b=puCq3prKF5EloF4nEGCiuktJCqw8+Wfw/V8w5adSXGDsNOliOet0XmGH7vrx/1c/rE DnOVN3lAiCorPe7Sn9ozVgrKdyNEa+PTsTNxUfEqTxinJUm8pmMSSfXwi1I4Z+ERmWKa J7Sw4cv1en6ST1qAU8JFhBFOfnCrznFf8lOqE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=qo9Rw94yJ4UR1mn7NpWdhM0xmR+ZUNvcxi9vTPfbLaj9pUUBos1Wx6aHrVUvMgeCfZ 3pJHEPkdCzzUqsBWDbe8JA3s2yPY2u/8ItooIZdGnMjHAoNiWbnM9833gL1CoYgSbTuC LCt+d0HmL68v+PzJ6i7FFJ5+eMgDdbiM10O/w=
Received: by 10.68.42.199 with SMTP id q7mr5458296pbl.64.1303056292131; Sun, 17 Apr 2011 09:04:52 -0700 (PDT)
Received: from WWW-A9465D99689 ([113.220.116.160]) by mx.google.com with ESMTPS id a4sm1729103pbf.56.2011.04.17.09.04.46 (version=SSLv3 cipher=OTHER); Sun, 17 Apr 2011 09:04:51 -0700 (PDT)
Date: Mon, 18 Apr 2011 00:10:52 +0800
From: wanghuinudt <wanghuinudt@gmail.com>
To: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
Message-ID: <201104180010421090553@gmail.com>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon777685602553_====="
Cc: sam <sam@irtf.org>, labelcast <labelcast@googlegroups.com>
Subject: [SAM] Some issues about labelcast protocol
X-BeenThere: sam@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <sam.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/sam>, <mailto:sam-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/sam>
List-Post: <mailto:sam@irtf.org>
List-Help: <mailto:sam-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/sam>, <mailto:sam-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2011 16:04:53 -0000
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: wanghuinudt@gmail.com or
wang.hui@nudt.edu.cn or
wanghuinudt@yahoo.com.cn
Tel:13467578342
- [SAM] Some issues about labelcast protocol wanghuinudt
- Re: [SAM] Some issues about labelcast protocol Thomas C. Schmidt