From schmidt@informatik.haw-hamburg.de Fri Apr 1 02:42:36 2011 Return-Path: X-Original-To: sam@core3.amsl.com Delivered-To: sam@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4214E3A679C for ; Fri, 1 Apr 2011 02:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSWXD7SsNYk6 for ; Fri, 1 Apr 2011 02:42:35 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3FC003A6781 for ; Fri, 1 Apr 2011 02:42:35 -0700 (PDT) Envelope-to: sam@irtf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q5as4-0009lU-4D; Fri, 01 Apr 2011 11:42:24 +0200 Message-ID: <4D959E6D.7030809@informatik.haw-hamburg.de> Date: Fri, 01 Apr 2011 11:44:13 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: wanghuinudt Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sam@irtf.org Cc: sam Subject: [SAM] Question regarding your presentation X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:42:36 -0000 Dear Wang Hui, yesterday in your presentation you made two statements which I forgot to ask about: 1. You want to avoid a scaling problem of IP Multicast 2. Labelcast as a new transport protocol remains application-transparent So, my questions are ad 1.) Which scaling problem do you refer to? ad 2.) What API allows you to use a different transport protocol without changing the application? Thanks, 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 ° From wanghuinudt@gmail.com Sun Apr 17 09:04:53 2011 Return-Path: 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 ; 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 ; 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 ; Sun, 17 Apr 2011 09:04:52 -0700 (PDT) Received: by pvg11 with SMTP id 11so2381668pvg.13 for ; 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" To: "Thomas C. Schmidt" 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 , labelcast 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 16:04:53 -0000 This is a multi-part message in MIME format. --=====003_Dragon777685602553_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit 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 --=====003_Dragon777685602553_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
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
 --=====003_Dragon777685602553_=====-- From schmidt@informatik.haw-hamburg.de Sun Apr 17 12:29:47 2011 Return-Path: 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 8245BE0784 for ; Sun, 17 Apr 2011 12:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.799 X-Spam-Level: X-Spam-Status: No, score=-99.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] 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 wuUiJ61U9GMC for ; Sun, 17 Apr 2011 12:29:46 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfc.amsl.com (Postfix) with ESMTP id 7FF11E0782 for ; Sun, 17 Apr 2011 12:29:45 -0700 (PDT) Envelope-to: sam@irtf.org Received: from g231109044.adsl.alicedsl.de ([92.231.109.44] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QBXdR-0004tp-Qn; Sun, 17 Apr 2011 21:27:54 +0200 Message-ID: <4DAB3F9E.4010006@informatik.haw-hamburg.de> Date: Sun, 17 Apr 2011 21:29:34 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: wanghuinudt References: <201104180010421090553@gmail.com> In-Reply-To: <201104180010421090553@gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sam@irtf.org Cc: sam , labelcast Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:29:47 -0000 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: +49-40-42875-8452 ¡ã ¡ã http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ¡ã From mko@cs.stir.ac.uk Tue Apr 19 08:21:43 2011 Return-Path: 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 70C46E07A7 for ; Tue, 19 Apr 2011 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6] 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 WSZu2+VU6iju for ; Tue, 19 Apr 2011 08:21:42 -0700 (PDT) Received: from clyde.stir.ac.uk (clyde.stir.ac.uk [139.153.13.35]) by ietfc.amsl.com (Postfix) with ESMTP id 688D3E079A for ; Tue, 19 Apr 2011 08:21:41 -0700 (PDT) Received: from [139.153.13.214] (helo=smtp.stir.ac.uk) by clyde.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QCCk2-0004D0-6M for sam@irtf.org; Tue, 19 Apr 2011 16:21:26 +0100 Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp.stir.ac.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QCCk1-0002G2-V6 for sam@irtf.org; Tue, 19 Apr 2011 16:21:26 +0100 Message-ID: <4DADA873.6030301@cs.stir.ac.uk> Date: Tue, 19 Apr 2011 16:21:23 +0100 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sam Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-stir.ac.uk-MailScanner-ID: 1QCCk2-0004D0-6M X-stir.ac.uk-MailScanner: Found to be clean Subject: [SAM] CFP: IMSAA-2011 - 5th International Conference on, Internet Multimedia System Architectures and Applications 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:21:43 -0000 Call for Papers: IMSAA-2011 5th International Conference on Internet Multimedia System Architectures and Applications Bangalore, India, 12-14 December 2011 www.imsaa.org Mobile broadband, convergence of data and communication networks, and proliferation of smart end-user devices and terminals have sparked many new architectures enabling internet multimedia applications. However, "Any Information, Any Device, Any Location" networked systems still face significant technical challenges including issues related to performance, privacy, security, reliability, scalability, mobility, interoperability, and deployment. IMSAA-11 is endorsed by the IEEE Communications Society Bangalore Chapter and the IEEE Communications Society Technical Committees on Communications and Information Security (CISTC), Network Operation and Management (CNOM), and Multimedia Communications (MMTC). IMSAA-11 is intended to tackle these challenges and will bring together researchers, engineers and practitioners working on the latest issues in internet multimedia systems, architectures and applications. The conference will include a peer reviewed program of technical sessions, workshops, tutorials, and demonstration sessions. We welcome submissions for IMSAA's Technical Program under the following tracks and topics: Track I. Services - Mobile Applications and Application Stores - Crowdsourcing and New Business Models - Social Networking and Communication services - Context and Content Aware Services - Service Lifecycle Management - Service Delivery Platforms, Virtualization, and Cloud Computing - Service Composition and Feature Interaction Handling - P2P Communication and Gaming Services - VoIP Services - Benchmarking Services and Application Track II. Next Generation Communication Systems - M2M Communications and Internet of Things - P2P Communication Architectures - IMS Control and Application Network - Smart Handheld, Settop, and Home Networking Equipment - Traffic Optimization and Performance - IPv6 Migration - Testing, Simulation, and Validation Platforms - Policy Management and Charging Gateways and Systems - Green Systems and Smart Grids Track III. Multimedia Streaming and Communication - Multicast, Broadcast, and IPTV - Media Streaming - Cross-layer Optimization for Multimedia Service Support - Video Quality Assessment - QoS for Voice and Video Track IV. Security - Privacy and Information Sharing - User Data Security and Privacy - End-to-end Security - Security and Privacy in P2P Networks - Authentication, Authorization, and Access Control In addition to the technical tracks, IMSAA-11 will host a range of workshops, tutorials and demos. Please check the conference website for details. Information for authors: All submissions via EDAS. All papers submitted in scope to conference tracks and topics will receive at least 3 reviews. Dates: Paper submission deadline 15 July 2011 Author notification 1 September 2011 Final camera ready 10 November 2011 TPC Chairs Ashish Jain, Telecordia, USA Mario Kolberg, University of Stirling, UK General Chair John Buford, Avaya Labs Research, USA -- The Sunday Times Scottish University of the Year 2009/2010 The University of Stirling is a charity registered in Scotland, number SC 011159. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1321 / Virus Database: 1500/3582 - Release Date: 04/18/11 -- The Sunday Times Scottish University of the Year 2009/2010 The University of Stirling is a charity registered in Scotland, number SC 011159. From taoli.nudt@gmail.com Tue Apr 26 22:13:49 2011 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961D9E06A0 for ; Tue, 26 Apr 2011 22:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.761 X-Spam-Level: ** X-Spam-Status: No, score=2.761 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzo0v+ML6DiH for ; Tue, 26 Apr 2011 22:13:49 -0700 (PDT) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 07188E0659 for ; Tue, 26 Apr 2011 22:13:48 -0700 (PDT) Received: by vxc34 with SMTP id 34so1351682vxc.13 for ; Tue, 26 Apr 2011 22:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=wO7iemKsXYgMOv/KE4hCBR8Z8vZg+eCvSYk6Tm8zVP0=; b=Q+GS9Hjlq027JNKb45tErCSbVUCwEJvgmtMiHCJ2GcrMOwRPst4e+Wf2IQNBhcbBEa z/qywyT853Waa1KhTz28C/cHn+/zHxzrHQbFDBbu5TLWbZZoDPBZ2599jZOE3VF5x+oI dCZ68BLxVtwKY5e7FS/1oTXM+qm4HuWdvcY+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ARbZmrcH5LJkR76CiL56EaIupW7na9G1kjIn5pdG/3xknv5z3k64h85aAIWD0pCeOi AJAQC0o/nRjXriIgZZLiiM3QwD0b/4WBWs0i+RA0cvbqHy8Z2GcSvEWxHk3zq083ZLiS oLg2oJV0Ril2jSHFsE+Naqe9WK8rNmydyF8gk= MIME-Version: 1.0 Received: by 10.52.96.138 with SMTP id ds10mr2581012vdb.11.1303881228157; Tue, 26 Apr 2011 22:13:48 -0700 (PDT) Received: by 10.52.159.42 with HTTP; Tue, 26 Apr 2011 22:13:48 -0700 (PDT) Date: Wed, 27 Apr 2011 13:13:48 +0800 Message-ID: From: =?GB2312?B?wO7oug==?= To: sam@irtf.org Content-Type: multipart/alternative; boundary=20cf307f3a366f01e104a1df818f Subject: [SAM] Greetings! 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 05:13:49 -0000 --20cf307f3a366f01e104a1df818f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am a freshman here. Just say hello to you. Best wishes, Tao Li -- Tao Li Institute of Network and Information Security College of Computer Science and Technology National University of Defense Technology (NUDT) , P. R. China --20cf307f3a366f01e104a1df818f Content-Type: text/html; charset=ISO-8859-1 Hi all,

I am a freshman here. Just say hello to you.

Best wishes,

Tao Li

--
Tao Li
Institute of Network and Information Security
College of Computer Science and Technology
National University of Defense Technology (NUDT) , P. R. China

--20cf307f3a366f01e104a1df818f-- From wajdi.elleuch@USherbrooke.ca Wed Apr 27 02:50:28 2011 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD8AE06A3 for ; Wed, 27 Apr 2011 02:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.751 X-Spam-Level: * X-Spam-Status: No, score=1.751 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzjcmp6pp-2m for ; Wed, 27 Apr 2011 02:50:27 -0700 (PDT) Received: from tunetmail20.outgw.tn (tunetmail20.outgw.tn [196.203.234.148]) by ietfa.amsl.com (Postfix) with ESMTP id 65668E064B for ; Wed, 27 Apr 2011 02:50:27 -0700 (PDT) Received: from tunet.tn (smtp.tunet.tn [41.228.38.23]) by tunetmail20.outgw.tn (Postfix) with ESMTP id 525B95E2A20 for ; Wed, 27 Apr 2011 10:50:25 +0100 (CET) Received: from tunet.tn (localhost [127.0.0.1]) by tunet.tn (Postfix) with ESMTP id B725341AF for ; Wed, 27 Apr 2011 10:49:55 +0200 (CEST) Received: (qmail 22423 invoked from network); 27 Apr 2011 08:49:54 -0000 Received: from unknown (HELO WajdiLaptop) (41.228.233.125) by tunet.tn with ESMTP; 27 Apr 2011 08:49:54 -0000 From: "Wajdi Elleuch" To: =?utf-8?B?J+adjumfrCc=?= References: In-Reply-To: Date: Wed, 27 Apr 2011 10:50:29 +0100 Message-ID: <005e01cc04c0$8b3a2fa0$a1ae8ee0$@elleuch@USherbrooke.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01CC04C8.ECFE97A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwEmfhZ8gflQwyHR3yfYYGx9uUIgAAJn2WA Content-Language: fr Cc: sam@irtf.org Subject: Re: [SAM] Greetings! X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wajdi.elleuch@ieee.org List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 09:50:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01CC04C8.ECFE97A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tao ! =20 Welcome !! =20 Wajdi=20 =20 De : sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] De la part de ?? Envoy=C3=A9 : mercredi 27 avril 2011 06:14 =C3=80 : sam@irtf.org Objet : [SAM] Greetings! =20 Hi all,=20 I am a freshman here. Just say hello to you. Best wishes, Tao Li --=20 Tao Li Institute of Network and Information Security College of Computer Science and Technology=20 National University of Defense Technology (NUDT) , P. R. China ------=_NextPart_000_005F_01CC04C8.ECFE97A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Tao !

 

Welcome !!

 

Wajdi

 

De : = sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] De la part de = ??
Envoy=C3=A9 : mercredi 27 avril 2011 = 06:14
=C3=80 : sam@irtf.org
Objet : [SAM] = Greetings!

 

Hi all,

I am a freshman here. = Just say hello to you.

Best wishes,

Tao Li

--
Tao Li
Institute of Network and Information = Security
College of Computer Science and Technology
National = University of Defense Technology (NUDT) , P. R. = China

------=_NextPart_000_005F_01CC04C8.ECFE97A0-- From sunzhigang.nudt@gmail.com Wed Apr 27 08:53:30 2011 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602D5E06A3 for ; Wed, 27 Apr 2011 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH8xt+pljlUg for ; Wed, 27 Apr 2011 08:53:29 -0700 (PDT) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7623DE06C9 for ; Wed, 27 Apr 2011 08:53:29 -0700 (PDT) Received: by pwj8 with SMTP id 8so962619pwj.13 for ; Wed, 27 Apr 2011 08:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=IfHLnwICl/YM4NYq4WA871pjpZde/6vUXgRo5+CJ77Y=; b=Cmph5ugreOd2uvEfEtFkVUsIhSNlAPpzoQjB2WI7Q/RoS1fws6MjYDZOIH+8eg7hLu mHIH9mmwA2pupP0DxUCzwkas4e84MNMznGjN3n3x5pkSCTOz0wKlImRtky0Qkd0aKmxg nfP0K6mA9gG3MXXBm1u+vLq8WbIibuBKJ7ffE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=M/9mmJJBkg2bB7aQmkrGBnokeS/Z5KP34E5pfQolA1KgGfHnF0wp+mNWltXGBbgJ0u mNHi8+Hv1/PvbWmyr2LRD67aYdhKk7mKQlxMsEqL0Am2u94sKUBNxhUxzut8sKehJMCL FsfjUanppTkD5TJwMduclOR5UEpQ4+SOwLXCI= MIME-Version: 1.0 Received: by 10.143.25.35 with SMTP id c35mr627994wfj.100.1303919608988; Wed, 27 Apr 2011 08:53:28 -0700 (PDT) Received: by 10.142.179.10 with HTTP; Wed, 27 Apr 2011 08:53:28 -0700 (PDT) Date: Wed, 27 Apr 2011 23:53:28 +0800 Message-ID: From: zhigang sun To: sam@irtf.org Content-Type: multipart/alternative; boundary=001636e1f7171c05c504a1e87177 Subject: [SAM] about labelcast 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:16:29 -0000 --001636e1f7171c05c504a1e87177 Content-Type: text/plain; charset=ISO-8859-1 Hello all, I think labelcast can solve two problems that RTP/UDP and IP multicast can not. First, In network measurement Network tomography using RTCP feedback is very useful to deduce the fault or congested switch node in the network. But its deduce result can not be verified using the in network measurement which is very important for network operator. Recent research shows that with more and more power on routers, in network measure will be a trend. But how to identify streaming packets or a single IPTV flow in the network? when steaming data is carried by RTP/UDP, it is not easy to be classified, unless 5-tuple matching is used. Labelcast, works as a transport layer protocol, can be easily identified by switch node with its protocol ID in IP header and a flow can be identified by short label. UDP can not provide useful information, such as sequence number and time stamp for in network measurement and fault detection. RTP also has rich information for quality management, but it is not design for in network measurement. Second, Path control Labelcast use label to control data distribution path. Unlike IP multicast, labelcast leave a policy interface to network operator to control the path just like openflow. Based on measurement result or other policies(such security, traffic engineering etc.), operator can adjust data distribution path at flow level. I think label-based forwarding can be the supplement of IP multicast in IPTV networks. I agree with Dr. wanghui that gateway is a good way making labelcast transparent to applications. The only thing gateway should do is replace udp header with labelcast header at the source and replace udp header back at destination side. Getway can be implemented at host or first/last hop switch node. We investigated our local IPTV operator recently and we found that they almost has no ways to monitoring and control their IPTV flows under current technologies because network operator can not provide a interface to them. A paper (about Junos SDK at presto'09) from juniper provide an novel method for IPTV qoe monitoring. So to support in network measure, labelcast is one of the solutions and we are doing this in our lab on routers. Best Regards Sun zhigang // sorry if you have received multi-copy of this message. --001636e1f7171c05c504a1e87177 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello all,

=A0

I think labelcast can solve two problem= s that RTP/UDP and IP multicast can not.

=A0

First, In network measurement

=A0

Network tomography using RTCP feedback = is very useful to deduce the fault or congested switch node in the network.= But its deduce result can not be verified using the in network measurement= which is very important for network operator. Recent research shows that w= ith more and more power on routers, in network measure will be a trend. But= how to identify streaming packets or a single IPTV flow in the network? wh= en steaming data is carried by RTP/UDP, it is not easy to be classified, un= less 5-tuple matching is used. Labelcast, works as a transport layer protoc= ol, can be easily identified by switch node with its protocol ID in IP head= er and a flow can be identified by short label.

UDP can not provide useful information,= such as sequence number and time stamp for in network measurement and faul= t detection. RTP also has rich information for quality management, but it i= s not design for in network measurement.

=A0

Second, Path control

=A0

Labelcast use label to control data dis= tribution path. Unlike IP multicast, labelcast leave a policy interface to = network operator to control the path just like openflow. Based on measureme= nt result or other policies(such security, traffic engineering etc.), opera= tor can adjust data distribution path at flow level. I think label-based fo= rwarding can be the supplement of IP multicast in IPTV networks.

=A0

I agree with Dr. wanghui that gateway i= s a good way making labelcast transparent to applications. The only thing g= ateway should do is replace udp header with labelcast header at the source = and replace udp header back at destination side. Getway can be implemented = at host or first/last hop switch node.

=A0

We investigated our local IPTV operator= recently and we found that they almost has no ways to monitoring and contr= ol their IPTV flows under current technologies because network operator can= not provide a interface to them. A paper (about Junos SDK at presto'09= )=A0 from juniper provide an novel method for IPTV qoe monitoring. So to su= pport in network measure, labelcast is one of the solutions and we are doin= g this in our lab on routers.

=A0

Best Regards

=A0

Sun zhigang

=A0

// sorry if you have received multi-cop= y of this message.

<= font face=3D"Calibri" size=3D"3">=A0

--001636e1f7171c05c504a1e87177-- From sunzhigang.nudt@gmail.com Wed Apr 27 09:19:18 2011 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5353EE0795 for ; Wed, 27 Apr 2011 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCCg57oydJii for ; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by ietfa.amsl.com (Postfix) with ESMTP id A804AE07D3 for ; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) Received: by pvg11 with SMTP id 11so1685079pvg.13 for ; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=aiSvxcd7pTBdRs+s1dVNtnpQvJJ29/a8nPXfetMj1vo=; b=qahTVD8rmnMRaeauoQg4117uBUHnWdjCoJHp5Ncs299xoGcxowavUdrmSsoUddL2Ra yXjJTmuUsnlCuSgwe4DhCJogXWsu6O6mCU6FTAoISEXnR4tYggifIEQW86WfnN9z2bYU G6BYSURlEbSvrDGS9YyLinNUyOeRwvimGtgFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MCPIzk1CKn2P5g91A6xUd7NKebRiHJ7B5MtDpQAtEJ8WV5lPzgiycz5g1AIQh46FCn nf9ZG2b4gGTOpZVCU/AP1+0DQFdGhasG3EaiwvA/XrAVSb4NtRC7jcGVSgl8U3AcKLXo N9Bj6eO+989CxLwY8pAaMJ19Zacj4yGDDsb8k= MIME-Version: 1.0 Received: by 10.143.25.35 with SMTP id c35mr639127wfj.100.1303921157220; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) Received: by 10.142.179.10 with HTTP; Wed, 27 Apr 2011 09:19:17 -0700 (PDT) Date: Thu, 28 Apr 2011 00:19:17 +0800 Message-ID: From: zhigang sun To: sam@irtf.org Content-Type: multipart/alternative; boundary=001636e1f71764290e04a1e8cd6d Subject: [SAM] hello 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:19:18 -0000 --001636e1f71764290e04a1e8cd6d Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, Did you find that something can not be display properly in new webpage of SAMRG (http://www.irtf.org/samrg)? Sun zhigang --001636e1f71764290e04a1e8cd6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello everyone,
=A0
Did you find that something can not be display pr= operly in=A0 new webpage of SAMRG (ht= tp://www.irtf.org/samrg)?
=A0
Sun zhigang --001636e1f71764290e04a1e8cd6d--