From rem-conf Mon Apr 02 02:46:26 2001 From rem-conf-request@es.net Mon Apr 02 02:46:25 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14k0kX-0005Sh-00; Mon, 2 Apr 2001 02:35:49 -0700 Received: from smtp1.cluster.oleane.net [195.25.12.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 14k0kV-0005SW-00; Mon, 2 Apr 2001 02:35:48 -0700 Received: from oleane (dyn-1-1-045.Vin.dialup.oleane.fr [195.25.4.45]) by smtp1.cluster.oleane.net with SMTP id f329ZiO13409 for ; Mon, 2 Apr 2001 11:35:44 +0200 (CEST) Message-ID: <002601c0bb58$76d72020$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPEG-4 Congress Date: Mon, 2 Apr 2001 11:36:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C0BB69.39EA7200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C0BB69.39EA7200 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Will MPEG-4 become the broadband content delivery standard ?=20 The MPEG-4 Congress will take place in Paris, France, from October 23 to = 26, 2001.=20 A call for papers is online: http://www.upperside.fr/mpeg42001/mpeg42001intro.htm ------=_NextPart_000_0023_01C0BB69.39EA7200 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Will MPEG-4 become the broadband = content=20 delivery standard ?
The MPEG-4 = Congress=20 will take place in Paris, France, from October = 23 to 26,=20 2001.
A call for papers is = online:
http://www.= upperside.fr/mpeg42001/mpeg42001intro.htm
 
------=_NextPart_000_0023_01C0BB69.39EA7200-- From rem-conf Mon Apr 02 04:13:12 2001 From rem-conf-request@es.net Mon Apr 02 04:13:11 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14k2DD-0000cI-00; Mon, 2 Apr 2001 04:09:31 -0700 Received: from (serrano.macrotec.cl) [200.28.19.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 14k2D9-0000bs-00; Mon, 2 Apr 2001 04:09:28 -0700 Received: from billyhoe ([64.1.2.30]) by serrano.macrotec.cl (Netscape Messaging Server 3.01) with SMTP id 312; Mon, 2 Apr 2001 02:02:28 -0400 From: debt-termination@kidzmail.com.au To: Subject: Eliminate Debt Without Bankruptcy!!!!! Date: Sun, 01 Apr 2001 21:47:15 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0F5D_00006B1C.00002BD9" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------=_NextPart_000_0F5D_00006B1C.00002BD9 Content-Type: text/html; Home Page

Eliminate All Your Major Credit Card Debt, Medical Bills, And Unsecured Loans Without Bankruptcy!!!!!!

* Are you tired of living paycheck to paycheck because of outrageous credit card payments?

*Are you tired of barely getting by every month because you fell victim to the CREDIT CARD TRAP?

*Are you sick and tired of always wondering if you are going to be able to pay all your bills next month?

*Do you have outrageous medical bills or unsecured loans that sucking you down?

*Are you afraid to file bankruptcy because of

           1.   the humiliation of having your name published in the paper                                   

           2.   the hassle of going to court

           3.   what it will do to your credit record

 

YOU DO Have An Alternative And We CAN Help!!!!!

Our experts have been helping people eliminate their debt in this manner for over seven                                      years and have been 100% successful.

With our program you can eliminate your debt hassle free and in total privacy                                                            (no going to court or getting your name published in the paper).                                                                                   The only people who will know about it are you and your creditors.

 

OUR GUARANTEE!!!

If we cannot eliminate your debt we will pay it ourselves!!!!!

You have nothing to lose so Call Now

There is A One Time Service Fee Of $2,000.00 For Our Services. All Forms Of Payment Accepted

800-320-9895  ext. 6247     (24 hour recorded message)

 

 

 

 

 

 

 

 

 

 

To be removed from future mailing send a blank email with remove in the subject line to mail-away@kidzmail.com.au

From rem-conf Mon Apr 02 07:49:26 2001 From rem-conf-request@es.net Mon Apr 02 07:49:25 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14k5ag-0007V2-00; Mon, 2 Apr 2001 07:45:59 -0700 Received: from smtp2.cluster.oleane.net [195.25.12.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 14k5ae-0007TZ-00; Mon, 2 Apr 2001 07:45:56 -0700 Received: from oleane (dyn-1-1-067.Vin.dialup.oleane.fr [195.25.4.67]) by smtp2.cluster.oleane.net with SMTP id f32EjlT95419 for ; Mon, 2 Apr 2001 16:45:48 +0200 (CEST) Message-ID: <014401c0bb83$c4c30940$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: Erratum MPEG 4 Congress Date: Mon, 2 Apr 2001 16:46:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01C0BB94.87DDFC40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0141_01C0BB94.87DDFC40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Erratum MPEG 4 Congress Due to a recent change in the dates of the Washington meeting next = October, the dates of the MPEG 4 Congress (Paris) have been moved to: = November 6-9. A call for proposals is online at: http://www.upperside.fr/mpeg42001/mpeg42001intro.htm ------=_NextPart_000_0141_01C0BB94.87DDFC40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Erratum MPEG 4 Congress
 
Due to a recent change in the dates of the = Washington meeting=20 next October, the dates of the MPEG 4 Congress (Paris) have been moved = to:=20 November 6-9.
A call for proposals is online at:
http://www.= upperside.fr/mpeg42001/mpeg42001intro.htm
 

 
 
------=_NextPart_000_0141_01C0BB94.87DDFC40-- From rem-conf Mon Apr 02 08:09:31 2001 From rem-conf-request@es.net Mon Apr 02 08:09:30 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14k5vz-000186-00; Mon, 2 Apr 2001 08:07:59 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 14k5vx-00017w-00; Mon, 2 Apr 2001 08:07:57 -0700 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id IAA06136 for ; Mon, 2 Apr 2001 08:07:57 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 2 Apr 2001 08:07:51 -0700 Received: from [17.219.158.123] (singeridsl2.apple.com [17.219.158.123]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id IAA16926; Mon, 2 Apr 2001 08:07:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <5.0.0.25.0.20010331120339.079a0650@goobox.prognet.com> References: <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com> <5.0.2.1.0.20010329171207.01e70020@goobox.prognet.com> <5.0.0.25.0.20010331120339.079a0650@goobox.prognet.com> Date: Mon, 2 Apr 2001 08:03:30 -0700 To: Rob Lanphier From: Dave Singer Subject: RE: MP4 Player Available for Download Cc: olivier.avaro@francetelecom.com, "'Hari Kalva'" , rem-conf@es.net, discuss@apps.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >At 10:00 AM 3/14/01 -0800, Dave Singer wrote: >>I hate to carry on an off-topic thread, but the MPEG-4 file format >>is not heavily encumbered. To my knowledge, we (Apple) are the >>only IPR owners in the file format per se, and the license needed >>would be the same as for the QT file format (i.e. it's the same >>IPR), for which we have plenty of examples of licensees (including >>Real Networks). > >Are you really willing to stand up and disclose the terms of the >Apple/RealNetworks agreement? I think it's entirely inappropriate >to cite the Apple/RealNetworks agreement as an example of an MPEG-4 >file format licensing success story, and entirely inappropriate to >discuss the terms of any deal that go beyond the joint press release: > >http://www.realnetworks.com/company/pressroom/pr/2000/apple.html > >Besides that, I don't think it's at all reasonable that if >RealNetworks and some other company/project want to interoperate, >that that other company/project should have to go to Apple to get >permission. Do you? > >Rob Of course not. I was merely dealing with a common complaint about licensable technology -- that people seem to be unable to obtain licenses. I wanted to point out that this was not the case here. As you note, I am merely pointing out a fact of public knowledge: that Apple and Real have agreed on terms for Real to use the QT Streaming format. This is also true of a number of other companies who also support the QT Streaming format. -- David Singer Apple Computer/QuickTime From rem-conf Mon Apr 02 11:59:05 2001 From rem-conf-request@es.net Mon Apr 02 11:59:04 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14k9Q5-0001OI-00; Mon, 2 Apr 2001 11:51:17 -0700 Received: from (eddie.timeandpeople.com.au) [203.24.241.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 14k9Q0-0001IU-00; Mon, 2 Apr 2001 11:51:13 -0700 Received: from SMTP1 by eddie.timeandpeople.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 2DRA1T67; Tue, 3 Apr 2001 04:20:32 +0930 Received: from [224.219.249.140] by _[86.186.236.220]_by with SMTP id A110C24E7 Mon, 2 Apr 2001 11:52:51 PDT From: Subject: RE: How serious are you... Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Date: Mon, 2 Apr 2001 12:10:08 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
You are receiving this e-mail because you opted-in by requesting information or requested to receive
special offers from an online purchase, in the last 6 months. To unsubscribe, please click HERE


We craft distinctive corporate identity with
unique images, animation and sound
  


New
 Look

Our mission is to project your company in the best possible image, to the greatest number of your potential clients. Our goal is to create and implement the most sophisticated and successful ad campaign possible for your company.  



We deliver the most dynamic e!mail
marketing campaign in the world
  


More
 Clients
Our professional techniques of marketing and the quality of our ad copy, generates more quality potential customers per marketing dollar than any other form of marketing. With custom graphics, images and bullet descriptions, your potential client will not miss your message.  



Direct e!mail marketing generates more
 qualified leads which generate greater sales
  



More
 Money

Conventional methods of marketing (i.e. snail mail) are 100 times more expensive, with only one tenth of the response. It is undisputable, that warm qualified leads generate greater sales. Without professional marketing, your product/service will never reach its potential growth or sales.

If you're serious about your business then this is for you!

Fill out the following form and one
of our consultants will contact you.

Your Name:
Your Web Address:
Company Name:
State:
Business Phone:
Home Phone:
Email:
Type of Business:

 

  
From rem-conf Mon Apr 02 14:55:38 2001 From rem-conf-request@es.net Mon Apr 02 14:55:37 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kCDL-00015j-00; Mon, 2 Apr 2001 14:50:19 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kCDF-000146-00; Mon, 2 Apr 2001 14:50:13 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 2C80D1E051 for ; Mon, 2 Apr 2001 17:50:09 -0400 (EDT) Received: from vtpc3 ([135.207.132.105]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA22438 for ; Mon, 2 Apr 2001 17:49:44 -0400 (EDT) Message-ID: <020601c0bbbf$1b6b2c10$6984cf87@vtpc3> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: Subject: Fw: PV2001 Call for Participation & Advance Program Date: Mon, 2 Apr 2001 17:51:43 -0400 Organization: AT&T Labs - Research MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0202_01C0BB9D.94277F90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0202_01C0BB9D.94277F90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0203_01C0BB9D.94277F90" ------=_NextPart_001_0203_01C0BB9D.94277F90 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable CALL FOR PARTICIPATION Please mark your calendar to attend the PV-2001 for a rewarding experience=20 in the field of "Advanced Packet Video=94 The 11th International Packet Video Workshop (PV-2001) will be held on = 30 April - 1 May 2001 in Kyongju, Korea (located in 350-kilometer = southeast of Seoul), which was the capital city of ancient Korea (A.D = 676-A.D 935). The workshop is devoted to presenting technological = advancements and innovations in video transmission over packet networks, = in particular, the Internet. Packet Video Workshops have been unique in = providing a common ground for people from video coding and networking = fields. Presentations on theory and practice, standards activities, and = business and consumer applications are encouraged. In 2001, the workshop = is scheduled to take place in the week following Picture Coding = Symposium (PCS-2001) which will be held in Seoul on 25-27 April 2001. We = cordially invite you to take part in this workshop. Further details and = updated information for PV-2001 can be found at = http://pv2001.kaist.ac.kr. With broad and active participations from all over the world, we are = convinced that the PV-2001 will be very successful.=20 Program Overview: The session program will have 8 sessions with 56 papers from 16 = countries. This will be further highlighted by two invited talks and one = panel discussion. The 23 papers will be presented by oral presentation = and the other papers will be presented by poster presentation. Topic Areas: =20 - Video streaming over Internet =20 - Network adaptive video coding and transport =20 - Error/loss resilient video coding and transport =20 - Layered coding for error resilience and heterogeneous networks =20 - Rate control for VBR video =20 - Statistical multiplexing for greater network and terminal = utilization =20 - Congestion control and bandwidth allocation =20 - Efficient transcoding for heterogeneous networks =20 - Error concealment and post processing =20 - Traffic shaping for efficient network and terminal utilization =20 - Performance modeling and evaluation for packet video network =20 - Interstream synchronization for multiple video presentations =20 - Packetized video for wireless/mobile systems =20 - Packetized video for home LAN's =20 - Multicasting, MBONE applications =20 - International standards: MPEG-4, MPEG-7, H.26L, H.323, RTP, = RTSP, SIP, SDP =20 - Terminal and server architecture for Internet TV =20 - Implementations and commercial applications =20 Invited Speakers: - Dr. Ya-Qin Zhang, Microsoft Research in Beijing, China "Convergence of Multimedia, Wireless and Internet=94 =20 - Dr. Civanlar M. Reha, AT&T Labs Research, U.S.A. "Internet Video - Protocols & Applications=94 =20 Registration Information: Category By March 31, 2001 After March 31, 2001 =20 Regular Registration Plan 1 US$300 US$350 =20 Plan 2 US$225 US$275 =20 Banquet for Accompanying Person US$60/each =20 Additional CD-ROM Proceedings US$50/each =20 Special Bus Transportation (from Seoul to Kyongju) US$80/each =20 PV and PCS-2001 Registration By March 31, 2001 After March 31, 2001 =20 Regular Registration Plan 3: PCS Regular+PV Plan 1 US$650 US$750 =20 Student Registration Plan 4: PCS Plan A+PV Plan 2 US$450 US$550 =20 Plan 5: PCS Plan B+PV Plan 2 US$390 US$490 =20 Important Date: March 31, 2001 Advance Registration & Hotel = Reservation PCS-2001 Secretariat:=20 Further inquiries can be made at: Tel: +82-42-472-7460 Fax: +82-42-472-7459 Email: = pv@pv2001.kaist.ac.kr ------=_NextPart_001_0203_01C0BB9D.94277F90 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 
CALL FOR PARTICIPATION
 Please mark your calendar to attend the = PV-2001
for a=20 rewarding experience
in the field of "Advanced Packet=20 Video=94

The=20 11th International Packet Video Workshop (PV-2001) will be = held on 30=20 April - 1 May 2001 in Kyongju, Korea (located in 350-kilometer southeast = of=20 Seoul), which was the capital city of ancient Korea (A.D 676-A.D 935). = The=20 workshop is devoted to presenting technological advancements and = innovations in=20 video transmission over packet networks, in particular, the Internet. = Packet=20 Video Workshops have been unique in providing a common ground for people = from=20 video coding and networking fields. Presentations on theory and = practice,=20 standards activities, and business and consumer applications are = encouraged. In=20 2001, the workshop is scheduled to take place in the week following = Picture=20 Coding Symposium (PCS-2001) which will be held in Seoul on 25-27 April = 2001. We=20 cordially invite you to take part in this workshop. Further details and = updated=20 information for PV-2001 can be found at http://pv2001.kaist.ac.kr.=

With broad and active participations from all over the = world, we are=20 convinced that the PV-2001 will be very successful.=20

Program Overview:

The session program will have 8 sessions with 56 papers = >from 16=20 countries. This will be further highlighted by two invited talks and one = panel=20 discussion. The 23 papers will be presented by oral presentation and the = other=20 papers will be presented by poster presentation.

Topic Areas:=20  

- Video streaming over Internet =
- Network adaptive video coding and = transport=20
- Error/loss resilient video coding and = transport=20
- Layered coding for error resilience and = heterogeneous=20 networks
- Rate control for VBR video
- Statistical multiplexing for greater network and = terminal=20 utilization
- Congestion control and bandwidth = allocation=20
- Efficient transcoding for heterogeneous=20 networks
- Error concealment and post processing =
- Traffic shaping for efficient network and terminal=20 utilization
- Performance modeling and evaluation for packet = video=20 network
- Interstream synchronization for multiple video=20 presentations
- Packetized video for wireless/mobile = systems=20
- Packetized video for home LAN's =
- Multicasting, MBONE applications =
- International standards: MPEG-4, MPEG-7, H.26L, = H.323, RTP,=20 RTSP, SIP, SDP
- Terminal and server architecture for Internet=20 TV
- Implementations and commercial applications=20

Invited Speakers:

- Dr. = Ya-Qin=20 Zhang, Microsoft Research in Beijing, China
  "Convergence of Multimedia, Wireless and=20 Internet=94

- Dr. = Civanlar M.=20 Reha, AT&T Labs Research, U.S.A.
  "Internet=20 Video - Protocols &=20 Applications=94

Registration Information:

Category

By=20 March 31, 2001

After=20 March 31, 2001

Regular Registration

Plan 1

US$300

US$350

Plan 2

US$225

US$275

Banquet for Accompanying = Person

US$60/each

Additional CD-ROM Proceedings

US$50/each

Special Bus Transportation (from Seoul to=20 Kyongju)

US$80/each

PV and PCS-2001 Registration

By=20 March 31, 2001

After=20 March 31, 2001

Regular Registration

Plan 3: PCS Regular+PV Plan 1

US$650

US$750

Student Registration

Plan 4: PCS Plan A+PV Plan 2

US$450

US$550

Plan 5: PCS Plan B+PV Plan 2

US$390

US$490

Important Date:=20      = March 31, 2001        Advance Registration & Hotel=20 Reservation

PCS-2001 Secretariat: 
Further inquiries = can be=20 made at:
Tel: +82-42-472-7460           =20 Fax: +82-42-472-7459             =20 Email:=20 pv@pv2001.kaist.ac.kr

------=_NextPart_001_0203_01C0BB9D.94277F90-- ------=_NextPart_000_0202_01C0BB9D.94277F90 Content-Type: text/html; name="advance_program.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="advance_program.htm" Paper Review
=

Advance Program

=A2=BAMONDAY, APRIL 30, 2001

INVITED TALK (1) = (08:40~09:40)

Room: Grand = Ballroom (A)

Convergence of Multimedia, Wireless and = Internet

Ya-Qin Zhang (Microsoft Research in = Beijing, China)

SESSION MP1: Streaming, Network = Adaptation and Performance (10:20~11:20)

Room: = Pine

Chair: = T.B.D.

1

An Empirical Analysis of Video Streaming over an Internet Routing = Environment

 

S.R.Sudharsanan, V.Ganapathy, and V.Ramachandran (Multimedia Univ., Cyberjaya, = Malaysia)

2

Adaptive Multimedia Streaming over IP

 

Matthew Walker, Richard Jacobs, and Mike Nilsson (Ipswich, U.K.)

3

Hierarchical Modeling of Variable Bit Rate Video Sources

 

Deepak S. Turaga and Tsuhan Chen (Carnegie Mellon Univ., U.S.A.)

4

Admission Control Algorithm Based = on Metadata of Quantization Parameter and Output-Bit-Rate Profile for = Guaranteeing

 

Hwangjun Song (Hongik Univ., Korea) and Hae-Kwang Kim (Sejong Univ., = Korea)

5

A New Rate Control Algorithm for = Real Time Video Communication Using Spatial Prediction = Error

 

Jun Geun Jeon and Myoung Ho Lee (ETRI, Korea)

6

Study of Packet Dropping Policies on Layered Video

 

Frederic Raspall (Univ. of Politecnica de Cataluuya, Spain), Christoph Kuhmuench (Univ. of = Mannheim, Germany), Albert Banchs, Federico Pelizza (NEC Europe Ltd., Germany), = and Sebastia Sallent (Univ. of Politecnica de Cataluuya, = Spain)

7

Cooperative Caching Framework of VOD Using P2P Technology

 

Jungohn Yim (LG Electronics Inc., Korea), Gil Yong Kim (Pusan Nat=A1=AFl Univ., Korea), and = Young-Sung Son (ETRI, Korea)

8

A Study on the Scalable Coding Algorithm by Separating and Composing of MPEG-2 = Bitstreams

 

Isao Nagayoshi, Tsuyoshi Hanamura, Hiroyuki Kasai, and Hideyoshi Tominaga (Waseda Univ., = Japan)

9

A Media Gateway for Flexible MPEG-2 Video Delivery over IP Network and its = Applications

 

Yuzo Senda (NEC = Corp., Japan)

10

Video Compression Based on Selectively Refining Regions in Difference = Frame

 

Jay Yun and Toby Berger (Cornell Univ., U.S.A.)

11

Markovian Arrival Process (MAP) Modeling for Superposed Packet = Streams

 

Sang H. Kang, Yong Han Kim (Univ. of Seoul, Korea), and Dan K. Sung (KAIST, = Korea)

SESSION MO1: Video Streaming = Over Internet

Room: Grand = Ballroom (A)

Chair: T.B.D.

11:20~11:40

Packet Classification Schemes for Streaming MPEG Video over Delay and Loss Differentiated Networks

 

Wai-tian Tan and Avideh Zakhor (Univ. of California, U.S.A.)

11:40~12:00

Hierarchical Video Multicast And Packet Filtering

 

David Pate and Jean-Jacques Pansiot = (LSIIT, France)

12:00~12:20

Aggregated QoS Mapping Framework for Relative Service Differentiation-Aware Video = Streaming

 

Jitae Shin, Jin-Gyeong Kim, JongWon = Kim, D. C. Lee, and C.-C. Jay Kuo (Univ. of Southern California, = U.S.A.

12:20~12:40

Media Oriented Video Streaming Flow Control in Linux Cluster = Server

 

Jungohn Yim (LG Electronics Inc., Korea), Gil Yong Kim (Pusan Nat=A1=AFl Univ., Korea), and = Young-Sung Son (ETRI, Korea)

12:40~13:00 

Simple Packet Loss Recovery Method for Video Streaming

 

   Miska M. = Hannuksela (Nokia Mobile Phones, Finland)

SESSION MO2: Streaming Congestion = Control

Room: Grand = Ballroom (A)

Chair: T.B.D.

14:00~14:20

= On the Interactions between Layered Quality Adaptation and Congestion Control = for Streaming Video

 

Nick Feamster, Deepak Bansal, = and Hari Balakrishnan (MIT, U.S.A.)

14:20~14:40

= Robust Scalable Video Streaming over Internet with Network-Adaptive Congestion = Control and Unequal Loss Protection

   Qian Zhang, Guijin Wang , Wenwu Zhu, and Ya-Qin Zhang (Microsoft Research, China)

14:40~15:00 

Long Window Rate Control for Video Streaming

 

Viktor Varsa and Marta Karczewicz = (Nokia Research Center, U.S.A.)

15:00~15:20

Adaptive Streaming of Stored Video in a TCP-Friendly Context : Multiple Versions = or Multiple Layers ?

 

Philippe de Cuetos, Despina Saparilla, and Keith W. Ross (Inst. Eurecom, France)

SESSION MP2: Multicasting, = Standards and Implementation (16:00~17:00)

Room: = Pine

Chair: T.B.D.

1

Sender-Initiated Configuration of an ACK-Tree for Reliable Multicast = Transport

 

Eunsook Kim (Sookmyung Women's Univ., Korea), Seokjoo Koh, Juyoung Park, Singak Kang (ETRI, = Korea), and Jongwon Choe (Sookmyung Women's Univ., Korea)

2

A Constrained Routing Algorithm for Dynamic = Multicasting

 

Hong-Soon Nam (ETRI, Korea), Dae-Young Kim (Chungnam Nat'l Univ., Korea), and Kyu-Ook Lee (ETRI, = Korea)

3

A Proposal of Video Contents E-Commerce System Using Scalability = Architecture

 

Mei Kodama (Hiroshima Univ., Japan), Tomoji Ikeda (Satake Corp., Japan), Hidekazu Takahashi, and = Masashi Murasaki (Hiroshima Univ., Japan)

4

  Water Ring Scan Order for MPEG-4 Fine Granular Scalable = Coding

 

Gwang Hoon Park, Seung Tae Kim, Yoon Jin Lee (Yonsei Univ., Wonju, Korea), Young Kwon Lim (MP4 = Cast, Korea), Hyun Cheol Kim, and Myoung Ho Lee (ETRI, = Korea)

5

Value Added Object Video Authoring Tools

 

  Pierre Pleven (Symah Vision, France)

6

  Web Based Multicast Audio and Video Application over QoS Enabled = Networks

 

Myung-Ki Shin and Yong-Jin Kim (ETRI, Korea)

7

Streaming MPEG-4 over IP and Broadcast Networks: DMIF Based = Architectures

 

Y. Pourmohammadi, K. Asrar Haghighi, A. Mohamed, and H. M. Alnuweiri (Univ. of British Columbia, = Canada)

8

Online Video Content Analysis for Collaborative Information Sharing and Dissemination in Semantic = Multicast

 

Wensheng Zhou, Son Dao (HRL Labs., U.S.A.), and C.-C. Jay Kuo (Univ. of Southern California, = U.S.A.)

9

Design of Appropriate Multiplexer and Its Corresponding Demutiplexer for = Multi-View Video          &n= bsp;        Communication System

 

Je-Woo Kim, Jong-Ho Paik, Byeong-Ho Choi, and Hyeok-Koo Jung (KETI, = Korea)

10

Design and Implementation of an Open Broadband Multimedia = System

 

Florin Lohan, Irek Defee (Tampere Univ. of Technology, Finland), and Harri Hakulinen (Nokia Home Communications, Finland)

11

A Study on the Interworking Platform Supporting Adaptive Stream = QoS

 

Byunghun Song, Kwangsue Chung, and Hyukjoon Lee (Kwangwoon Univ., = Korea)

SESSION MO3: Multicasting, = Standards and Network Control

Room: Grand = Ballroom (A)

Chair: T.B.D.

17:00~17:20

Classification of Receivers in Large Multicast Groups Using = Distributed

Kave Salamatian and Thierry Turletti (Univ. of Paris VI, France)

17:20~17:40

MPEG-7 Transcoding Hints for Reduced Complexity and Improved = Quality

Peter M. Kuhn, Teruhiko Suzuki (Sony Corp., Japan), and Anthony Vetro (MERL, U.S.A.)

17:40~18:00

Adding Delivery Support to MPEG-Pro, an Authoring System for = MPEG-4

Frederic Bouilhaguet, Cyril = Concolato, Souhila Boughoufalah, and Jean-Claude Dufourd (ENST, France)

18:00~18:20

An Efficient Scene-Based Renegotiation Scheduling and Admission Control for = RCBR Transmission of Real-Time Video Traffic

Jae Cheol Kwon, Myeong-jin Lee, and Jae-kyoon Kim (KAIST, Korea)

 

=A2=BATUESDAY, MAY 1, 2001

INVITED TALK (2) = (08:40~09:40)

Room: Grand = Ballroom (A)

Internet Video - Protocols & = Applications

Civanlar M. Reha (AT&T Labs Research, = U.S.A.)

SESSION TP1: Error Resilient and = Layered Coding (10:20~11:20)

Room: = Pine

Chair: T.B.D.

1

An Implementation of Coding Scheme for Packet Loss = Protection

Youshi Xu and Tingting Zhang (Mid-Sweden Univ., Sweden)

2

  Constraint-Reduced Regularization for Reducing Blocking Artifacts in Compressed = Video

In-Kyung Hwang, Shi-Chang Joung, Sung-Jin Kim, and Joon-Ki Paik (Chung-Ang Univ., = Korea)

3

Context-Based Block Motion = Estimation (CB-BME): A Low-Complexity Approach to Motion Analysis in Video = Coders

   F.G.B. De Natale and F. Granelli (Univ. of Trento, Italy)

4

Scalable Delivery of Digital Video Over Non-Prioritized ATM Networks: A Joint Source-Channel = Approach

R. Kurceren and J. Modestino (Rensselaer Polytechnic Inst., U.S.A.)

5

   Layered Wavelet Coding for Video

Claudia Schremmer, Christoph Kuhmuench, and Wolfgang Effelsberg (Univ. of Mannheim, = Germany)

6

   Design of Joint Source-Channel Decoder for H.263+ by MAP = Estimation

     = Ho-hyon Song, Yong-gu Kim, and Yoon-sik Choe (Yonsei Univ., = Korea)

7

   Motion Vector Recovery Based on Homogeneous Motion Area for H.263 Video = Communications

JungHyun Kim and GueeSang Lee (Chonnam Nat'l Univ., Korea)

8

  Redundancy Allocation Strategy for Multiple Description Transform Video = Coding

Sang-Uk Ryu and Yo-Sung Ho (K-JIST, Korea)

9

  Video Coding Using Color Set Partitioning in Hierarchical Trees = Scheme

Lee Wei Siong and Ashraf A. Kassim (Nat'l Univ. of Singapore, = Singapore)

10

A Novel Approach for the Concealment of JPEG2000 Transmission = Errors

Luigi Atzori, Stefano Corona, Daniele D. Giusto, and Alessio Raccis (Univ. of Cagliari, Italy)

11

An Efficient Data Partitioning and Coding for Error-Resilient DCT-Based = Images

Kyu-chan Roh, Kwang-deok Seo, and Jae-kyoon Kim (KAIST, Korea)

SESSION TO1: Wireless/Mobile = Packet Video

Room: Grand = Ballroom (A)

Chair: T.B.D.

11:20~11:40

Multiple Selective Retransmissions in RTP

Carsten Burmeister, Rolf Hakenberg, = Jose Rey (Panasonic, Germany), Akihiro Miyazaki, and Koichi Hata (Matsushita Electric Industrial Co. = Ltd., Japan)

11:40~12:00

A Joint Source Coding and Power Control Approach for Maximizing the Capacity of = CDMA Wireless Networks Supporting Heterogeneous Video = Traffic

Yee Sin Chan and J. W. Modestino (Rensselaer Polytechnic Inst., U.S.A.)

12:00~12:20

Design of an Adaptive Interface between Video Compression and Transmission = Protocols for Mobile Communication

Arjen van der Schaaf, Koen Langendoen, and R. L. Lagendijk (Delft Univ. of Technology, The = Netherlands)

12:20~12:40

IVideo - A Video Proxy for the Mobile Internet

Sam John, Rittwik Jana, Vinay Vaishampayan, and Amy Reibman (AT&T Research Lab., = U.S.A.)

12:40~13:00 

Wireless Video Transport Using = Conditional Retransmission and Low-Delay Interleaving

Supavadee Aramvith (Univ. of Washington, U.S.A.), Chia-Wen Lin (Nat'l Chung Cheng Univ., Taiwan), and Ming-Ting Sun (Univ. of Washington, U.S.A.)

SESSION TO2: Network Adaptive = Video Coding and Transport

Room: Grand = Ballroom (A)

Chair: T.B.D.

14:00~14:20 

A Joint Source-Channel Coding Approach for Packet Video Transport over Wireless = IP Networks

Y. Pei and J. W. Modestino = (Rensselaer Polytechnic Inst., U.S.A.)

14:20~14:40

Scalable Video Coding and its Delivery System over the = Internet

Atsushi Sagata, Yoshiyuki Yashima, Kazuto Kamikura, and Naoki Kobayashi (NTT, = Japan)

14:40~15:00

Rate Control Methods for Real-Time VBR Video Coding and = Transmission

Junfeng Bai, Chang Feng (Univ. of Missouri-Columbia, U.S.A.), Qingmin Liao, Xinggang Lin (Tsinghua = Univ., China), and Xinhua Zhuang (Univ. of Missouri-Columbia, = U.S.A.)

15:00~15:20

Progressiv Texture Video Streaming for Lossy Packet Networks

Thomas Stockhammer and = Christian Buchner (Munich Univ. of Technology, Germany)

15:20~15:40

Adaptive QoS Management for MPEG-4 Streaming Service over = Internet

Ji Hoon Choi, Sang Jo = Lee, Hyun Chul Kim, and Myung Ho Lee (Kyunghee Univ., Korea)

PANEL DISCUSSION = (16:00~17:00)

Room: Grand = Ballroom (A)

The detailed information will be informed soon.

 

------=_NextPart_000_0202_01C0BB9D.94277F90-- From rem-conf Mon Apr 02 18:05:02 2001 From rem-conf-request@es.net Mon Apr 02 18:05:01 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kFCC-0001bM-00; Mon, 2 Apr 2001 18:01:20 -0700 Received: from (mailserver.cncic.gov.cn) [202.106.165.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kFC5-0001aJ-00; Mon, 2 Apr 2001 18:01:14 -0700 Received: from ip195.kansas-city9.mo.pub-ip.psi.net_[38.27.195.195] ([38.27.195.195]) by mailserver.cncic.gov.cn (Netscape Messaging Server 4.15) with SMTP id GB6XHQ00.S1A; Tue, 3 Apr 2001 08:32:14 +0800 Received: from ns.smpc.co.kr by ip195.kansas-city9.mo.pub-ip.psi.net with ESMTP; Mon, 02 Apr 2001 19:31:44 -0600 Message-ID: <000075630d61$00001660$0000082a@ns.smpc.co.kr> To: From: andreas.schlegel@kali.com.cn Subject: How to Avoid Corporate Downsizing 2090 Date: Mon, 02 Apr 2001 19:31:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: apo05118@topmail.dk X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list HAVE YOU EVER WANTED TO LEARN WEB PAGE DESIGN WITH MACROMEDIA FLASH, DREAMWEAVER, OR ADOBE PHOTOSHOP? ARE YOU INTERESTED IN A CAREER IN THE INTERNET INDUSTRY? Thousands of companies are unable to fill their immediate job openings for web related positions at all levels. Information Technology careers earn some of the highest salaries in the country. Trained professionals will soon be able to work from the comfort of their own homes with new higher speed Internet connections. WE WANT TO HELP YOU! You will gain the skills necessary to become a successful web designer, entrepreneur, or web specialist through our online courses. You need no Internet experience because we're here to TEACH YOU! WHAT MAKES TRAINING WITH OUR INSTITUTION YOUR ANSWER? * Learning within a few days! * Affordable and subsidized tuition! * Free trial software! * Individual attention! * Learning at your own pace! * Pleasant, interactive, online classroom! * Career and placement help! * Commercial and personal training! * Conditional Money Back Guarantee! OUR DYNAMIC QUICKSTART PROGRAM You will learn how to build a professional commercial or personal web site in hours through our dynamic "Quick Start" program. Students, like you, will receive a package including fully functional, all-inclusive software for use in the class, along with essential trialware and freeware added to enhance your educational experience. You will have available to you all the most popular courses needed to succeed in the Web design business. Select from Microsoft Frontpage, Adobe Photoshop, HTML, Internet Marketing, Macromedia Flash, and Dreamweaver. You will learn more, learn faster, and get into the Web career world ahead of your competition with the color, action, and interactivity that are hallmarks of our classes. We prepare you for SUCCESS! >>TESTIMONIALS<< Mark M says: "When I enrolled at the University I had little skills in the web process. Now six months later I've built a valuable portfolio that I can market to potential clients or employees." Farnaaz T. says: "I would like to take this opportunity to thank you very much for your help. Thank you for being my support and my strength. If it wasn't for you I wouldn't have made it all the way." Jen A says: "The staff at the University has been great and the School has really opened doors for me!" THINK IT THROUGH.... As a Commercial Web Design Specialist, THERE ARE NO LIMITS! Our staff of Student Counselors and Advisors will help you to properly structure your curriculum and answer any questions you may have. To maintain our highest level of service to motivated students, class sizes will be limited each session. To speak with the Admissions Office about your needs, please phone the following number and leave the outlined responses shown below. CALL NOW FOR MORE INFORMATION >> (303) 215-3063 >> CALL ANYTIME! When you call, we will need: - Your Full Name - Your Phone Number - Best Weekday to Contact You - Your E-mail Address CALL ANYTIME! (303) 215-3063 (REMOVAL INSTRUCTIONS) This mailing is done by an independent marketing company. We respect your online privacy and apologize if you have received this message in error. We do respect our remove lists! Please do not use the reply to this e-mail, an e-mail reply cannot be read! If you would like to be removed from our mailing list just click below and send us a remove request email. (To Be Removed) mailto:notme750@europe.com?subject=RemoveWebSchool From rem-conf Mon Apr 02 20:48:46 2001 From rem-conf-request@es.net Mon Apr 02 20:48:46 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kHlH-00010g-00; Mon, 2 Apr 2001 20:45:43 -0700 Received: from gw.policja.krasnik.pl [212.182.118.194] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 14kHl9-0000yT-00; Mon, 2 Apr 2001 20:45:38 -0700 Received: (qmail 80344 invoked from network); 3 Apr 2001 03:52:47 -0000 Received: from unknown (HELO j98OH113y?) (129.37.237.91) by 0 with SMTP; 3 Apr 2001 03:52:47 -0000 DATE: 02 Apr 01 10:51:48 PM FROM: h30sj39@enoreo.on.ca Message-ID: <3j15PBMbA3MO0sp2> SUBJECT: Sell a product which costs nothing to produce! Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend: Your first thought about this is to say "BULL", JUST LIKE I did! HOWEVER, BEFORE YOU SAY IT, read the following. We are cutting out most of the "sensational" & "amazing" stuff and the time-consuming testimonial details in order to get to the MAIN EVENT. And, that is - "BE A MILLIONAIRE, LIKE OTHERS, WITHIN A YEAR!" This plan was in the news lately. A national weekly news program devoted an entire show to the investigation of this program, described below, to see if it really can MAKE PEOPLE MONEY, and whether it is legal. Their findings proved once and for all that there are ABSOLUTELY NO LAWS prohibiting the participation in the program; and, if people can follow the simple instructions, they can make MEGA BUCKS with only $25 out-of-pocket costs DUE TO THE RECENT INCREASE OF POPULARITY AND RESPECT THIS PROGRAM HAS ATTAINED, IT IS WORKING BETTER THAN EVER!! FOLLOW THESE SIMPLE INSTRUCTIONS: FIRST: Order all 5 reports shown on the list below. For each report, which you will need later, send $5 CASH (NO CHECKS OR FOREIGN CURRENCY). Wrap the cash in at least 2 sheets of paper & write the REPORT NUMBER and NAME OF THE REPORT YOU ARE ORDERING, AND YOUR E-mail ADDRESS to the person whose name appears ON THAT LIST next to the report. THEY ARE: ----------------------------------------------------------------------- REPORT #1 "The Insider's Guide to Advertising for FREE on the Net” ORDER REPORT #1 FROM: CWM Enterprises POBox 2234 Asheboro NC 27204-2234 USA ----------------------------------------------------------------------- REPORT #2 "The Insider's Guide to Sending Bulk Email on the Net". ORDER REPORT #2 FROM: David Campion 2649 Majestic Circle Dacula GA 30019 USA -------------------------------------------------------------------- REPORT #3 "The Secret to Multilevel Marketing on the Net" ORDER REPORT #3 FROM: DMB Enterprises 612 Albemarle Terrace Portland, OR 97210-3113 USA -------------------------------------------------------------------------- REPORT #4 "How To Become a Millionaire Utilizing MLM and the Net” ORDER REPORT #4 FROM: B. W. Hill 17100 Collins Ave #110-100 N Miami Beach, FL 33160 USA -------------------------------------------------------------------------- REPORT #5 "How to send 1,000,000 Emails for FREE. ORDER REPORT #5 FROM: John Lutheran PO Box 33555 San Diego CA 92163-3555 USA -------------------------------------------------------------------------- NOW, AFTER YOU HAVE ORDERED ALL 5 REPORTS (Enclosing $5 Cash and a sheet with your Name and Email address & the Report #) DO THIS: Take this letter, and: 1. REMOVE the name & address of the person in REPORT #5. 2. Move the name & address from REPORT #4 down to REPORT #5. 3. Move the name & address from REPORT #3 down to REPORT #4. 4. Move the name & address from REPORT #2 down to REPORT #3. 5. Move the name & address from REPORT #1 down to REPORT #2. 6. INSERT YOUR NAME & ADDRESS IN THE REPORT #1 POSITION. PLEASE MAKE SURE YOU COPY NAMES & ADDRESSES ACCURATELY!!!! Also IMPORTANT. Do NOT alter the names of the people who are listed for each report (other than the changes instructed above). If you do, you will DESTROY the pyramid and LOSE OUT ON THE MAJORITY OF YOUR PROFITS. Once you understand the way this works, you will also see how it DOES NOT WORK if you CHANGE IT IN ANY WAY!!! ****Now, take this ENTIRE LETTER, WITH THE MODIFIED LIST OF NAMES and SAVE IT ON YOUR COMPUTER. Do not make any other changes. YOU WILL NEED THIS TO DO YOUR BULK E-MAILINGS. ****When you receive the 5 Reports you ordered, SAVE THEM ON YOUR COMPUTER, ALSO. You will need them to fill orders that you receive. This is important!! ---------------------------------------------------------------------- There are 2 PRIMARY METHODS to get this venture going: 1.BY SENDING BULK EMAIL LEGALLY. Let's say you decide to start small and that you send out only 5,000 Emails and get only a small 0.2% response. That is 10 orders for Report #1. Those 10 people send out 5,000 Emails each for a total of 50,000. At the 0.2% response rate, you get orders for 100 Report #2. Those 100 send out 5,000 each and you receive orders for 1,000 of Report #3. This 1000 sends out 5000 each and you get orders for 10,000 Report #4. Those 10,000 send out 5,000 each and you receive 100,000 orders for Report #5. ADD IT UP!!! YOUR TOTAL INCOME IN THIS EXAMPLE IS: #1 - $50: #2 - $500: #3 - $5,000: #4 - $50,000: #5 - $500,000. THIS ADDS UP TO A GRAND TOTAL OF $555,550.00 FOR YOU. The above example uses the very minimum response. Many people will send out 100,000/250,000/500,000 EMails. Just take a moment to compute what this could mean in earnings for YOU!! 2. BY PLACING FREE ADS ON THE INTERNET. Advertising on the Net is very, very inexpensive and there are hundreds of FREE PLACES to advertise. Placing a lot of free ads will easily get a larger response. We strongly suggest that you start with METHOD #1 and then add METHOD #2 as you go along. For every $5.00 you receive, all you must do is Email them the Report they ordered. THAT'S IT!. Always provide SAME DAY SERVICE ON ALL ORDERS. This will guarantee that the Emails they send out, with YOUR NAME & ADDRESS on it, will be prompt because they cannot advertise until they receive the report. ------------------------------------------------------------------------ ///////////////////////// YOUR SUCCESS GUIDELINES \\\\\\\\\\\\\\\\\\\\\\\\\\ ***If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. ***After you have received 10 orders for #1, in about 2 to 3 weeks, you should receive 100 orders for Report #2. If you do not, continue sending emails until you do. ***Once you have received 100 or more orders for Report #2, YOU CAN RELAX because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER. Every time your name is moved down on the list, you are placed in front of a different Report. You can keep track of your progress by watching WHICH REPORT PEOPLE ARE ORDERING FROM YOU. If you want to GENERATE MORE INCOME, SEND ANOTHER BATCH OF EMAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business. ------------------------------------------------------------------------- NOW YOU HAVE BEFORE YOU THE IDEAS, INFORMATION, MATERIALS, and OPPORTUNITY TO BECOME FINANCIALLY INDEPENDENT. ==SO, IT IS UP TO YOU!!!=== -------------------------------------------------------------- /////////// TESTIMONIALS \\\\\\\\\\\\\\ We have many testimonials from people who claim to have made fortunes with this plan, like the following brief summary: ***A couple from Chicago reports $147,200 in 45 days. ***An individual from Canada made $319,210 the first 12 wks. ***A lady from NY made over $490,000 on her first try, and she's started another round. We decided the letter was too long, so we have omitted many paragraphs of details on these. Besides, we don't know them and cannot verify their reports. We think it is a great, legal, money-raising venture; and, we had much rather notify you later of HOW MUCH MONEY WE MADE WITH IT! ///////////////////// GOOD LUCK!!! \\\\\\\\\\\\\\\\\\\\\\\\\ ---------------------------------------------------------------------- If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D C. //////THIS IS A ONE TIME MAILING NO NEED TO REMOVE\\\\\\\ This message is sent in compliance of the proposed bill SECTION 301 per Section 301, Paragraph (a)(2)(C) of S1618. Further transmission to you by the sender of this e-mail maybe stopped at no cost to you by sending a reply to: Sophie530@email.com with the word Remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. ******************************************************* THIS LETTER CONSTITUTES NO GUARANTEES STATED NOR IMPLIED. IN THE EVENT THAT IT IS DETERMINED THAT THIS LETTER CONSTITUTES A GUARANTEE OF ANY KIND, THAT GUARANTEE IS NOW VOID. ANY TESTIMONIALS OR AMOUNTS OF EARNINGS LISTED IN THIS LETTER MAY BE FACTUAL OR FICTITIOUS. ******************************************************** From rem-conf Tue Apr 03 05:02:00 2001 From rem-conf-request@es.net Tue Apr 03 05:01:58 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kPKc-0002hT-00; Tue, 3 Apr 2001 04:50:42 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kPKa-0002hI-00; Tue, 3 Apr 2001 04:50:40 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26753; Tue, 3 Apr 2001 07:50:32 -0400 (EDT) Message-Id: <200104031150.HAA26753@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-amr-06.txt Date: Tue, 03 Apr 2001 07:50:32 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format and file storage format for AMR and AMR-WB audio Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt, Q. Xie, S. Gupta Filename : draft-ietf-avt-rtp-amr-06.txt Pages : 26 Date : 02-Apr-01 This document specifies a real-time transport protocol (RTP) payload format to be used for AMR and AMR-WB speech encoded signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats. Furthermore, a file format for storage of AMR and AMR-WB speech data is specified. Two separate MIME type registrations, one for AMR and one for AMR-WB, describing both RTP payload format and storage format are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-amr-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-amr-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010402124256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124256.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Apr 03 08:38:23 2001 From rem-conf-request@es.net Tue Apr 03 08:38:23 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kSoJ-00011i-00; Tue, 3 Apr 2001 08:33:35 -0700 Received: from ada.cs.ucy.ac.cy [194.42.7.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kSoH-00011Y-00; Tue, 3 Apr 2001 08:33:34 -0700 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id SAA25434 for ; Tue, 3 Apr 2001 18:39:29 +0300 Message-ID: <024f01c0bc54$400b21c0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: Subject: Call for participation -- Infocom 2001, April 22-26, 2001, Anchorage, Alaska Date: Tue, 3 Apr 2001 18:39:20 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OUR SINCERE APOLOGIES FOR MULTIPLE COPIES C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska TRAIN CHARTER: This year we are chartering a train for our welcome reception. This train ride will take you through the Kenai fjords and will include food and drinks. April 24, 6-11 pm. Seats are limited, and will be given out on the basis of registration date. CONFERENCE REGISTRATION: The deadline for advance registration is April 2, 2001 (5pm Eastern Standard Time). Please register early to ensure that you have a seat in the train charter. On-line registration is possible at our website at http://www.ieee-infocom.org/2001 and then clicking on "Registration Information". Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. HOTEL REGISTRATION: Please book your hotel room early at the Marriott Anchorage Downtown. The Hilton is now completely sold out. The conference rates at both hotels are the same and the two hotels are within a 5 minute walking distance of each other. TOURS: Several tours of Alaska's natural treasures are planned. Please visit our website at http://www.ieee-infocom.org/2001 and look for "On-line tour registration". AIRLINE TICKETS: Please book your flights to Anchorage early, so that you can get reasonably priced tickets. TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications Quality of Service (QoS) Support for Broadband Wireless Networks Traffic Engineering in IP/MPLS Networks TCP Congestion Controls: Algorithms and Models Video Over IP Bluetooth and Pervasive Wireless Networking Control and Management for Optical Networks: An IP-Centric Approach Principles of Multicast Protocols and Services PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model From rem-conf Tue Apr 03 09:04:05 2001 From rem-conf-request@es.net Tue Apr 03 09:04:04 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kTFr-0003S3-00; Tue, 3 Apr 2001 09:02:03 -0700 Received: from patan.sun.com [192.18.98.43] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kTFq-0003Rt-00; Tue, 3 Apr 2001 09:02:02 -0700 Received: from amon.Central.Sun.COM ([129.147.4.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06708 for ; Tue, 3 Apr 2001 09:02:01 -0700 (PDT) Received: from Sun.COM (sunray18 [129.147.4.63]) by amon.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19283 for ; Tue, 3 Apr 2001 10:02:00 -0600 (MDT) Sender: Matthew.Matheis@Sun.COM Message-ID: <3AC9F3F8.D562BBD5@Sun.COM> Date: Tue, 03 Apr 2001 10:02:00 -0600 From: matthew matheis Reply-To: matt.matheis@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list subscribe to Mbone Announcements From rem-conf Tue Apr 03 11:22:42 2001 From rem-conf-request@es.net Tue Apr 03 11:22:42 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kVPA-0005OZ-00; Tue, 3 Apr 2001 11:19:48 -0700 Received: from relay.eecs.berkeley.edu [169.229.34.228] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kVP8-0005OP-00; Tue, 3 Apr 2001 11:19:46 -0700 Received: from bmrc.berkeley.edu (ix.CS.Berkeley.EDU [128.32.36.141]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA05057; Tue, 3 Apr 2001 11:19:45 -0700 (PDT) Message-ID: <3ACA1336.997C604B@bmrc.berkeley.edu> Date: Tue, 03 Apr 2001 11:15:19 -0700 From: Florissa Colina X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/4 The Future of the GUI -- John Ousterhout, Interwoven, Inc. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar The Future of the GUI Wednesday April 4, 2001 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) John Ousterhout Interwoven, Inc. Graphical user interfaces as we knew them in the 1980s and early 1990s are on the road to extinction, replaced by Web-based GUIs. In this talk I will discuss issues in using the Web for "real" GUIs (as opposed to documents and forms) and compare Web-based GUIs to traditional GUIs. I will also speculate about how the facilities for Web-based GUIs might evolve in years to come. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Apr 03 23:37:06 2001 From rem-conf-request@es.net Tue Apr 03 23:37:05 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kgpj-0007SU-00; Tue, 3 Apr 2001 23:31:59 -0700 Received: from mcigate1.mci.mei.co.jp [210.146.208.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kgpg-0007OZ-00; Tue, 3 Apr 2001 23:31:56 -0700 Received: from postman.mci.mei.co.jp (postman.mci.mei.co.jp [133.185.181.250]) by mcigate1.mci.mei.co.jp (/) with SMTP id PAA13552 for ; Wed, 4 Apr 2001 15:30:52 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.9.1/3.7Wpl2:mcihub1:01030620) id PAA21878; Wed, 4 Apr 2001 15:30:51 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.10.2/3.7W-GW1) with ESMTP id f346U5u13876 for ; Wed, 4 Apr 2001 15:30:05 +0900 (JST) Received: from sannoudou by gaugin.telecom.mci.mei.co.jp (8.11.2/3.7W-TELECOM) with SMTP id f346UoF02959 for ; Wed, 4 Apr 2001 15:30:50 +0900 (JST) Message-ID: <013401c0bcd0$a33cbca0$dc16a8c0@sannoudou.telecom.mci.mei.co.jp> From: "Toru Sannoudou" To: Subject: rem-conf-request@es.net Date: Wed, 4 Apr 2001 15:29:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Wed Apr 04 02:31:57 2001 From rem-conf-request@es.net Wed Apr 04 02:31:56 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14kjY9-0007Mr-00; Wed, 4 Apr 2001 02:26:01 -0700 Received: from (mail10.netsgo.com) [211.39.33.54] by mail1.es.net with esmtp (Exim 1.81 #2) id 14kjY7-0007Ji-00; Wed, 4 Apr 2001 02:25:59 -0700 Received: from gate1 ([150.23.24.41]) by mail10.netsgo.com with Microsoft SMTPSVC(5.5.1877.447.44); Wed, 4 Apr 2001 18:24:53 +0900 Message-ID: <007401c0bce9$04fc0140$29181796@sktelecom.com> From: "Seung Jun Lee" To: References: <002601c0bb58$76d72020$8001a8c0@oleane.com> Subject: Question: RTP Payload format for G.723.1 Date: Wed, 4 Apr 2001 18:24:14 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C0BD34.73F8AD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C0BD34.73F8AD00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 SSdkIGxpa2UgdG8gZ2V0IHNvbWUgaW5mb3JtYXRpb24gb24gUlRQIHBheWxvYWQgZm9ybWF0IGZv ciBHLjcyMy4xLg0KSSd2ZSBzZWFyY2hlZCBSRkMgZGF0YWJhc2UgYnV0IEkgY291bGRuJ3QgZmlu ZCBhbnkuDQpDb3VsZCBhbnlvbmUgaGVscCA/DQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KU2V1bmcu DQo= ------=_NextPart_000_0071_01C0BD34.73F8AD00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNS4wMC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3 NTQ4OyBzaXplPTI+SSdkIGxpa2UgdG8gZ2V0IHNvbWUgaW5mb3JtYXRpb24gb24gUlRQIHBheWxv YWQgZm9ybWF0IA0KZm9yIEcuNzIzLjEuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj NDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPkkndmUgc2VhcmNoZWQgUkZDIGRhdGFiYXNlIGJ1dCBJIGNv dWxkbid0IGZpbmQgDQphbnkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7 JiM0NzU0ODsgc2l6ZT0yPkNvdWxkIGFueW9uZSBoZWxwID88L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+VGhhbmtzIGluIGFkdmFuY2UuPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1 NDg7IHNpemU9Mj5TZXVuZy48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0071_01C0BD34.73F8AD00-- From rem-conf Thu Apr 05 04:14:41 2001 From rem-conf-request@es.net Thu Apr 05 04:14:40 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14l77A-0007DO-00; Thu, 5 Apr 2001 03:35:44 -0700 Received: from plmta00.chello.pl [213.46.248.62] by mail1.es.net with esmtp (Exim 1.81 #2) id 14l778-0007Cw-00; Thu, 5 Apr 2001 03:35:42 -0700 Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:00:38 -0100 From: "Rita de Groot" To: Subject: huidziekte Sender: "Rita de Groot" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:09 +0200 Content-Transfer-Encoding: 8bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From rem-conf Thu Apr 05 12:03:59 2001 From rem-conf-request@es.net Thu Apr 05 12:03:57 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14lExV-0002tS-00; Thu, 5 Apr 2001 11:58:17 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 14lExT-0002tA-00; Thu, 5 Apr 2001 11:58:15 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA08245; Thu, 5 Apr 2001 11:50:36 -0700 Message-ID: <3ACCBF9B.57063A11@bmrc.berkeley.edu> Date: Thu, 05 Apr 2001 10:55:23 -0800 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/11 Berkeley Multimedia, Interfaces and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar (http://bmrc.berkeley.edu/mig) Overview of the TiVo Service Architecture April 11, 2001, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Jim Barton TiVo, Inc. The TiVo Service is based on a scalable distributed architecture for the management and provisioning of many different kinds of meta-data for each TiVo subscriber. This talk provides an overview of the architectural philosophy and actual implementation of the complete end-to-end service platform, including a discussion of the challenges of building a reliable consumer oriented "black box" using modern computer technologies. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Fri Apr 06 09:22:50 2001 From rem-conf-request@es.net Fri Apr 06 09:22:50 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14lYo1-00014A-00; Fri, 6 Apr 2001 09:09:49 -0700 Received: from canospam.agcs.com [130.131.166.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 14lYnz-00013n-00; Fri, 6 Apr 2001 09:09:47 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id JAA26407 for ; Fri, 6 Apr 2001 09:09:46 -0700 (MST) Posted-Date: Fri, 6 Apr 2001 09:09:46 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Fri Apr 06 09:09:34 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id JAA17126 for ; Fri, 6 Apr 2001 09:09:26 -0700 (MST) Received: from agcs.com ([130.131.75.186]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA6654; Fri, 6 Apr 2001 09:09:45 -0700 Message-ID: <3ACDEA49.F8829882@agcs.com> Date: Fri, 06 Apr 2001 09:09:45 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net CC: PacketCable PSTN Majordomo List Subject: RFC 2833 'E' bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The 'E' (end-of-event) bit is used to indicate that an event such as a DTMF tone has ended. This is a useful bit of information where the event in question is truely an event. Some events reported in RFC 2833 event payloads are actually states. One example of this is the ABCD trunking events (144..159). For these events the 'E' bit is meaningless since the appearance of a different event/state implies the end of the previous event/state. In some applications having to send this extra event is in fact detrimental since extra delay may be incurred (e.g.-where access bandwidth is limited). I believe it would be useful to allow the use of the 'E' bit to be optional for events that are actually states. Thoughts? Rex From rem-conf Sun Apr 08 22:10:54 2001 From rem-conf-request@es.net Sun Apr 08 22:10:53 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14mTYS-0003UM-00; Sun, 8 Apr 2001 21:45:32 -0700 Received: from postal2.es.net [198.128.3.206] by mail1.es.net with esmtp (Exim 1.81 #2) id 14mTYR-0003UC-00; Sun, 8 Apr 2001 21:45:31 -0700 Received: from sj-msg-core-1.cisco.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Sun, 08 Apr 2001 21:45:30 -0700 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA01505; Sun, 8 Apr 2001 21:45:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn-tmp14.cisco.com [10.21.64.14]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAD01065; Sun, 8 Apr 2001 21:45:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20010408214207.022f5ec8@mail.potlnd1.or.home.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Apr 2001 21:44:32 -0700 To: Chuck Harrison From: Mark Baugher Subject: Re: Secure RTP; crypto context Cc: rem-conf@es.net In-Reply-To: <3AC6309E.A27F5EBC@iname.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chuck I wanted to call your attention to some key management work that is going on in the MSEC WG that some of us want to apply to SRTP. It's GDOI, http://search.ietf.org/internet-drafts/draft-ietf-msec-gdoi-00.txt I don't yet know how this could fit with the MPEG-4 IPMP work. regards, Mark At 11:31 AM 3/31/2001 -0800, you wrote: >Greetings! > >Please apply newbie disclaimer, I have not been working in this area >very long. > >While >http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt >describes particular default methods, I think there is an implicit >longing for a way to generalize the protocol. Could we piggyback on RFC >2630, Cryptographic Message Syntax, and its AES update? >http://www.ietf.org/rfc/rfc2630.txt >http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-01.txt > >I am visualizing a "detached content" mode, wherein the encrypted >content (a big chunk of it...as much as you encrypt under a single key >context) is separated from the "header" info. The content is packetized, >and transmitted over an RTP stream pretty much as in the srtp-00 draft. > >It seems that the "classic" RTP approach would then be to send the rest >of the CMS message (i.e. the "crypto header") out-of-band. However, I >think the "new paradigm" is to consider it to be an additional media >stream. Over in MPEG they call it an IPMP stream. In this paradigm, the >crypto header info is part of the multimedia session. Because transport >is likely to be unreliable, and participants may "hop on", it will >probably be retransmitted periodically. If key change is required, this >is handled by sending a new crypto header on the IPMP stream, and >starting a corresponding new piece of "detached content" on the media >stream. > >As noted by others, key change must be synchronized between the IPMP >stream and media stream. This could be done using the extended packet >sequence number defined in srtp-00. It could also be done by timestamp. >(Some of you know that I think general multistream timestamp-based sync >should be added to RTP. But don't hold your breath. ) As a >pragmatist, I think the "odd/even" approach deployed in ATSC (and DVB?) >is simple, robust, and worth standardizing. See the ATSC guide >http://www.fcc.gov/Bureaus/Engineering_Technology/Documents/atsc/a54/ >section 8.5.3, esp. figure 8.15. > >.... >And another detail from srtp-00. It states, > When RTP authentication is not present, robust synchronization is not > possible. In this case, transmission errors or an active attacker may > force the receiver to erroneously update his rollover counter and > thus to become completely out of synch. It is not possible to protect > against active attackers in such case [...] > >I would think that, if the rollover counter is only updated when the >packet is successfully decrypted, then active attacks would be >suppressed without authentication overhead. Determining "successful >decryption" may be trivial with some highly structured payload formats >and impossible with others. Thus this technique is a definite MAY. > >.... >And *another* piece of spew... >It seems there is considerable concern about D.O.S. attacks. Should we >think about a way to filter spurious packets within the network, before >they reach the target device? Maybe the filter function could be >provided by an "RTP translator" entity? I am thinking particularly you >would want to remove the garbage before it hits a wireless link. > >Cheers, > Chuck Harrison > Far Field Associates, LLC > co-chair, SMPTE DC28.4 Study Group on Conditional Access > for Digital Cinema > +1 360 863 8340 (voice) GMT-0800 From rem-conf Mon Apr 09 08:29:20 2001 From rem-conf-request@es.net Mon Apr 09 08:29:19 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14mdVr-0000G3-00; Mon, 9 Apr 2001 08:23:31 -0700 Received: from tateyama.tokyo.main.co.jp (mail.ru) [210.164.197.66] by mail1.es.net with smtp (Exim 1.81 #2) id 14mdVm-0000Ft-00; Mon, 9 Apr 2001 08:23:29 -0700 X-Server: x-server From: "19.95" To: rem-conf@es.net Subject: ADV. Natural penis enlargement -without surgery-! Date: Mon, 9 Apr 2001 00:13:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ================ Removal Information ========================= This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. This message is not intended for residents in the State of WA, NV, CA & VA. Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia,or California resident please remove yourself. We respect all removal requests. To Be Removed: mailto:s_health12@consultant.com?subject=remove. If you DID NOT "opt-in", meaning -at some time- signed up to receive health and/or sexual health related information, please send removal request. ================================================================= This is for adult men only !!! ****************** If you did not 'opt-in', please delete now! *** ****************** IF YOU ARE NOT AN ADULT, DELETE NOW !! ******** We are a serious company, offering a program that will enhance your sex life, and enlarge your penis in a totally natural way. We realize many men -and their women- are unhappy with their penis size. The truth is that size matters, not only it affects many men's performance, but their self-esteem as well. Penis enlargement is POSSIBLE; just as you can exercise almost any part of your body, you CAN exercise your penis. Our program is totally PROVEN and GUARANTEED !!! Our company has the techniques! Totally NATURAL techniques; no gadgets, no pumps, no surgery! If you want more information, please send an email with 'more info'in the subject to: info168@usa.com -mailto:info168@usa.com?subject=moreinfo-.. This is an automated answer, for removal use s_health12@consultant.com. If the above link has been removed, just reply to this message with 'more info' on the subject line. This IS NOT UNSOLICITED; you appear in an opt-in list, if in error, please remove yourself. Please let those who suffer from erectile dysfunction, similar problems or small penis size receive this information! =============== DISPONIBLE TAMBIEN EN ESPAÑOL =================== From rem-conf Mon Apr 09 10:21:32 2001 From rem-conf-request@es.net Mon Apr 09 10:21:31 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14mfHw-0001El-00; Mon, 9 Apr 2001 10:17:16 -0700 Received: from postal2.es.net [198.128.3.206] by mail1.es.net with esmtp (Exim 1.81 #2) id 14mfHu-0001ER-00; Mon, 9 Apr 2001 10:17:14 -0700 Received: from toyo01.toyoshima.com.tw ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876; Mon, 09 Apr 2001 10:17:12 -0700 Received: from mailmij.nl (203.167.112.171 [203.167.112.171]) by toyo01.toyoshima.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id HBLVWBKD; Tue, 10 Apr 2001 01:12:39 +0800 Message-ID: <000059e41d65$000010d6$000025d4@centrum.cz> To: From: qiaqjcsipl@centrum.cz Subject: . Date: Mon, 09 Apr 2001 09:02:42 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Minister Charles Simpson has the power to make you a LEGALLY ORDAINED MINISTER within 48 hours!!!! 11.a BE ORDAINED NOW! As a minister, you will be authorized to perform the rites and ceremonies of the church!! WEDDINGS MARRY your BROTHER, SISTER, or your BEST FRIEND!! Don't settle for being the BEST MAN OR BRIDES' MAID Most states require that you register your certificate (THAT WE SEND YOU) with the state prior to conducting the ceremony. FUNERALS A very hard time for you and your family Don't settle for a minister you don't know!! Most states require that you register your certificate (THAT WE SEND YOU) with the state prior to conducting the ceremony. BAPTISMS You can say "WELCOME TO THE WORLD!!!! I AM YOUR MINISTER AND YOUR UNCLE!!" What a special way to welcome a child of God. FORGIVENESS OF SINS The Catholic Church has practiced the forgiveness of sins for centuries **Forgiveness of Sins is granted to all who ask in sincerity and willingness to change for the better!! VISIT CORRECTIONAL FACILITIES Since you will be a Certified Minister, you can visit others in need!! Preach the Word of God to those who have strayed from the flock WANT TO START YOUR OWN CHURCH?? After your LEGAL ORDINATION, you may start your own congregation!! At this point you must be wondering how much the Certificate costs. Right? Well, let's talk about how much the program is worth. Considering the value of becoming a CERTIFIED MINISTER I'd say the program is easily worth $100. Wouldn't you agree? However, it won't cost that much. Not even close! My goal is to make this life changing program affordable so average folks can benefit from the power of it. Since I know how much you want to help others, you're going to receive your Minister Certification for under $100.00... Not even $50.00... You are going to receive the entire life-changing course for only $29.95. For only $29.95 you will receive: 1. 8-inch by 10-inch certificate IN COLOR, WITH GOLD SEAL. (CERTIFICATE IS PROFESSIONALLY PRINTED BY AN INK PRESS) 2. Proof of Minister Certification in YOUR NAME!! 3. SHIPPING IS FREE!!! *********************************************************************** LIMITED TIME OFFER: ORDER TODAY! SEND Only $29.95 US (CREDIT CARD, CASH, CHECK, OR MONEY ORDER) SHIPPING IS FREE!!!For Shipping OUTSIDE the US please add $11.00. To place your order merely fill out the following form and fax to 1-775-535-7852. If this line is busy, please try faxing to 1-801-383-9138. or mail to: Internet Information Services PO Box 21442 Billings, MT 59104 (ALL ORDERS FILLED WITHIN 24 HOURS OF RECEIVING THEM) *Please allow 8 days to receive your certificate by mail. If you do not receive your order within 10 days, please send us a fax letting us know of the late arrival. We will then contact you to figure out why you have not received your order. ************************* Credit Card Order Form (Please print very clearly in dark ink) Name on Credit Card: Address: City/State/ZIP: Your email address: Your card will be charged $29.95 for your Ministers' Certificate. For Shipping OUTSIDE the US please add $11.00. Type of Card, circle one (Visa, MasterCard, American Express) Credit Card Number: Date Credit Card Expires: Please tell us your phone Number: Please tell us your fax Number: To order by Check or Money Order: MAKE YOUR CHECK PAYABLE TO: Internet Information Services (Please Print Clearly Your Name and Address) Name: Address: City/State/ZIP: E-mail Address: Please tell us your phone Number: Please tell us your fax Number: (ALL ORDERS FILLED WITHIN 24 HOURS OF RECEIVING THEM) *Please allow 8 days to receive your certificate by mail. If you do not receive your order within 10 days, please send us a fax letting us know of the late arrival. We will then contact you to figure out why you have not received your order. Thank you for your business, Internet Information Services PO Box 21442 Billings, MT 59104 Fax to 1-775-535-7852. If this line is busy, please try faxing to 1-801-383-9138. Copyright (c) 1997-2000 All Rights Reserved ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This ad is produced and sent out by: Universal Advertising Systems To be removed from our mailing list please email us at vanessagreen@freeze.com with remove in the subject line or call us toll free at 1-888-605-2485 and give us your email address or write us at: Central DB Removal, PO Box 1200, Oranjestad, Aruba ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ cvgfdhgbjhfdgjhdgjhfdjhjg768345054768757FDJGHXVBXHHHhbGggfgbfdhglsjdhxnbcnvbnxcfhsbfnbsdbfdj From rem-conf Tue Apr 10 12:38:53 2001 From rem-conf-request@es.net Tue Apr 10 12:38:52 2001 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 14n3kt-0002lZ-00; Tue, 10 Apr 2001 12:24:47 -0700 Received: from postal1.es.net [198.128.3.205] by mail1.es.net with esmtp (Exim 1.81 #2) id 14n3kr-0002lP-00; Tue, 10 Apr 2001 12:24:45 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Tue, 10 Apr 2001 12:24:44 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA26994; Tue, 10 Apr 2001 12:18:56 -0700 Message-ID: <3AD35DC3.E4C59E95@bmrc.berkeley.edu> Date: Tue, 10 Apr 2001 12:23:47 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/11 Berkeley Multimedia, Interfaces and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar (http://bmrc.berkeley.edu/mig) Overview of the TiVo Service Architecture April 11, 2001, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Jim Barton TiVo, Inc. The TiVo Service is based on a scalable distributed architecture for the management and provisioning of many different kinds of meta-data for each TiVo subscriber. This talk provides an overview of the architectural philosophy and actual implementation of the complete end-to-end service platform, including a discussion of the challenges of building a reliable consumer oriented "black box" using modern computer technologies. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Wed Apr 11 10:58:50 2001 From rem-conf-request@es.net Wed Apr 11 10:58:48 2001 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14nOtA-0000si-00; Wed, 11 Apr 2001 10:58:44 -0700 Received: from postal1.es.net ([198.128.3.205]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14nOt8-0000sY-00; Wed, 11 Apr 2001 10:58:42 -0700 Received: from canospam.agcs.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 11 Apr 2001 10:58:41 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id KAA05325 for ; Wed, 11 Apr 2001 10:58:40 -0700 (MST) Posted-Date: Wed, 11 Apr 2001 10:58:40 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Apr 11 10:58:39 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id KAA12705 for ; Wed, 11 Apr 2001 10:58:18 -0700 (MST) Received: from agcs.com ([130.131.56.175]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA6044; Wed, 11 Apr 2001 10:58:38 -0700 Message-ID: <3AD49B2C.86DC72E@agcs.com> Date: Wed, 11 Apr 2001 10:58:05 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: Other work/charter update References: <200103231725.MAA04181@purple.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list For the ABCD trunking events, which are likely to run into the duration problem periodically, the duration field probably is not very important. We have the timestamp, which indicates the start time of the event in every event packet that repeats the same event. And we also have the sequence number. The duration field would be largely ignored by implementations other than for having to set it to something that is RFC 2833 compliant. For the ABCD event application it would be acceptable to allow the duration field to be treated as an unsigned integer and just allow it to wrap around. Alternatively, allowing a value of zero to be used if duration is to be ignored would be a simpler and less expensive thing to do. We look forward to Henning's ID. Rex Colin Perkins wrote: > Folks, > > There have been a number of areas where progress has occured since the last > meeting, but which were not discussed in the AVT meeting yesterday. These > include: RFC 2833 errata, payload formats for meta-information, and the new > draft on precision audio/video. In addition, we need to re-charter the AVT > working group. > > Regarding RFC 2833 errata, we note the following: > - The MF S1...S3 codes have two code points, but need three. We > agreed, on the mailing list, to deprecate codes 142 and 143, > and assign new numbers. > - We may need to add a channel failure event to signal E1 loss of > frame > - What is the procedure for events longer than those which can be > represented in the duration field? Are continuation packets > acceptable? > Henning Schulzrinne will produce an updated draft addressing these issues. > > At the San Diego meeting, two payloads for meta-information were presented. > The authors have been working on this since then, and believe it makes > sense to focus on a common (payload independent) set of mechanisms for > indicating and communicating metadata associated with RTP streams. For > example: > - announcing sessions with associated metadata (SDP) > - requesting streams with associated metadata (RTSP) > - specifying the communication of metadata (in-band vs. > out-of-band, separate metadata stream vs. mixed media/meta-data > stream) > Subsequent to that, they will consider the matter of payload format(s) > themselves. We expect to see an update in future. > > Chuck Harrison submitted a new draft on precision audio/video > (draft-harrison-avt-precision-av-00.txt). The abstract reads: > This memo discusses methods for transporting audio-visual content > over the Internet while meeting professional-quality temporal > performance. This memo gives information about the timing > requirements and synchronization practices in professional > audio-visual production and exhibition. It is intended to initiate > a discussion which may result in new or modified IETF standards > which address the needs of this field. > We encourage you to read and comment on the issues raised by this draft, > since it is desirable that RTP can be used for studio quality audio/video. > > We note that we have completed the vast majority of our milestones, and > that it is time to recharter (the current charter, goals and milestones > are available from http://www.ietf.org/html.charters/avt-charter.html) > > What are the next steps for the AVT working group? In the short term, we > need to finish the MPEG-4 and multiplexing (TCRTP) work which is on our > current charter, then write the existing work into the charter along with > milestones for completion (i.e. SRTP, unicast RTCP, RTCP feedback, RTCP-based > retransmission, ULP/UXP, AMR, EVRC, Vorbis). Longer term, once RTP is a > draft standard, we need to advance the proposed standard payload formats - > which ones? - and guide development of new payload formats. > > We propose the following new charter: > > The Audio/Video Transport Working Group was formed to specify a > protocol for real-time transmission of audio and video over UDP and > IP multicast. This is the Real-time Transport Protocol, RTP, > together with its associated profile for audio/video conferences > and payload format documents. > > The current goals of the working group are to complete the revision > of RTP and the audio/video profile for draft standard, to review > the existing payload formats to determine which of those are > suitable for advancement to draft standard, to develop new RTP > profiles relating to security, unicast feedback, and unicast RTCP, > and to guide development of new payload formats. > > Regarding milestones, we propose to issue WG last call on: > - RTP Testing Strategies (draft-ietf-avt-rtptest-04.txt) > - Comfort Noise payload (draft-ietf-avt-rtp-cn-01.txt) > in the next few days. We will also submit a revision to the MIME > registration draft and request IESG last call on: > - MIME registrations (draft-ietf-avt-rtp-mime-05.txt) > - SDP RTCP BW modifiers (draft-ietf-avt-rtcp-bw-03.txt) > We propose to send the RTP specification and audio/video profile to the > area director for review in the next few days, for eventual publication > as a proposed standard. > > Proposed milestones, for completion in Apr/May: > - AMR payload format to proposed standard > - CRTP to draft standard > - CRTP enhancements to proposed standard and TCRTP to BCP > - Combine RTCP feedback drafts to form a new profile > - Resolve ULP/UXP choice (send both to proposed, or chose one?) > > Proposed milestones, for completion by the London meeting: > - RTP payload format for MPEG-4 multiple SL > - RTP payload format for EVRC > - RTP payload format for Vorbis > - RTCP feedback profile to proposed/experimental (depending on congestion > control results) > - RTP payload format for Selective retransmission > - Complete Unicast RTCP profile, start performance simulations > - Secure RTP profile to proposed standard > - ULP/UXP to proposed standard > > Proposed milestones, for completion by the Salt Lake City meeting: > - Unicast RTCP profile to proposed > - RTP payload format for MPEG-4 FlexMux to proposed standard > > We also need to advance the current proposed standard payload formats, and > other documents, to draft standard. At present, those eligible include: > - H.261 - Redundant audio > - CellB - Generic FEC > - H.263, H.263+ - Text conversation > - MPEG - DTMF > - Bundled MPEG - Real time pointers > - BT.656 - MIB > - JPEG > Volunteers are solicited to work on revising these ready for draft standard. > Opinions on which are suitable for draft standard, which should remain at > proposed, which should be declared historic are solicited. > > Comments and suggestions are welcome. > > Colin and Steve From rem-conf Wed Apr 11 13:42:49 2001 From rem-conf-request@es.net Wed Apr 11 13:42:48 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nRFD-0001RK-00; Wed, 11 Apr 2001 13:29:39 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nRFB-0001RA-00; Wed, 11 Apr 2001 13:29:37 -0700 Received: from topaz.3com.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 11 Apr 2001 13:29:36 -0700 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3BKS0a25631 for ; Wed, 11 Apr 2001 13:28:00 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f3BKTZ723462 for ; Wed, 11 Apr 2001 13:29:35 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A2B.0070900A ; Wed, 11 Apr 2001 13:29:29 -0700 X-Lotus-FromDomain: 3COM From: James_Renkel@3com.com To: rem-conf@es.net Message-ID: <88256A2B.00708D21.00@hqoutbound.ops.3com.com> Date: Wed, 11 Apr 2001 15:29:21 -0500 Subject: Re: Other work/charter update Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All, TIA committee TR-30.1 (modems) and ITU-T SG16 / WP1 / Q11 are working jointly on a concept called "modem over IP" (MoIP), to complement voice over IP (VoIP) and facsimile over IP (FoIP). I won't take the time here now to try to explain this work, but will if anybody requests that. One option that we are looking at is the use of RFC 2833 to code modem events and signals, if not when in MoIP mode then at least during the transition from VoIP mode to MoIP mode. As part of the work in developing a so-called V.moip draft recommendation, we are cataloging all such modem events and signals that would need representation in RFC 2833. We have already found several deficiencies with the existing RFC 2833 (Although those deficiencies are perhaps more appropriately addressed by a BCP than an RFC 2833 revision.), and some new events and signals that have been added to ITU-T V series modem recommendations since the last revision of RFC 2833 (For example, the ANSpcm signal that is required for some V.92 connections.). We were planning on submitting an I-D at the appropriate time (i.e., when we've finally figured it all out :-) ) of a revision to RFC 2833, and possibly a BCP for using RFC 2833 modem events and signals (Trust us: it ain't obvious. one of the "examples" or hints in RFC 2833 is flat out wrong and would lead to the modems never connecting!) If these contributions are not done collectively by the TR-30.1 and ITU-T SG16 / WP1 /Q11 committee, then CommWorks will do it as an individual company, perhaps jointly with others. My question to this mailing list is: What is the appropriate way to mesh this work we're doing with the other revisions to RFC 2833 that are being discussed? We are modem experts and have some skill in dealing with the TIA and ITU-T organizations, but are probably naive at best when it comes to IETF procedures. We are looking for guidance here. The MoIP committee is also very interested in the forward error correction and retransmission "schemes" for RTP (MoIP probably will require RTP delivery reliability akin to that of TCP, without some of its drawbacks, e.g., the so-called "head-of-line" issue.). Therefore, IMHO, no, we don't want to use (only) TCP for MoIP. I believe others in the committe may have different opinions on this, as we haven't yet settled on this. I assume we will raise our concerns with the FEC and retransmission schemes with this mailing list, and propose some things. Is there anything else we should be doing? Any comments and suggestions would be most welcome. Jim Renkel Director, Advanced Technology & System Engineering The CommWorks Corp., a 3Com company formerly the 3Com Carrier Networks Business "Rex Coldren" on 04/11/2001 12:58:05 PM Please respond to coldrenr@agcs.com Sent by: "Rex Coldren" To: Colin Perkins cc: rem-conf@es.net (James Renkel/MW/US/3Com) Subject: Re: Other work/charter update For the ABCD trunking events, which are likely to run into the duration problem periodically, the duration field probably is not very important. We have the timestamp, which indicates the start time of the event in every event packet that repeats the same event. And we also have the sequence number. The duration field would be largely ignored by implementations other than for having to set it to something that is RFC 2833 compliant. For the ABCD event application it would be acceptable to allow the duration field to be treated as an unsigned integer and just allow it to wrap around. Alternatively, allowing a value of zero to be used if duration is to be ignored would be a simpler and less expensive thing to do. We look forward to Henning's ID. Rex Colin Perkins wrote: > Folks, > > There have been a number of areas where progress has occured since the last > meeting, but which were not discussed in the AVT meeting yesterday. These > include: RFC 2833 errata, payload formats for meta-information, and the new > draft on precision audio/video. In addition, we need to re-charter the AVT > working group. > > Regarding RFC 2833 errata, we note the following: > - The MF S1...S3 codes have two code points, but need three. We > agreed, on the mailing list, to deprecate codes 142 and 143, > and assign new numbers. > - We may need to add a channel failure event to signal E1 loss of > frame > - What is the procedure for events longer than those which can be > represented in the duration field? Are continuation packets > acceptable? > Henning Schulzrinne will produce an updated draft addressing these issues. > > At the San Diego meeting, two payloads for meta-information were presented. > The authors have been working on this since then, and believe it makes > sense to focus on a common (payload independent) set of mechanisms for > indicating and communicating metadata associated with RTP streams. For > example: > - announcing sessions with associated metadata (SDP) > - requesting streams with associated metadata (RTSP) > - specifying the communication of metadata (in-band vs. > out-of-band, separate metadata stream vs. mixed media/meta-data > stream) > Subsequent to that, they will consider the matter of payload format(s) > themselves. We expect to see an update in future. > > Chuck Harrison submitted a new draft on precision audio/video > (draft-harrison-avt-precision-av-00.txt). The abstract reads: > This memo discusses methods for transporting audio-visual content > over the Internet while meeting professional-quality temporal > performance. This memo gives information about the timing > requirements and synchronization practices in professional > audio-visual production and exhibition. It is intended to initiate > a discussion which may result in new or modified IETF standards > which address the needs of this field. > We encourage you to read and comment on the issues raised by this draft, > since it is desirable that RTP can be used for studio quality audio/video. > > We note that we have completed the vast majority of our milestones, and > that it is time to recharter (the current charter, goals and milestones > are available from http://www.ietf.org/html.charters/avt-charter.html) > > What are the next steps for the AVT working group? In the short term, we > need to finish the MPEG-4 and multiplexing (TCRTP) work which is on our > current charter, then write the existing work into the charter along with > milestones for completion (i.e. SRTP, unicast RTCP, RTCP feedback, RTCP-based > retransmission, ULP/UXP, AMR, EVRC, Vorbis). Longer term, once RTP is a > draft standard, we need to advance the proposed standard payload formats - > which ones? - and guide development of new payload formats. > > We propose the following new charter: > > The Audio/Video Transport Working Group was formed to specify a > protocol for real-time transmission of audio and video over UDP and > IP multicast. This is the Real-time Transport Protocol, RTP, > together with its associated profile for audio/video conferences > and payload format documents. > > The current goals of the working group are to complete the revision > of RTP and the audio/video profile for draft standard, to review > the existing payload formats to determine which of those are > suitable for advancement to draft standard, to develop new RTP > profiles relating to security, unicast feedback, and unicast RTCP, > and to guide development of new payload formats. > > Regarding milestones, we propose to issue WG last call on: > - RTP Testing Strategies (draft-ietf-avt-rtptest-04.txt) > - Comfort Noise payload (draft-ietf-avt-rtp-cn-01.txt) > in the next few days. We will also submit a revision to the MIME > registration draft and request IESG last call on: > - MIME registrations (draft-ietf-avt-rtp-mime-05.txt) > - SDP RTCP BW modifiers (draft-ietf-avt-rtcp-bw-03.txt) > We propose to send the RTP specification and audio/video profile to the > area director for review in the next few days, for eventual publication > as a proposed standard. > > Proposed milestones, for completion in Apr/May: > - AMR payload format to proposed standard > - CRTP to draft standard > - CRTP enhancements to proposed standard and TCRTP to BCP > - Combine RTCP feedback drafts to form a new profile > - Resolve ULP/UXP choice (send both to proposed, or chose one?) > > Proposed milestones, for completion by the London meeting: > - RTP payload format for MPEG-4 multiple SL > - RTP payload format for EVRC > - RTP payload format for Vorbis > - RTCP feedback profile to proposed/experimental (depending on congestion > control results) > - RTP payload format for Selective retransmission > - Complete Unicast RTCP profile, start performance simulations > - Secure RTP profile to proposed standard > - ULP/UXP to proposed standard > > Proposed milestones, for completion by the Salt Lake City meeting: > - Unicast RTCP profile to proposed > - RTP payload format for MPEG-4 FlexMux to proposed standard > > We also need to advance the current proposed standard payload formats, and > other documents, to draft standard. At present, those eligible include: > - H.261 - Redundant audio > - CellB - Generic FEC > - H.263, H.263+ - Text conversation > - MPEG - DTMF > - Bundled MPEG - Real time pointers > - BT.656 - MIB > - JPEG > Volunteers are solicited to work on revising these ready for draft standard. > Opinions on which are suitable for draft standard, which should remain at > proposed, which should be declared historic are solicited. > > Comments and suggestions are welcome. > > Colin and Steve From rem-conf Wed Apr 11 19:16:30 2001 From rem-conf-request@es.net Wed Apr 11 19:16:29 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nWU7-00044G-00; Wed, 11 Apr 2001 19:05:23 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nWU5-000446-00; Wed, 11 Apr 2001 19:05:21 -0700 Received: from cs.columbia.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 11 Apr 2001 19:05:20 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA03700; Wed, 11 Apr 2001 22:05:18 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3AD50D5E.5D24D0EA@cs.columbia.edu> Date: Wed, 11 Apr 2001 22:05:18 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James_Renkel@3com.com CC: rem-conf@es.net Subject: Re: Other work/charter update References: <88256A2B.00708D21.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list James_Renkel@3com.com wrote: > > All, > > TIA committee TR-30.1 (modems) and ITU-T SG16 / WP1 / Q11 are working jointly > on a concept called "modem over IP" (MoIP), to complement voice over IP (VoIP) > and facsimile over IP (FoIP). I won't take the time here now to try to explain > this work, but will if anybody requests that. > > One option that we are looking at is the use of RFC 2833 to code modem events > and signals, if not when in MoIP mode then at least during the transition from > VoIP mode to MoIP mode. As part of the work in developing a so-called V.moip > draft recommendation, we are cataloging all such modem events and signals that > would need representation in RFC 2833. We have already found several > deficiencies > with the existing RFC 2833 (Although those deficiencies are perhaps more > appropriately addressed by a BCP than an RFC 2833 revision.), and some new However, RFC 2833 will be revised as it progress from Proposed to Draft Standard, so I would certainly appreciate if you could send me any suggestions for clarifying text or bug fixes. I don't claim to be a modem expert and thus have to rely on external experts to review material and catch mistakes. > events > and signals that have been added to ITU-T V series modem recommendations since > the last revision of RFC 2833 (For example, the ANSpcm signal that is required > for some V.92 connections.). Again, text and suggestions are most welcome. > > We were planning on submitting an I-D at the appropriate time (i.e., when we've > finally figured it all out :-) ) of a revision to RFC 2833, and possibly a BCP > for using RFC 2833 modem events and signals (Trust us: it ain't obvious. one of > the "examples" or hints in RFC 2833 is flat out wrong and would lead to the > modems > never connecting!) If these contributions are not done collectively by the Please let me know which one. > TR-30.1 > and ITU-T SG16 / WP1 /Q11 committee, then CommWorks will do it as an individual > company, perhaps jointly with others. > > My question to this mailing list is: What is the appropriate way to mesh this > work > we're doing with the other revisions to RFC 2833 that are being discussed? We Easy: just send text to me. I'll fold them into the upcoming rfc2833bis draft(s). The drafts can then be reviewed by the community at large to make sure mistakes are minimized. The last time around, it was really difficult to get any feedback, so I look forward to having you (and others on the TIA/ITU-T committee) contribute to the next revision. > are > modem experts and have some skill in dealing with the TIA and ITU-T > organizations, > but are probably naive at best when it comes to IETF procedures. We are looking > for > guidance here. > > The MoIP committee is also very interested in the forward error correction and > retransmission "schemes" for RTP (MoIP probably will require RTP delivery > reliability akin to that of TCP, without some of its drawbacks, e.g., the > so-called > "head-of-line" issue.). Therefore, IMHO, no, we don't want to use (only) TCP for > > MoIP. I believe others in the committe may have different opinions on this, as > we > haven't yet settled on this. I assume we will raise our concerns with the FEC > and > retransmission schemes with this mailing list, and propose some things. Is there > > anything else we should be doing? SCTP might be a reasonable option. RTP will run over that, too, if needed. > > Any comments and suggestions would be most welcome. > > Jim Renkel > Director, Advanced Technology & System Engineering > The CommWorks Corp., a 3Com company > formerly the 3Com Carrier Networks Business > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 11 19:53:27 2001 From rem-conf-request@es.net Wed Apr 11 19:53:27 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nX5H-00050r-00; Wed, 11 Apr 2001 19:43:47 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nX5G-00050h-00; Wed, 11 Apr 2001 19:43:46 -0700 Received: from canospam.agcs.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 11 Apr 2001 19:43:45 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id TAA07475 for ; Wed, 11 Apr 2001 19:43:44 -0700 (MST) Posted-Date: Wed, 11 Apr 2001 19:43:44 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Apr 11 19:43:41 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id TAA11562 for ; Wed, 11 Apr 2001 19:43:22 -0700 (MST) Received: from agcs.com ([130.131.56.175]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA6C1A; Wed, 11 Apr 2001 19:43:42 -0700 Message-ID: <3AD51638.41C4A2A0@agcs.com> Date: Wed, 11 Apr 2001 19:43:05 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: James_Renkel@3com.com, rem-conf@es.net Subject: Re: Other work/charter update References: <88256A2B.00708D21.00@hqoutbound.ops.3com.com> <3AD50D5E.5D24D0EA@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning, Can you respond to the original questions in this thread? I'll repeat them below. I think they got lost in the tangential modem relay response to my original response to Colin's update... Thanks, Rex SNIP from the original response >>>>>>>>>>>>>>>>>>>>>>> For the ABCD trunking events, which are likely to run into the duration problem periodically, the duration field probably is not very important. We have the timestamp, which indicates the start time of the event in every event packet that repeats the same event. And we also have the sequence number. The duration field would be largely ignored by implementations other than for having to set it to something that is RFC 2833 compliant. For the ABCD event application it would be acceptable to allow the duration field to be treated as an unsigned integer and just allow it to wrap around. Alternatively, allowing a value of zero to be used if duration is to be ignored would be a simpler and less expensive thing to do. We look forward to Henning's ID. SNIP from original response >>>>>>>>>>>>>>>>>>>>>>>>> "Henning G. Schulzrinne" wrote: > James_Renkel@3com.com wrote: > > > > All, > > > > TIA committee TR-30.1 (modems) and ITU-T SG16 / WP1 / Q11 are working jointly > > on a concept called "modem over IP" (MoIP), to complement voice over IP (VoIP) > > and facsimile over IP (FoIP). I won't take the time here now to try to explain > > this work, but will if anybody requests that. > > > > One option that we are looking at is the use of RFC 2833 to code modem events > > and signals, if not when in MoIP mode then at least during the transition from > > VoIP mode to MoIP mode. As part of the work in developing a so-called V.moip > > draft recommendation, we are cataloging all such modem events and signals that > > would need representation in RFC 2833. We have already found several > > deficiencies > > with the existing RFC 2833 (Although those deficiencies are perhaps more > > appropriately addressed by a BCP than an RFC 2833 revision.), and some new > > However, RFC 2833 will be revised as it progress from Proposed to Draft > Standard, so I would certainly appreciate if you could send me any > suggestions for clarifying text or bug fixes. I don't claim to be a > modem expert and thus have to rely on external experts to review > material and catch mistakes. > > > events > > and signals that have been added to ITU-T V series modem recommendations since > > the last revision of RFC 2833 (For example, the ANSpcm signal that is required > > for some V.92 connections.). > > Again, text and suggestions are most welcome. > > > > > We were planning on submitting an I-D at the appropriate time (i.e., when we've > > finally figured it all out :-) ) of a revision to RFC 2833, and possibly a BCP > > for using RFC 2833 modem events and signals (Trust us: it ain't obvious. one of > > the "examples" or hints in RFC 2833 is flat out wrong and would lead to the > > modems > > never connecting!) If these contributions are not done collectively by the > > Please let me know which one. > > > TR-30.1 > > and ITU-T SG16 / WP1 /Q11 committee, then CommWorks will do it as an individual > > company, perhaps jointly with others. > > > > My question to this mailing list is: What is the appropriate way to mesh this > > work > > we're doing with the other revisions to RFC 2833 that are being discussed? We > > Easy: just send text to me. I'll fold them into the upcoming rfc2833bis > draft(s). The drafts can then be reviewed by the community at large to > make sure mistakes are minimized. The last time around, it was really > difficult to get any feedback, so I look forward to having you (and > others on the TIA/ITU-T committee) contribute to the next revision. > > > are > > modem experts and have some skill in dealing with the TIA and ITU-T > > organizations, > > but are probably naive at best when it comes to IETF procedures. We are looking > > for > > guidance here. > > > > > The MoIP committee is also very interested in the forward error correction and > > retransmission "schemes" for RTP (MoIP probably will require RTP delivery > > reliability akin to that of TCP, without some of its drawbacks, e.g., the > > so-called > > "head-of-line" issue.). Therefore, IMHO, no, we don't want to use (only) TCP for > > > > MoIP. I believe others in the committe may have different opinions on this, as > > we > > haven't yet settled on this. I assume we will raise our concerns with the FEC > > and > > retransmission schemes with this mailing list, and propose some things. Is there > > > > anything else we should be doing? > > SCTP might be a reasonable option. RTP will run over that, too, if > needed. > > > > > Any comments and suggestions would be most welcome. > > > > Jim Renkel > > Director, Advanced Technology & System Engineering > > The CommWorks Corp., a 3Com company > > formerly the 3Com Carrier Networks Business > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 11 21:20:10 2001 From rem-conf-request@es.net Wed Apr 11 21:20:09 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nYSE-0006LU-00; Wed, 11 Apr 2001 21:11:34 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nYSC-0006LK-00; Wed, 11 Apr 2001 21:11:32 -0700 Received: from purple.east.isi.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 11 Apr 2001 21:11:31 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA00881 for ; Thu, 12 Apr 2001 00:11:28 -0400 Message-Id: <200104120411.AAA00881@purple.east.isi.edu> To: rem-conf@es.net Subject: AVT presentation slides from Minneapolis Date: Thu, 12 Apr 2001 00:11:28 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A reminder that those who presented in Minneapolis should send me copies of your slides, for inclusion in the minutes. Colin From rem-conf Thu Apr 12 01:11:18 2001 From rem-conf-request@es.net Thu Apr 12 01:11:17 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nc7J-00019F-00; Thu, 12 Apr 2001 01:06:13 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nc7H-000195-00; Thu, 12 Apr 2001 01:06:11 -0700 Received: from mx2.ust.hk ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 01:06:10 -0700 Received: from smtp.ust.hk (smtp.ust.hk [143.89.14.35]) by mx2.ust.hk (8.11.0/8.11.0) with ESMTP id f3C836I28412 for ; Thu, 12 Apr 2001 16:03:06 +0800 Received: from dmg246 (dmg246.resnet.ust.hk [143.89.156.246]) by smtp.ust.hk (8.11.0/8.11.0) with SMTP id f3C846M16086 for ; Thu, 12 Apr 2001 16:04:06 +0800 (HKT) Message-Id: <200104120804.f3C846M16086@smtp.ust.hk> Date: Thu, 12 Apr 2001 16:5:30 +0800 From: Rito Ljc Reply-To: csljc@ust.hk To: "rem-conf@es.net" Subject: RTT estimation for multicast Organization: UST X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can any one give some directions on how to efficiently estimate Round-trip time for each receivers in a mulciast environment. Thanks From rem-conf Thu Apr 12 01:36:33 2001 From rem-conf-request@es.net Thu Apr 12 01:36:32 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14ncXn-00024P-00; Thu, 12 Apr 2001 01:33:35 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14ncXl-00024F-00; Thu, 12 Apr 2001 01:33:33 -0700 Received: from mail.noos.fr ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 01:33:33 -0700 Received: (qmail 6731722 invoked by uid 0); 12 Apr 2001 08:33:31 -0000 Received: from d024.dhcp212-198-210.noos.fr (HELO KAVEMAISON) ([212.198.210.24]) (envelope-sender ) by verlaine.noos.net (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 08:33:31 -0000 Reply-To: From: "=?GB2312?B?S2F2qKYgU2FsYW1hdGlhbg==?=" To: , Subject: RE: RTT estimation for multicast Date: Thu, 12 Apr 2001 10:36:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200104120804.f3C846M16086@smtp.ust.hk> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, there is two main work on this subject: 1- A paper by D. Sisalem about MLDA (see http://citeseer.nj.nec.com/sisalem00mlda.html) 2- A paper by Golestani (see http://citeseer.nj.nec.com/context/947803/0 ) Good Luck Kv -----Original Message----- From: Rito Ljc [mailto:csljc@ust.hk] Sent: jeu. 12 avril 2001 10:01 To: rem-conf@es.net Subject: RTT estimation for multicast Can any one give some directions on how to efficiently estimate Round-trip time for each receivers in a mulciast environment. Thanks From rem-conf Thu Apr 12 03:50:01 2001 From rem-conf-request@es.net Thu Apr 12 03:50:00 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nedx-0003cg-00; Thu, 12 Apr 2001 03:48:05 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nedw-0003cW-00; Thu, 12 Apr 2001 03:48:04 -0700 Received: from web-2.star2.net ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 03:48:03 -0700 Received: from 21rst-century.com (1Cust116.tnt2.lorton.va.da.uu.net [63.23.103.116]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 12 Apr 2001 06:58:10 -0400 Message-ID: <3AD58830.1B04CA5@21rst-century.com> Date: Thu, 12 Apr 2001 06:49:19 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: csljc@ust.hk CC: "rem-conf@es.net" Subject: Re: RTT estimation for multicast References: <200104120804.f3C846M16086@smtp.ust.hk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Use RTCP. Remember, you do NOT need to know anything about the receiver's clock to estimate a RTT. >From draft-ietf-avt-rtp-new-09.txt (from section 4) Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [11]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently. and (From 6.4.1) Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this reception report block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as (A- LSR - DLSR). This is illustrated in Fig. 2. Remember, though, that in the real Internet multicast routing will frequently be asymmetric, and will commonly be different than for unicast traffic, which might cause problems depending on what you want to do. Rito Ljc wrote: > > Can any one give some directions on how to efficiently estimate Round-trip time > for each receivers in a mulciast environment. > > Thanks -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 04:18:59 2001 From rem-conf-request@es.net Thu Apr 12 04:18:58 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nf6E-0004b8-00; Thu, 12 Apr 2001 04:17:18 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nf6D-0004ay-00; Thu, 12 Apr 2001 04:17:17 -0700 Received: from mail.noos.fr ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 04:17:16 -0700 Received: (qmail 2481230 invoked by uid 0); 12 Apr 2001 11:17:15 -0000 Received: from d024.dhcp212-198-210.noos.fr (HELO perse) ([212.198.210.24]) (envelope-sender ) by zola.noos.net (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 11:17:15 -0000 From: =?US-ASCII?Q?Kave_Salamatian?= To: , Cc: Subject: RE: RTT estimation for multicast Date: Thu, 12 Apr 2001 13:16:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3AD58830.1B04CA5@21rst-century.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Sorry to contradict you Marshall. But RTT estimation in the multicast channel is not as easy because of the feedback implosion problem. The two paper I mention before explain why and give some solution. The MLDA approach need clock synchronisation (or at least realtime online clock skew estimation) but the Golestani approach distribute the rtt calculation over the multicast tree. if you want to use rtt for TCP friendly rate adaptation you should go through the above mentionned process and the approach suggested by you is not sufficient as it will generate too spaced rtt estimates. Regards Kv -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: jeudi 12 avril 2001 12:49 To: csljc@ust.hk Cc: rem-conf@es.net Subject: Re: RTT estimation for multicast Use RTCP. Remember, you do NOT need to know anything about the receiver's clock to estimate a RTT. >From draft-ietf-avt-rtp-new-09.txt (from section 4) Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [11]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently. and (From 6.4.1) Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this reception report block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as (A- LSR - DLSR). This is illustrated in Fig. 2. Remember, though, that in the real Internet multicast routing will frequently be asymmetric, and will commonly be different than for unicast traffic, which might cause problems depending on what you want to do. Rito Ljc wrote: > > Can any one give some directions on how to efficiently estimate Round-trip time > for each receivers in a mulciast environment. > > Thanks -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 05:42:36 2001 From rem-conf-request@es.net Thu Apr 12 05:42:35 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14ngOx-0006Ax-00; Thu, 12 Apr 2001 05:40:43 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14ngOv-0006An-00; Thu, 12 Apr 2001 05:40:41 -0700 Received: from web-2.star2.net ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 05:40:40 -0700 Received: from 21rst-century.com (1Cust116.tnt2.lorton.va.da.uu.net [63.23.103.116]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 12 Apr 2001 08:50:46 -0400 Message-ID: <3AD5A268.3BFD6C59@21rst-century.com> Date: Thu, 12 Apr 2001 08:41:12 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Kave Salamatian CC: csljc@ust.hk, rem-conf@es.net Subject: Re: RTT estimation for multicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Kave; 1.) I think that the ACK implosion problem is much over-rated in the current Internet, although RTCP needs to be modified for SSM and for very large groups. I do not know what Rito Ljc wants to do, so it is hard to figure out what RTT update rate he desires. For our case, if we had a million listeners, we would (in our SSM RTCP implementation) be receiving about 20 megabits per second of receiver reports back to us. Although that sounds like a high data rate, it amounts to a cost of about 0.1% of revenue for that case, which would easily be affordable (assuming 1 million receivers). You have to modify the protocol a little, but having these kinds of data rates are not really a problem today. 2.) Is either the MLDA approach or the Golestani approach implemented anywhere ? You can use RTCP compliant receivers to estimate RTT now. 3.) I am sorry, but using the actual RTT to calculate the desired rate for multicast congestion control doesn't really make any sense to me. Multicast is one way, and the notion of filling up the pipe to maximize the transmission of data between ACKs just doesn't apply. (Some NAK based schemes might be counter examples here.) The real reason RTT is used in multicast CC seems to be just to mimic the TCP average throughput using Padhye's equation or something similar, where throughput is inversely proportional to the RTT. This can lead to strange results in the real world. Suppose you use a satellite link to distribute multicast data to remote POP's, where it is sent out to receivers. The RTT will include the 80,000 kilometers of satellite path up and down, and so will be at least 250 milliseconds one way. Suppose that the ground based RTT to a receiver was 50 milliseconds (25 each way), so that the satellite based RTT will be 275 milliseconds, vs 50 for the ground based, or a factor of 5.5. If this satellite link was being used for multicast only, to avoid congesting the commodity Internet, is it really fair to penalize it by a factor of 5 in its "fair" bandwidth usage? Yes, to do standard TCP over a satellite link without TCP tuning may be inefficient, but should that inefficiency be imposed on satellite multicasts when there is no TCP over that link ? My personal opinion is that multicast congestion control is really a hard problem, and likely to require operational feedback before it really works well. (The same was true with TCP, by the way.) "Fairness" seems to me to be an ill-posed problem for multicast, but "don't break the network" is a well posed problem that I do not think is solved for multicast, but could be. I worry that just trying to emulate TCP throughput will prove to be a dead-end, and will detract from solving the more basic problem of trying to keep growth in multicast traffic from breaking things in the network. Regards Marshall Kave Salamatian wrote: > > Hi, > > Sorry to contradict you Marshall. But RTT estimation in the multicast > channel is not as easy because of the feedback implosion problem. The two > paper I mention before explain why and give some solution. The MLDA approach > need clock synchronisation (or at least realtime online clock skew > estimation) but the Golestani approach distribute the rtt calculation over > the multicast tree. > > if you want to use rtt for TCP friendly rate adaptation you should go > through the above mentionned process and the approach suggested by you is > not sufficient as it will generate too spaced rtt estimates. > > Regards > > Kv > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: jeudi 12 avril 2001 12:49 > To: csljc@ust.hk > Cc: rem-conf@es.net > Subject: Re: RTT estimation for multicast > > Use RTCP. Remember, you do NOT need to know > anything about the receiver's clock to estimate a RTT. > > >From draft-ietf-avt-rtp-new-09.txt > > (from section 4) > > Wallclock time (absolute date and time) is represented using the > timestamp format of the Network Time Protocol (NTP), which is in > seconds relative to 0h UTC on 1 January 1900 [11]. The full > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > the integer part in the first 32 bits and the fractional part in the > last 32 bits. In some fields where a more compact representation is > appropriate, only the middle 32 bits are used; that is, the low 16 > bits of the integer part and the high 16 bits of the fractional part. > The high 16 bits of the integer part must be determined > independently. > > and (From 6.4.1) > > Let SSRC_r denote the receiver issuing this receiver > report. Source SSRC_n can compute the round-trip > propagation delay to SSRC_r by recording the time A when > this reception report block is received. It calculates the > total round-trip time A-LSR using the last SR timestamp > (LSR) field, and then subtracting this field to leave the > round-trip propagation delay as (A- LSR - DLSR). This is > illustrated in Fig. 2. > > Remember, though, that in the real Internet multicast routing will > frequently be asymmetric, and > will commonly be different than for unicast traffic, which might cause > problems depending > on what you want to do. > > Rito Ljc wrote: > > > > Can any one give some directions on how to efficiently estimate Round-trip > time > > for each receivers in a mulciast environment. > > > > Thanks > > -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 06:33:52 2001 From rem-conf-request@es.net Thu Apr 12 06:33:51 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nhCr-0007kw-00; Thu, 12 Apr 2001 06:32:17 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nhCq-0007km-00; Thu, 12 Apr 2001 06:32:16 -0700 Received: from max5.rrze.uni-erlangen.de ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 06:32:10 -0700 Received: from lisa.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP; Thu, 12 Apr 2001 15:32:09 +0200 Received: from localhost by lisa (8.9.3+Sun/cl-RRZE) id PAA17588; Thu, 12 Apr 2001 15:32:08 +0200 (MET DST) Date: Thu, 12 Apr 2001 15:32:08 +0200 (MET DST) From: Falko Dressler To: Marshall Eubanks cc: rem-conf@es.net, salamat@rp.lip6.Fr Subject: Re: RTT estimation for multicast In-Reply-To: <3AD5A268.3BFD6C59@21rst-century.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Marshall, I do think that you are right, but you have to distinguish between (1) online congestion control for a particular application and (2) 'offline' QoS measurement for (a part of) the internet. The first one can be done using the RTP/RTCP protocol (maybe including some enhancements). Not yet implemented is the much more meaningful measurement of the one-way delay. The second one is more useful for the providers of a network service. There are some first ideas / implementations to provide information about the current state (reliability and QoS) of an IP multicast network: the MRM (Multicast Reachability Monitor, IETF draft) and an advancement, the MQM (Multicast Quality Monitor, to be published soon). I don't think, that the are real problems to scale for (1). But there are such problems for (2), which can only be solved by intelligent selecting the interesting parts of the network to survey. Best wishes, Falko. On Thu, 12 Apr 2001, Marshall Eubanks wrote: > Date: Thu, 12 Apr 2001 08:41:12 -0400 > From: Marshall Eubanks > To: Kave Salamatian rem-conf@es.net rem-conf@es.net > Subject: Re: RTT estimation for multicast > > Hello Kave; > > 1.) I think that the ACK implosion problem is much over-rated in the current > Internet, although RTCP needs to be modified for SSM and for very > large groups. I do not know what Rito Ljc wants to do, so it > is hard to figure out what RTT update rate he desires. > > For our case, if we had a million listeners, we would (in our SSM RTCP > implementation) be receiving about 20 megabits per second of receiver > reports back to us. Although that sounds like a high data rate, > it amounts to a cost of about 0.1% of revenue for that case, which > would easily be affordable (assuming 1 million receivers). You have > to modify the protocol a little, but having these kinds of data > rates are not really a problem today. > > 2.) Is either the MLDA approach or the Golestani approach implemented anywhere ? > You can use RTCP compliant receivers to estimate RTT now. > > 3.) I am sorry, but using the actual RTT to calculate the desired rate > for multicast congestion control doesn't really make any sense to me. Multicast > is one way, and the notion of filling up the pipe to maximize the > transmission of data between ACKs just doesn't apply. (Some NAK based schemes > might be counter examples here.) > > The real reason RTT is used in multicast CC seems to be just to mimic the TCP average throughput using Padhye's > equation or something similar, where throughput is inversely proportional to > the RTT. This can lead to strange results in the real world. > > Suppose you use a satellite link to distribute multicast data to remote > POP's, where it is sent out to receivers. The RTT will include the 80,000 > kilometers of satellite path up and down, and so will be at least 250 milliseconds one way. > Suppose that the ground based RTT to a receiver was 50 milliseconds (25 each way), > so that the satellite based RTT will be 275 milliseconds, vs 50 for the ground based, or > a factor of 5.5. > > If this satellite link was being used for multicast only, to avoid congesting the commodity Internet, > is it really fair to penalize it by a factor of 5 in its "fair" bandwidth usage? > Yes, to do standard TCP over a satellite link without TCP tuning may be inefficient, > but should that inefficiency be imposed on satellite multicasts when there is no TCP > over that link ? > > My personal opinion is that multicast congestion control is really a hard problem, and > likely to require operational feedback before it really works well. (The same was > true with TCP, by the way.) "Fairness" seems to me to be an ill-posed problem for multicast, > but "don't break the network" is a well posed problem that I do not think is solved > for multicast, but could be. I worry that just trying to emulate TCP throughput > will prove to be a dead-end, and will detract from solving the more basic problem > of trying to keep growth in multicast traffic from breaking things in the network. > > Regards > Marshall > > > Kave Salamatian wrote: > > > > Hi, > > > > Sorry to contradict you Marshall. But RTT estimation in the multicast > > channel is not as easy because of the feedback implosion problem. The two > > paper I mention before explain why and give some solution. The MLDA approach > > need clock synchronisation (or at least realtime online clock skew > > estimation) but the Golestani approach distribute the rtt calculation over > > the multicast tree. > > > > if you want to use rtt for TCP friendly rate adaptation you should go > > through the above mentionned process and the approach suggested by you is > > not sufficient as it will generate too spaced rtt estimates. > > > > Regards > > > > Kv > > > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@21rst-century.com] > > Sent: jeudi 12 avril 2001 12:49 > > To: csljc@ust.hk > > Cc: rem-conf@es.net > > Subject: Re: RTT estimation for multicast > > > > Use RTCP. Remember, you do NOT need to know > > anything about the receiver's clock to estimate a RTT. > > > > >From draft-ietf-avt-rtp-new-09.txt > > > > (from section 4) > > > > Wallclock time (absolute date and time) is represented using the > > timestamp format of the Network Time Protocol (NTP), which is in > > seconds relative to 0h UTC on 1 January 1900 [11]. The full > > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > > the integer part in the first 32 bits and the fractional part in the > > last 32 bits. In some fields where a more compact representation is > > appropriate, only the middle 32 bits are used; that is, the low 16 > > bits of the integer part and the high 16 bits of the fractional part. > > The high 16 bits of the integer part must be determined > > independently. > > > > and (From 6.4.1) > > > > Let SSRC_r denote the receiver issuing this receiver > > report. Source SSRC_n can compute the round-trip > > propagation delay to SSRC_r by recording the time A when > > this reception report block is received. It calculates the > > total round-trip time A-LSR using the last SR timestamp > > (LSR) field, and then subtracting this field to leave the > > round-trip propagation delay as (A- LSR - DLSR). This is > > illustrated in Fig. 2. > > > > Remember, though, that in the real Internet multicast routing will > > frequently be asymmetric, and > > will commonly be different than for unicast traffic, which might cause > > problems depending > > on what you want to do. > > > > Rito Ljc wrote: > > > > > > Can any one give some directions on how to efficiently estimate Round-trip > > time > > > for each receivers in a mulciast environment. > > > > > > Thanks > > > > -- > > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > > Test your network for multicast : http://www.multicasttech.com/mt/ > -- Falko Dressler Universitaet Erlangen-Nuernberg, RRZE EMail: Falko.Dressler@rrze.uni-erlangen.de Tel: +49 9131 85-27802 / Fax: +49 9131 302941 WWW: http://bsd.rrze.uni-erlangen.de/~fd/ From rem-conf Thu Apr 12 07:21:03 2001 From rem-conf-request@es.net Thu Apr 12 07:21:03 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nhvp-00016M-00; Thu, 12 Apr 2001 07:18:45 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nhvn-00016C-00; Thu, 12 Apr 2001 07:18:43 -0700 Received: from mail.noos.fr ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 07:18:42 -0700 Received: (qmail 12481276 invoked by uid 0); 12 Apr 2001 14:18:39 -0000 Received: from d024.dhcp212-198-210.noos.fr (HELO KAVEMAISON) ([212.198.210.24]) (envelope-sender ) by racine.noos.net (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 14:18:39 -0000 Reply-To: From: =?US-ASCII?Q?Kave_Salamatian?= To: Cc: , Subject: RE: RTT estimation for multicast Date: Thu, 12 Apr 2001 16:21:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3AD5A268.3BFD6C59@21rst-century.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Marshall, I agree with some of your point. >1.) I think that the ACK implosion problem is much over-rated in the current >Internet, although RTCP needs to be modified for SSM and for very >large groups. I do not know what Rito Ljc wants to do, so it >is hard to figure out what RTT update rate he desires. >For our case, if we had a million listeners, we would (in our SSM RTCP >implementation) be receiving about 20 megabits per second of receiver >reports back to us. Although that sounds like a high data rate, >it amounts to a cost of about 0.1% of revenue for that case, which >would easily be affordable (assuming 1 million receivers). You have >to modify the protocol a little, but having these kinds of data >rates are not really a problem today. Conceptually, the problem do not arise simply from the ACK implosion problem. Mulcast channels are assymetrical in that sense that their one to many in one direction and many to one in the other. One way of contourning the problem is to see this highly assymetric channel as a combination of several symmetrical point to point channel and dealing with them separately. When you have enough ressource (bandwidth and computing power) you can do that but this approach does not scale well with a lot of receivers. For example in your one million receiver case the problem will not arise from receiving the RTCP packets. But mainly for retransmitting the answer to them (or to calculate the rtt and store it). If want to send the answer in unicast you will have to send packet to 1 million different destination each second !!! >2.) Is either the MLDA approach or the Golestani approach implemented anywhere ? >You can use RTCP compliant receivers to estimate RTT now. We are implementing MLDA even if I am not happy with it mainly because of your next argument. But It is the only way of doing TCP Friendly thing. >3.) I am sorry, but using the actual RTT to calculate the desired rate >for multicast congestion control doesn't really make any sense to me. Multicast >is one way, and the notion of filling up the pipe to maximize the >transmission of data between ACKs just doesn't apply. (Some NAK based schemes >might be counter examples here.) Totally agree with you. The underlying network model for TCP is that the network is a rigid pipe that can contain one TCP window. This model is totally wrong for multicast. A good congestion control for multicast should be rate based and no more window based. >The real reason RTT is used in multicast CC seems to be just to mimic the TCP average throughput using Padhye's >equation or something similar, where throughput is inversely proportional to >the RTT. This can lead to strange results in the real world. >Suppose you use a satellite link to distribute multicast data to remote >POP's, where it is sent out to receivers. The RTT will include the 80,000 >kilometers of satellite path up and down, and so will be at least 250 milliseconds one way. >Suppose that the ground based RTT to a receiver was 50 milliseconds (25 each way), >so that the satellite based RTT will be 275 milliseconds, vs 50 for the ground based, or >a factor of 5.5. >If this satellite link was being used for multicast only, to avoid congesting the commodity Internet, >is it really fair to penalize it by a factor of 5 in its "fair" bandwidth usage? >Yes, to do standard TCP over a satellite link without TCP tuning may be inefficient, >but should that inefficiency be imposed on satellite multicasts when there is no TCP >over that link ? Here you give a nice example of TCP absurdity. Another one is following : If the forward path is not congested but the backward link is, TCP mechanism will adapt to the backward link condition which is completely out of purpose. >My personal opinion is that multicast congestion control is really a hard problem, and >likely to require operational feedback before it really works well. (The same was >true with TCP, by the way.) "Fairness" seems to me to be an ill-posed problem for multicast, >but "don't break the network" is a well posed problem that I do not think is solved >for multicast, but could be. I worry that just trying to emulate TCP throughput >will prove to be a dead-end, and will detract from solving the more basic problem >of trying to keep growth in multicast traffic from breaking things in the network. I agree with you on this subject. I think that the main problem in multicast (as for the unicast case) is not congestion control. It is mainly application adaptation to network state. Globally from a theoritical point of view it can be shown that unlike the point to point case where the network optimisation problem, can be separated from the user optimisation problem and lead to fairness providing algorithms that do not need operationnal feedback, the multicasr case is not separable. This means that you cannot reach to any fairness without coordinated action of the network and the user. However, I wish to thak marshall for his contribution. Regards Kv Kave Salamatian wrote: > > Hi, > > Sorry to contradict you Marshall. But RTT estimation in the multicast > channel is not as easy because of the feedback implosion problem. The two > paper I mention before explain why and give some solution. The MLDA approach > need clock synchronisation (or at least realtime online clock skew > estimation) but the Golestani approach distribute the rtt calculation over > the multicast tree. > > if you want to use rtt for TCP friendly rate adaptation you should go > through the above mentionned process and the approach suggested by you is > not sufficient as it will generate too spaced rtt estimates. > > Regards > > Kv > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: jeudi 12 avril 2001 12:49 > To: csljc@ust.hk > Cc: rem-conf@es.net > Subject: Re: RTT estimation for multicast > > Use RTCP. Remember, you do NOT need to know > anything about the receiver's clock to estimate a RTT. > > >From draft-ietf-avt-rtp-new-09.txt > > (from section 4) > > Wallclock time (absolute date and time) is represented using the > timestamp format of the Network Time Protocol (NTP), which is in > seconds relative to 0h UTC on 1 January 1900 [11]. The full > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > the integer part in the first 32 bits and the fractional part in the > last 32 bits. In some fields where a more compact representation is > appropriate, only the middle 32 bits are used; that is, the low 16 > bits of the integer part and the high 16 bits of the fractional part. > The high 16 bits of the integer part must be determined > independently. > > and (From 6.4.1) > > Let SSRC_r denote the receiver issuing this receiver > report. Source SSRC_n can compute the round-trip > propagation delay to SSRC_r by recording the time A when > this reception report block is received. It calculates the > total round-trip time A-LSR using the last SR timestamp > (LSR) field, and then subtracting this field to leave the > round-trip propagation delay as (A- LSR - DLSR). This is > illustrated in Fig. 2. > > Remember, though, that in the real Internet multicast routing will > frequently be asymmetric, and > will commonly be different than for unicast traffic, which might cause > problems depending > on what you want to do. > > Rito Ljc wrote: > > > > Can any one give some directions on how to efficiently estimate Round-trip > time > > for each receivers in a mulciast environment. > > > > Thanks > > -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 07:22:59 2001 From rem-conf-request@es.net Thu Apr 12 07:22:58 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nhzN-0001EZ-00; Thu, 12 Apr 2001 07:22:25 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nhzM-0001EP-00; Thu, 12 Apr 2001 07:22:24 -0700 Received: from mail.noos.fr ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 07:22:23 -0700 Received: (qmail 1719839 invoked by uid 0); 12 Apr 2001 14:22:21 -0000 Received: from d024.dhcp212-198-210.noos.fr (HELO KAVEMAISON) ([212.198.210.24]) (envelope-sender ) by camus.noos.net (qmail-ldap-1.03) with SMTP for ; 12 Apr 2001 14:22:21 -0000 Reply-To: From: =?US-ASCII?Q?Kave_Salamatian?= To: "Falko Dressler" , "Marshall Eubanks" Cc: Subject: RE: RTT estimation for multicast Date: Thu, 12 Apr 2001 16:25:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Falko, >I do think that you are right, but you have to distinguish between >(1) online congestion control for a particular application and >(2) 'offline' QoS measurement for (a part of) the internet. >The first one can be done using the RTP/RTCP protocol (maybe including >some enhancements). Not yet implemented is the much more meaningful >measurement of the one-way delay. I completely agree with you. Moreover the one way delay is more natural for multicast transmission taht are one to many. >The second one is more useful for the providers of a network service. >There are some first ideas / implementations to provide information about >the current state (reliability and QoS) of an IP multicast network: the >MRM (Multicast Reachability Monitor, IETF draft) and an advancement, the >MQM (Multicast Quality Monitor, to be published soon). I wonder about the utility of rtt in the context of multicast out of TCP friendly rate calculation. Can you give me some applications? >I don't think, that the are real problems to scale for (1). But there >are such problems for (2), which can only be solved by intelligent >selecting the interesting parts of the network to survey. >Best wishes, >Falko. Regards Kv From rem-conf Thu Apr 12 07:54:49 2001 From rem-conf-request@es.net Thu Apr 12 07:54:48 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14niTL-0002rn-00; Thu, 12 Apr 2001 07:53:23 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14niTK-0002rd-00; Thu, 12 Apr 2001 07:53:22 -0700 Received: from web-2.star2.net ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 07:53:21 -0700 Received: from 21rst-century.com (1Cust116.tnt2.lorton.va.da.uu.net [63.23.103.116]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 12 Apr 2001 11:03:26 -0400 Message-ID: <3AD5C1AC.7F6BD3CE@21rst-century.com> Date: Thu, 12 Apr 2001 10:54:35 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Falko Dressler CC: rem-conf@es.net, salamat@rp.lip6.Fr Subject: Re: RTT estimation for multicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Falko; Falko Dressler wrote: > > Hello Marshall, > > I do think that you are right, but you have to distinguish between > (1) online congestion control for a particular application and > (2) 'offline' QoS measurement for (a part of) the internet. > You are of course correct. Many applications (multiparty games, for example) might also need / want to know RTT and OWTT for various reasons. I was thinking online here. > The first one can be done using the RTP/RTCP protocol (maybe including > some enhancements). Not yet implemented is the much more meaningful > measurement of the one-way delay. This is tough. If you really need to have good one way times, I would invest in cheap GPS clocks, which can give you time sync anywhere to much better than a microsecond. > The second one is more useful for the providers of a network service. > There are some first ideas / implementations to provide information about > the current state (reliability and QoS) of an IP multicast network: the > MRM (Multicast Reachability Monitor, IETF draft) and an advancement, the > MQM (Multicast Quality Monitor, to be published soon). > > I don't think, that the are real problems to scale for (1). But there > are such problems for (2), which can only be solved by intelligent > selecting the interesting parts of the network to survey. > I think of this as a nested problem. There are very revealing tools (such as mtrace) which cannot be run that often. There are not so revealing tools (loss statistics aggregated by site or ASN, say), which eventually should be fairly ubiquitous (such as the access grid beacon project). In between, there needs to be something, and there also needs to be a mechanism to take problem alerts (from the wide, but coarse, tools) and apply more fine-grained tools in a more or less automatic fashion. Regards Marshall > Best wishes, > Falko. > > On Thu, 12 Apr 2001, Marshall Eubanks wrote: > > > Date: Thu, 12 Apr 2001 08:41:12 -0400 > > From: Marshall Eubanks > > To: Kave Salamatian rem-conf@es.net rem-conf@es.net > > Subject: Re: RTT estimation for multicast > > > > Hello Kave; > > > > 1.) I think that the ACK implosion problem is much over-rated in the current > > Internet, although RTCP needs to be modified for SSM and for very > > large groups. I do not know what Rito Ljc wants to do, so it > > is hard to figure out what RTT update rate he desires. > > > > For our case, if we had a million listeners, we would (in our SSM RTCP > > implementation) be receiving about 20 megabits per second of receiver > > reports back to us. Although that sounds like a high data rate, > > it amounts to a cost of about 0.1% of revenue for that case, which > > would easily be affordable (assuming 1 million receivers). You have > > to modify the protocol a little, but having these kinds of data > > rates are not really a problem today. > > > > 2.) Is either the MLDA approach or the Golestani approach implemented anywhere ? > > You can use RTCP compliant receivers to estimate RTT now. > > > > 3.) I am sorry, but using the actual RTT to calculate the desired rate > > for multicast congestion control doesn't really make any sense to me. Multicast > > is one way, and the notion of filling up the pipe to maximize the > > transmission of data between ACKs just doesn't apply. (Some NAK based schemes > > might be counter examples here.) > > > > The real reason RTT is used in multicast CC seems to be just to mimic the TCP average throughput using Padhye's > > equation or something similar, where throughput is inversely proportional to > > the RTT. This can lead to strange results in the real world. > > > > Suppose you use a satellite link to distribute multicast data to remote > > POP's, where it is sent out to receivers. The RTT will include the 80,000 > > kilometers of satellite path up and down, and so will be at least 250 milliseconds one way. > > Suppose that the ground based RTT to a receiver was 50 milliseconds (25 each way), > > so that the satellite based RTT will be 275 milliseconds, vs 50 for the ground based, or > > a factor of 5.5. > > > > If this satellite link was being used for multicast only, to avoid congesting the commodity Internet, > > is it really fair to penalize it by a factor of 5 in its "fair" bandwidth usage? > > Yes, to do standard TCP over a satellite link without TCP tuning may be inefficient, > > but should that inefficiency be imposed on satellite multicasts when there is no TCP > > over that link ? > > > > My personal opinion is that multicast congestion control is really a hard problem, and > > likely to require operational feedback before it really works well. (The same was > > true with TCP, by the way.) "Fairness" seems to me to be an ill-posed problem for multicast, > > but "don't break the network" is a well posed problem that I do not think is solved > > for multicast, but could be. I worry that just trying to emulate TCP throughput > > will prove to be a dead-end, and will detract from solving the more basic problem > > of trying to keep growth in multicast traffic from breaking things in the network. > > > > Regards > > Marshall > > > > > > Kave Salamatian wrote: > > > > > > Hi, > > > > > > Sorry to contradict you Marshall. But RTT estimation in the multicast > > > channel is not as easy because of the feedback implosion problem. The two > > > paper I mention before explain why and give some solution. The MLDA approach > > > need clock synchronisation (or at least realtime online clock skew > > > estimation) but the Golestani approach distribute the rtt calculation over > > > the multicast tree. > > > > > > if you want to use rtt for TCP friendly rate adaptation you should go > > > through the above mentionned process and the approach suggested by you is > > > not sufficient as it will generate too spaced rtt estimates. > > > > > > Regards > > > > > > Kv > > > > > > -----Original Message----- > > > From: Marshall Eubanks [mailto:tme@21rst-century.com] > > > Sent: jeudi 12 avril 2001 12:49 > > > To: csljc@ust.hk > > > Cc: rem-conf@es.net > > > Subject: Re: RTT estimation for multicast > > > > > > Use RTCP. Remember, you do NOT need to know > > > anything about the receiver's clock to estimate a RTT. > > > > > > >From draft-ietf-avt-rtp-new-09.txt > > > > > > (from section 4) > > > > > > Wallclock time (absolute date and time) is represented using the > > > timestamp format of the Network Time Protocol (NTP), which is in > > > seconds relative to 0h UTC on 1 January 1900 [11]. The full > > > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > > > the integer part in the first 32 bits and the fractional part in the > > > last 32 bits. In some fields where a more compact representation is > > > appropriate, only the middle 32 bits are used; that is, the low 16 > > > bits of the integer part and the high 16 bits of the fractional part. > > > The high 16 bits of the integer part must be determined > > > independently. > > > > > > and (From 6.4.1) > > > > > > Let SSRC_r denote the receiver issuing this receiver > > > report. Source SSRC_n can compute the round-trip > > > propagation delay to SSRC_r by recording the time A when > > > this reception report block is received. It calculates the > > > total round-trip time A-LSR using the last SR timestamp > > > (LSR) field, and then subtracting this field to leave the > > > round-trip propagation delay as (A- LSR - DLSR). This is > > > illustrated in Fig. 2. > > > > > > Remember, though, that in the real Internet multicast routing will > > > frequently be asymmetric, and > > > will commonly be different than for unicast traffic, which might cause > > > problems depending > > > on what you want to do. > > > > > > Rito Ljc wrote: > > > > > > > > Can any one give some directions on how to efficiently estimate Round-trip > > > time > > > > for each receivers in a mulciast environment. > > > > > > > > Thanks > > > > > > -- > > > > > > -- > Falko Dressler > Universitaet Erlangen-Nuernberg, RRZE > EMail: Falko.Dressler@rrze.uni-erlangen.de > Tel: +49 9131 85-27802 / Fax: +49 9131 302941 > WWW: http://bsd.rrze.uni-erlangen.de/~fd/ -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 08:00:54 2001 From rem-conf-request@es.net Thu Apr 12 08:00:54 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14niZt-0003by-00; Thu, 12 Apr 2001 08:00:09 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14niZs-0003bV-00; Thu, 12 Apr 2001 08:00:08 -0700 Received: from web-2.star2.net ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 08:00:07 -0700 Received: from 21rst-century.com (1Cust116.tnt2.lorton.va.da.uu.net [63.23.103.116]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 12 Apr 2001 11:10:13 -0400 Message-ID: <3AD5C343.4F378069@21rst-century.com> Date: Thu, 12 Apr 2001 11:01:22 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: salamat@rp.lip6.fr CC: csljc@ust.hk, rem-conf@es.net Subject: Re: RTT estimation for multicast References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Kave; Kave Salamatian wrote: > > Hi Marshall, > > I agree with some of your point. > > >1.) I think that the ACK implosion problem is much over-rated in the > current > >Internet, although RTCP needs to be modified for SSM and for very > >large groups. I do not know what Rito Ljc wants to do, so it > >is hard to figure out what RTT update rate he desires. > > >For our case, if we had a million listeners, we would (in our SSM RTCP > >implementation) be receiving about 20 megabits per second of receiver > >reports back to us. Although that sounds like a high data rate, > >it amounts to a cost of about 0.1% of revenue for that case, which > >would easily be affordable (assuming 1 million receivers). You have > >to modify the protocol a little, but having these kinds of data > >rates are not really a problem today. > Conceptually, the problem do not arise simply from the ACK implosion > problem. Mulcast channels are assymetrical in that sense that their one to > many in one direction and many to one in the other. One way of contourning > the problem is to see this highly assymetric channel as a combination of > several symmetrical point to point channel and dealing with them separately. > When you have enough ressource (bandwidth and computing power) you can do > that but this approach does not scale well with a lot of receivers. For > example in your one million receiver case the problem will not arise from > receiving the RTCP packets. But mainly for retransmitting the answer to them > (or to calculate the rtt and store it). If want to send the answer in > unicast you will have to send packet to 1 million different destination each > second !!! Yes, but why on earth would you want to do this ? Essential to any SSM broadcast type RTCP is either hard-wiring or dynamically sending from the source the RTCP report rate. There is no reason I can see for, in a large scale SSM group, to send information about every receiver to every receiver. > > >2.) Is either the MLDA approach or the Golestani approach implemented > anywhere ? > >You can use RTCP compliant receivers to estimate RTT now. > We are implementing MLDA even if I am not happy with it mainly because of > your next argument. But It is the only way of doing TCP Friendly thing. > > >3.) I am sorry, but using the actual RTT to calculate the desired rate > >for multicast congestion control doesn't really make any sense to me. > Multicast > >is one way, and the notion of filling up the pipe to maximize the > >transmission of data between ACKs just doesn't apply. (Some NAK based > schemes > >might be counter examples here.) > Totally agree with you. The underlying network model for TCP is that the > network is a rigid pipe that can contain one TCP window. This model is > totally wrong for multicast. A good congestion control for multicast should > be rate based and no more window based. > > >The real reason RTT is used in multicast CC seems to be just to mimic the > TCP average throughput using Padhye's > >equation or something similar, where throughput is inversely proportional > to > >the RTT. This can lead to strange results in the real world. > > >Suppose you use a satellite link to distribute multicast data to remote > >POP's, where it is sent out to receivers. The RTT will include the 80,000 > >kilometers of satellite path up and down, and so will be at least 250 > milliseconds one way. > >Suppose that the ground based RTT to a receiver was 50 milliseconds (25 > each way), > >so that the satellite based RTT will be 275 milliseconds, vs 50 for the > ground based, or > >a factor of 5.5. > > >If this satellite link was being used for multicast only, to avoid > congesting the commodity Internet, > >is it really fair to penalize it by a factor of 5 in its "fair" bandwidth > usage? > >Yes, to do standard TCP over a satellite link without TCP tuning may be > inefficient, > >but should that inefficiency be imposed on satellite multicasts when there > is no TCP > >over that link ? > Here you give a nice example of TCP absurdity. Another one is following : If > the forward path is not congested but the backward link is, TCP mechanism > will adapt to the backward link condition which is completely out of > purpose. > Good point. > >My personal opinion is that multicast congestion control is really a hard > problem, and > >likely to require operational feedback before it really works well. (The > same was > >true with TCP, by the way.) "Fairness" seems to me to be an ill-posed > problem for multicast, > >but "don't break the network" is a well posed problem that I do not think > is solved > >for multicast, but could be. I worry that just trying to emulate TCP > throughput > >will prove to be a dead-end, and will detract from solving the more basic > problem > >of trying to keep growth in multicast traffic from breaking things in the > network. > I agree with you on this subject. I think that the main problem in multicast > (as for the unicast case) is not congestion control. It is mainly > application adaptation to network state. Globally from a theoritical point > of view it can be shown that unlike the point to point case where the > network optimisation problem, can be separated from the user optimisation > problem and lead to fairness providing algorithms that do not need > operationnal feedback, the multicasr case is not separable. This means that > you cannot reach to any fairness without coordinated action of the network > and the user. > Do you have a reference for this? It sounds plausible, but... > However, I wish to thak marshall for his contribution. > You're welcome. Regards Marshall > Regards > > Kv > > Kave Salamatian wrote: > > > > Hi, > > > > Sorry to contradict you Marshall. But RTT estimation in the multicast > > channel is not as easy because of the feedback implosion problem. The two > > paper I mention before explain why and give some solution. The MLDA > approach > > need clock synchronisation (or at least realtime online clock skew > > estimation) but the Golestani approach distribute the rtt calculation over > > the multicast tree. > > > > if you want to use rtt for TCP friendly rate adaptation you should go > > through the above mentionned process and the approach suggested by you is > > not sufficient as it will generate too spaced rtt estimates. > > > > Regards > > > > Kv > > > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@21rst-century.com] > > Sent: jeudi 12 avril 2001 12:49 > > To: csljc@ust.hk > > Cc: rem-conf@es.net > > Subject: Re: RTT estimation for multicast > > > > Use RTCP. Remember, you do NOT need to know > > anything about the receiver's clock to estimate a RTT. > > > > >From draft-ietf-avt-rtp-new-09.txt > > > > (from section 4) > > > > Wallclock time (absolute date and time) is represented using the > > timestamp format of the Network Time Protocol (NTP), which is in > > seconds relative to 0h UTC on 1 January 1900 [11]. The full > > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > > the integer part in the first 32 bits and the fractional part in the > > last 32 bits. In some fields where a more compact representation is > > appropriate, only the middle 32 bits are used; that is, the low 16 > > bits of the integer part and the high 16 bits of the fractional part. > > The high 16 bits of the integer part must be determined > > independently. > > > > and (From 6.4.1) > > > > Let SSRC_r denote the receiver issuing this receiver > > report. Source SSRC_n can compute the round-trip > > propagation delay to SSRC_r by recording the time A when > > this reception report block is received. It calculates the > > total round-trip time A-LSR using the last SR timestamp > > (LSR) field, and then subtracting this field to leave the > > round-trip propagation delay as (A- LSR - DLSR). This is > > illustrated in Fig. 2. > > > > Remember, though, that in the real Internet multicast routing will > > frequently be asymmetric, and > > will commonly be different than for unicast traffic, which might cause > > problems depending > > on what you want to do. > > > > Rito Ljc wrote: > > > > > > Can any one give some directions on how to efficiently estimate > Round-trip > > time > > > for each receivers in a mulciast environment. > > > > > > Thanks > > > > -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Thu Apr 12 09:06:53 2001 From rem-conf-request@es.net Thu Apr 12 09:06:53 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14njaO-000565-00; Thu, 12 Apr 2001 09:04:44 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14njaN-00055v-00; Thu, 12 Apr 2001 09:04:43 -0700 Received: from serve.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 09:04:42 -0700 Received: from john (dsl254-117-007.nyc1.dsl.speakeasy.net [216.254.117.7]) by serve.com (Postfix) with SMTP id 31482550BC; Thu, 12 Apr 2001 11:58:31 -0400 (EDT) From: "Secure E-Business Executive Summit" To: "Secure E-Biz Summit" Subject: DoD's Secure E-Business Summit - EARLY BIRD RATE EXPIRES 4/15/01 Date: Thu, 12 Apr 2001 12:00:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SECURE E-BUSINESS EXECUTIVE SUMMIT May 7-9, 2001 Hilton Crystal City, EARLY BIRD RATE EXPIRES ON SUNDAY, APRIL 15 Register Today at www.SecurE-Biz.net ******************************************* The Federal CIO Council, The Department of Defense CIO, the National Information Assurance Partnership (National Security Agency (NSA) & National Institute of Standards and Technology (NIST)), the National Imagery & Mapping Agency (NIMA), the U.S. Treasury Department, the Department of Veterans Affairs, and the Canadian Department of National Defence are jointly hosting the annual Secure E-Business Executive Summit. Art Money, CIO for the Department of Defense, issued a letter urging industry and government to support the Secure E-Business Executive Summit. That letter may be viewed at http://www.SecurE-Biz.net/DCIO_letter.pdf. Building on last year's successful formula, this year's program is designed to address the disparate needs of enterprise system designers, architects, program managers, CIO's, CTO's, and business leaders. The 2000 E-Business Summit was received with great enthusiasm by over 450 delegates from business and industry, with overwhelming praise for being a non-tradeshow, content rich venue that focused on addressing real challenges in transitioning into the secure internet infrastructure. Three parallel tracks, plus a daily CIO Roundtable will address the varied educational needs of the IT community: - STRATEGIES FOR BUSINESS PROCESS TRANSFORMATION - ADAPTIVE ARCHITECTURES FOR INTERNET INFRASTRUCTURE - E-SOLUTIONS FOR IT INVESTMENT For additional information, please see www.SecurE-Biz.net Invited Distinguished Speakers include: Marvin Adams, CIO and EVP, Ford Ed Amoroso, Director, Security, AT&T Gregor S. Bailar, CIO, NASD Tim Berners-Lee, Managing Director, MIT, W3C Ed Black, President & CEO, CCIA Miriam Browning, Deputy CIO, U.S. Army Mayi Canales, COO, Department of the Treasury Joe Cleveland, Corporate CIO, Lockheed Martin Steve Cochran, VP, Council for Excellence in Government Dr. Dan Geer, Technical Director, @Stake Mike Gibbons, Senior Manager, Information Assurance, KPMG Consulting Al Grasso, CIO, Mitre Corporation Micheal Guttman, Chief Technical Officer, IONA Giliman Louie, President, In-Q-Tel Monica Luechtefeld, VP E-Commerce, Office Depot Terry Mainard, Technical Director, CIA Diann McCoy, Deputy Director, Information Engineering, DISA Fred Meyer, CMO, Tibco Cheri Musser, CIO, E-GM, General Motors John L. Osterholz, Dir., Arch & Interop, OSD C3I Dr. Ron Ross, Director, NIST, NIAP Scott Schnell, Senior VP, RSA Security Gen Bernard Skoch, Principal Director, DISA Richard Mark Soley, Ph.D., CEO, OMG Mark Tolliver, President, Netscape iPlanet Ron Turner, Deputy CIO, Navy G. Martin Wagner, Associate Administrator, GSA Dr. Linton Wells, II, Principle Deputy, OSD C3I General John Woodward, Deputy CIO, Department of Defense (For a complete listing of speakers and the agenda, please see the web site, at www.SecurE-Biz.net) Register Online at www.SecurE-Biz.net: Early Bird Registration (until April 15, 2001): - Government: $295 - Non-government: $345 After April 15, 2001: - Government: $395 - Non-government: $445 Sponsors of the Secure E-Business Executive Summit include: AT&T, Anadac, Interoperability Clearinghouse, IONA, iPlanet, KPMG Consulting, Lockheed Martin, the Object Management Group, the Objective Technology Group, Oracle, Post Newsweek Tech Media Group, RSA Security, Tibco, CIO Magazine, Federal Computer Week, Government Computer News, Washington Technology, the Council for Excellence in Government, the Computer and Communications Industry Association (CCIA), and the Center for Internet Security, For more information, please go to www.SecurE-Biz.net, www.c3i.OSD.mil/ebiz/, or call (703)768-0400. From rem-conf Thu Apr 12 09:10:07 2001 From rem-conf-request@es.net Thu Apr 12 09:10:06 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14njcc-00058s-00; Thu, 12 Apr 2001 09:07:02 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14njcb-00058Q-00; Thu, 12 Apr 2001 09:07:01 -0700 Received: from serve.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 09:07:00 -0700 Received: from john (dsl254-117-007.nyc1.dsl.speakeasy.net [216.254.117.7]) by serve.com (Postfix) with SMTP id 950E654F78; Thu, 12 Apr 2001 12:04:16 -0400 (EDT) From: "Secure E-Business Executive Summit" To: "Secure E-Biz Summit" Subject: DoD's Secure E-Business Summit - EARLY BIRD RATE EXPIRES 4/15/01 Date: Thu, 12 Apr 2001 12:06:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SECURE E-BUSINESS EXECUTIVE SUMMIT May 7-9, 2001 Hilton Crystal City, EARLY BIRD RATE EXPIRES ON SUNDAY, APRIL 15 Register Today at www.SecurE-Biz.net ******************************************* The Federal CIO Council, The Department of Defense CIO, the National Information Assurance Partnership (National Security Agency (NSA) & National Institute of Standards and Technology (NIST)), the National Imagery & Mapping Agency (NIMA), the U.S. Treasury Department, the Department of Veterans Affairs, and the Canadian Department of National Defence are jointly hosting the annual Secure E-Business Executive Summit. Art Money, CIO for the Department of Defense, issued a letter urging industry and government to support the Secure E-Business Executive Summit. That letter may be viewed at http://www.SecurE-Biz.net/DCIO_letter.pdf. Building on last year's successful formula, this year's program is designed to address the disparate needs of enterprise system designers, architects, program managers, CIO's, CTO's, and business leaders. The 2000 E-Business Summit was received with great enthusiasm by over 450 delegates from business and industry, with overwhelming praise for being a non-tradeshow, content rich venue that focused on addressing real challenges in transitioning into the secure internet infrastructure. Three parallel tracks, plus a daily CIO Roundtable will address the varied educational needs of the IT community: - STRATEGIES FOR BUSINESS PROCESS TRANSFORMATION - ADAPTIVE ARCHITECTURES FOR INTERNET INFRASTRUCTURE - E-SOLUTIONS FOR IT INVESTMENT For additional information, please see www.SecurE-Biz.net Invited Distinguished Speakers include: Marvin Adams, CIO and EVP, Ford Ed Amoroso, Director, Security, AT&T Gregor S. Bailar, CIO, NASD Tim Berners-Lee, Managing Director, MIT, W3C Ed Black, President & CEO, CCIA Miriam Browning, Deputy CIO, U.S. Army Mayi Canales, COO, Department of the Treasury Joe Cleveland, Corporate CIO, Lockheed Martin Steve Cochran, VP, Council for Excellence in Government Dr. Dan Geer, Technical Director, @Stake Mike Gibbons, Senior Manager, Information Assurance, KPMG Consulting Al Grasso, CIO, Mitre Corporation Micheal Guttman, Chief Technical Officer, IONA Giliman Louie, President, In-Q-Tel Monica Luechtefeld, VP E-Commerce, Office Depot Terry Mainard, Technical Director, CIA Diann McCoy, Deputy Director, Information Engineering, DISA Fred Meyer, CMO, Tibco Cheri Musser, CIO, E-GM, General Motors John L. Osterholz, Dir., Arch & Interop, OSD C3I Dr. Ron Ross, Director, NIST, NIAP Scott Schnell, Senior VP, RSA Security Gen Bernard Skoch, Principal Director, DISA Richard Mark Soley, Ph.D., CEO, OMG Mark Tolliver, President, Netscape iPlanet Ron Turner, Deputy CIO, Navy G. Martin Wagner, Associate Administrator, GSA Dr. Linton Wells, II, Principle Deputy, OSD C3I General John Woodward, Deputy CIO, Department of Defense (For a complete listing of speakers and the agenda, please see the web site, at www.SecurE-Biz.net) Register Online at www.SecurE-Biz.net: Early Bird Registration (until April 15, 2001): - Government: $295 - Non-government: $345 After April 15, 2001: - Government: $395 - Non-government: $445 Sponsors of the Secure E-Business Executive Summit include: AT&T, Anadac, Interoperability Clearinghouse, IONA, iPlanet, KPMG Consulting, Lockheed Martin, the Object Management Group, the Objective Technology Group, Oracle, Post Newsweek Tech Media Group, RSA Security, Tibco, CIO Magazine, Federal Computer Week, Government Computer News, Washington Technology, the Council for Excellence in Government, the Computer and Communications Industry Association (CCIA), and the Center for Internet Security, For more information, please go to www.SecurE-Biz.net, www.c3i.OSD.mil/ebiz/, or call (703)768-0400. From rem-conf Thu Apr 12 09:34:23 2001 From rem-conf-request@es.net Thu Apr 12 09:34:23 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nk1p-000713-00; Thu, 12 Apr 2001 09:33:05 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nk1o-00070t-00; Thu, 12 Apr 2001 09:33:04 -0700 Received: from gw-nl4.philips.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 09:33:03 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA18629 for ; Thu, 12 Apr 2001 18:33:01 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma018627; Thu, 12 Apr 01 18:33:01 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA11908 for ; Thu, 12 Apr 2001 18:33:01 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id SAA03629 for ; Thu, 12 Apr 2001 18:32:35 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900017351247; Thu, 12 Apr 2001 18:44:58 +0200 To: Subject: MPEG-4 RTP payload format Message-ID: <0056900017351247000002L072*@MHS> Date: Thu, 12 Apr 2001 18:44:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 04/12/01 18:31:30" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A new version of the MPEG-4 generic (SL) RTP payload format is available at: http://search.ietf.org/internet-drafts/draft-gentric-avt-mpeg4-multisl-= 03.txt Changes are affecting the document structure and english text but not the principles nor actual payload format. Regards, Philippe Gentric Software architect MP4net - Broadcast & Internet delivery solutions Laboratoires d'Electronique Philips BP15 22 av. Descartes 94453 Limeil-Brevannes Cedex France tel: +33(0)145106812 fax: +33(0)145106960 Philippe.Gentric@philips.com = From rem-conf Thu Apr 12 10:32:28 2001 From rem-conf-request@es.net Thu Apr 12 10:32:28 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nkua-0000WL-00; Thu, 12 Apr 2001 10:29:40 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nkuZ-0000WB-00; Thu, 12 Apr 2001 10:29:39 -0700 Received: from redball.dynamicsoft.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 10:29:38 -0700 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA17334; Thu, 12 Apr 2001 13:32:45 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Apr 2001 13:29:14 -0400 Message-ID: From: Jonathan Rosenberg To: "'salamat@rp.lip6.fr'" , tme@21rst-century.com Cc: csljc@ust.hk, rem-conf@es.net Subject: RE: RTT estimation for multicast Date: Thu, 12 Apr 2001 13:29:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: Kave Salamatian [mailto:salamat@rp.lip6.fr] > Sent: Thursday, April 12, 2001 10:22 AM > To: tme@21rst-century.com > Cc: csljc@ust.hk; rem-conf@es.net > Subject: RE: RTT estimation for multicast > > > Hi Marshall, > > I agree with some of your point. > > >1.) I think that the ACK implosion problem is much over-rated in the > current > >Internet, although RTCP needs to be modified for SSM and for very > >large groups. I do not know what Rito Ljc wants to do, so it > >is hard to figure out what RTT update rate he desires. Lots of work has been done on scaling up RTCP to large groups (although SSM is a bit different). Some algorithms have been added to the rtp-new spec called reconsideration, which help maintain a constant aggregate RTCP rate independent of group size. As far as RTT estimation goes, a sender will end up with a constant rate of RTT estimates, each one from a different host. Our studies have actually shown that the RTCP algorithms are fair, evenly dividing up the RTCP rate amongst all the group members in steady state. These studies have also shown that the reconsideration algorithms tend to favor rate allocation to uses who have not yet sent packets, which means that a sender gets a broad sampling of RTTs across users. Whether thats what you want or not is a good question. For SSM, the RTCP scaling algorithms don't work unless the source tells the recipient the group size. We looked at this a while back, and there are some serious smurf style DoS attack issues that can arise for large groups (an attacker reports a low group size, causing everyone to flood the target). Interestingly, using the sender to report the group size also increases the effective network latency for learning group joins. That is, once a user joins, we need to wait for the source to learn it, and report it back, until group members know about the change. Our studies have shown that this increased latency worsens the congestion effects that arise when a large number of users simultaneously join a group. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From rem-conf Thu Apr 12 12:05:10 2001 From rem-conf-request@es.net Thu Apr 12 12:05:08 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nmKb-0002BG-00; Thu, 12 Apr 2001 12:00:37 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nmKa-0002B6-00; Thu, 12 Apr 2001 12:00:36 -0700 Received: from ietf.org ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 12:00:35 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07463; Thu, 12 Apr 2001 15:00:29 -0400 (EDT) Message-Id: <200104121900.PAA07463@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: A More Loss-Tolerant RTP Payload Format for MP3 Audio to Proposed Standard Date: Thu, 12 Apr 2001 15:00:29 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'A More Loss-Tolerant RTP Payload Format for MP3 Audio' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary While the RTP payload format defined in RFC 2250 [2] is generally applicable to all forms of MPEG audio or video, it is sub-optimal for MPEG 1 or 2, layer III audio (commonly known as "MP3"). The reason for this is that an MP3 frame is not a true "Application Data Unit" - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. This document specifies an alternative RTP payload format for MP3 audio. This format uses a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 "Application Data Units", which can also (optionally) be rearranged in an interleaving pattern. This new format is therefore more data-efficient than RFC 2250 in the face of packet loss. This document also registers the mime type audio/mpa-robust. Working Group Summary This document is a product of the Audio Video Transport (AVT) Working Group. The working group achieved strong consensus for advancing the document. During the last call period, the working group noticed technical concerns with the definition of the timestamp resolution and use of the RTP M-bit, and the author agreed with the working group assessment and revised the document accordingly. Protocol Quality The document was reviewed for the IESG by Allison Mankin. At least one implementation of the payload is known. From rem-conf Thu Apr 12 12:13:09 2001 From rem-conf-request@es.net Thu Apr 12 12:13:09 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14nmVo-0002rZ-00; Thu, 12 Apr 2001 12:12:12 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14nmVn-0002rN-00; Thu, 12 Apr 2001 12:12:11 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 12 Apr 2001 12:12:10 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA05893; Thu, 12 Apr 2001 12:04:38 -0700 Message-ID: <3AD5FD6A.6314BEBB@bmrc.berkeley.edu> Date: Thu, 12 Apr 2001 12:09:30 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/18 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces, and Graphics Seminar bmrc.berkeley.edu/mig Perceptual Scheduling in Real-Time Music and Audio Applications PhD Dissertation April 18, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Amar Chaudhary Computer Science Division - EECS U.C. Berkeley Academic research of computer music and commercial sound systems is moving from special-purpose hardware towards software implementations on general-purpose computers. The enormous gains in general-purpose processor performance gives musicians and composers richer and more complex control of sound in their performances and compositions. Just a geometric modeling has given graphic designers more control of their scens and objects, (e.g., independent control of size, position and texture), sound synthesis allows more control of musical parameters such as duration, frequency and timbre. Examples of sound-synthesis algorithms include additive synthesis, resonance modeling, frequency-modulation(FM) synthesis and physical models. Applications, called synthesis servers, allow musicians to dynamically speecify models for these algorithms and synthesize sound from them in real time in response to user input. A synthesis server is an expressive, software-only musical instrument. However, the widespread use of synthesis servers has been frustrated by high computational requirements. This problem is particularly true of the sinusoidal and resonance models described in this dissertation. Typical sinusoidal and resonance models contain hundreds of elements, called partials, that together represent an approximation of the original sound. Even though computers are now running above the 1GHz clock rate, it is still not possible to use many large models in polyphonic or multi-channel settings. For example, a typical composition might include eight models with 120 partials each, or 960 partials total. Additionally, current operating systems do not guarantee quality of service (QoS) necessary for interactive real-time musical performance, particulary when the system is running at or near full computational capacity. Traditional approaches that pre-compute audio samples or perform optimal scheduling off line do not lend themselves to musical applications that are built dynamically and must be responsive to variations in live musical performance. We introduce a novel approach to reducing the computational requirements in real-time music applications, called perceptual scheduling, in which QoS guarantees are maintained using voluntary detected, the perceptual scheduler requests that the synthesis algorithms reduce computational requirements. Each algorithm reduces its computation using specific psychoacoustic metrics that preserve audio quality while reducing computational complexity. This dissertation describes the perceptual scheduling framework and its application to musical works using additive synthesis and resonance modeling. Reduction strategies are developed based on the results of listening experiments. The reduction strategies and the perceptual scheduling framework are implemented in "Open Sound World," a prototype programming system for synthesis servers. This implementation is then tested on several short musical examples. The computation saved is measured for each example. The quality of the audio output from the servers with and without perceptual scheduling enabled is evaluated by human listeners in a controlled experiment. The result of this experiment have been encouraging. In one example, the average CPU time decreased by about 75%, yet listeners perceivced little degradation in audio quality. The perceptual scheduling framework can be applied to other compute-intensive algorithms in computer music, such as granular synthesis, pitch detection and sound spatialization. It can also be applied to other perceptually oriented computational tasks, such as real-time graphics and video processing. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Fri Apr 13 07:14:15 2001 From rem-conf-request@es.net Fri Apr 13 07:14:14 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14o48u-0003fu-00; Fri, 13 Apr 2001 07:01:44 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14o48t-0003fk-00; Fri, 13 Apr 2001 07:01:43 -0700 Received: from purple.east.isi.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 13 Apr 2001 07:01:35 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id JAA03599 for ; Fri, 13 Apr 2001 09:58:45 -0400 Message-Id: <200104131358.JAA03599@purple.east.isi.edu> To: rem-conf@es.net Subject: DRAFT AVT minutes Date: Fri, 13 Apr 2001 09:58:43 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached are draft minutes from the Minneapolis AVT meeting. Please send comments and corrections to the chairs before Monday morning (EST), in order that we can meet the submission deadline. Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group Minutes Reported by Colin Perkins. The Audio/Video Transport working group met twice at the 50th IETF in Minneapolis. In the first session, we discussed advancement of the RTP specification and audio/video profile to draft standard, also a number of new profiles for secure RTP, unicast RTCP feedback, and low delay RTCP feedback were discussed. In the second session, we discussed RTP payload formats for generic FEC with ULP, AMR, EVRC, Vorbis and MPEG-4. The meeting opened with a status update by Steve Casner. It was noted that there have been a number of problems with the working group's mailing list and it was proposed to move the mailing list to be hosted at ietf.org. Such a move will inevitably be somewhat disruptive, but it was thought that this is better than the current problems, with some messages getting lost, the archive copy to the IETF secretariat not working, and subscription/un-subscription being problematic. Hearing no objection from the group, the chairs plan to transfer the list, and announce the move on the current mailing list and on ietf-announce. Subscription to the new list will NOT be automatic: once it is announced, you will have to manually join (this is because there is no way to get the membership of the current list). The group has had a single RFC published since the last meeting: the RTP payload format for G.722 audio (RFC 3047). The RTP payload format for DV video is with the IESG; the RTP payload for DV audio has been returned to the authors for revision to edit for clarity. In addition, the authors have determined that changes are needed to specify the ordering of bits/samples, to specify a fixed set of compound symbols for the channel order parameters, to describe the handling of 0x8000 in L16 mode (it is an error indication). These revisions are expected to be completed shortly, at which time a brief working group last call will be held before the draft is sent back to the IESG. The more loss tolerant RTP payload format for MP3 audio was sent to the IESG, but withdrawn when implementation work at Apple found some areas which needed clarification. After editorial changes, the draft has now been resubmitted to the IESG for last call. The Secure Real Time Transport Protocol (draft-ietf-avt-srtp-00.txt) was presented by David McGrew (this draft is the result of a merger between two similar proposals presented at the previous meeting). David started by showing that the performance of the scheme on a 500 MHz Pentium II shows a normal throughput of 106.2 Mbps and a rejection throughput of approximately 7.5 million rejections per second, showing performance is not expected to be an issue. Regarding the protocol, a couple of interaction with RFC 1889 were noted. Some have suggested that section 9.1 of RFC 1889 should be applied to SRTP, but since the encryption prefix offers no security advantage when used with current SRTP the authors propose that it is not used. It was also noted that selective encryption of RTCP compound packets is specified in RFC 1889, but this is not currently included in SRTP. Should it be included? Steve Casner noted that this depends on the application scenario. The issue of multiple senders and key reuse was raised. Since the SSRC is used in the encryption context it is necessary to guarantee that the choice of SSRC is unique, or it is necessary to use a different encryption key per sender. Jonathan Lennox noted that, with light-weight multicast sessions, collisions cannot be avoided, and maybe we need wording in the RTP spec that applications should listen during the period before their first RTCP and change their SSRC if the chosen one is heard? [It is already there in section 8.1 of RFC 1889.] This would reduce - but not eliminate - the chance of collisions. David McGrew noted that there's a legitimate chance of a loss of privacy due to this issue. It was noted that the UMAC message authentication scheme specified may not be widely implementable. Ross Finlayson asked about the Tesla scheme coming from the MSEC working group. Bob Briscoe noted that this draft needs to state its applicability: it doesn't authenticate the source, just the group (this is not stated in the draft). He will suggest wording changes to reflect this concern. Bob Briscoe also asked if Tesla should be included in the spec? Maybe, but he doesn't want to hold up SRTP for this. Ross Finlayson noted that he thinks source authentication should be part of the spec. The issue of video on demand and multiple keys per SRTP session was raised, as previously discussed on the mailing list. Is there a possibility of changing encryption keys without changing the RTP sessions? It may be necessary to identify each distinct key with a range of packets. Steve Casner noted that we have the notion of changing the SSRC anyway, so the key distribution can indicate that the SSRC will change with the encryption key, hence this shouldn't be a big issue. SDP parameters need to be defined to signal SRTP and the key to be used. A revised draft will be produced shortly, and it is expected that this will be ready for last call by the time of the next meeting. Julian Chesterfield presented an RTCP extension for source specific multicast sessions (draft-chesterfield-avt-rtcpssm-00.txt). This allows receivers to unicast their RTCP back to the source, which summarises and then multicasts the information to the group. There are two suggestions for how this summary should be conveyed: 1) an RTCP sender report, modified so that each report block corresponds to a report from a receiver; or 2) a new sender summary report, which is similar but has the RR timestamps removed prior to forwarding, saving 8 bytes per report. The draft also contains a modification to RTCP bandwidth allocation, so the backchannel is included in the allocation (this turns out not to be needed). Considerable interest was expressed in this work, and a number of comments and suggestions were noted: - When forwarding RTCP data from the sender, multiple reports can be chained into a single packet, hence receivers must be prepared to handle RR data from multiple sources in a single RR packet. The inclusion of SDES packets containing, at least, the CNAME was suggested. - It is desirable that this is not limited to SSM, hence signaling will be needed (e.g. by SDP). Bob Briscoe asked if any analysis has been done to establish if this is more or less efficient than standard multicast RTCP. Steve Casner answered that it won't be more appropriate for a true multisource application. - Additional security concerns, such as source address spoofing, need to be considered (packet bombing of the source, etc). - Is there enough benefit to having a summary sender report? Steve Casner was unconvinced: there are problems with the calculation of the reporting interval if the packets are aggregated (since the bandwidth the receivers see is less than that the sender sees, which leads to an artificially lower reporting interval). Steve also noted that redefining the meaning of an existing report type could lead to problems, and that it is better to define a new packet type (there is no shortage of RTCP payload type identifier). This work has the potential for wide use and merits further development. The author is working on implementation in the UCL RTP library, and is aware of two other implementations. The two drafts specifying timing rules and packet formats for a new profile for low-delay RTCP backchannel information were revised for this meeting, but have not yet been merged as was planned at the last meeting. This is to be done in mid-April. The first of these discussed concepts and timing rules (draft-wenger-avt-rtcp-feedback-02.txt) and was presented by Joerg Ott. There have been a number of changes since the last meeting: the timer reconsideration section has been checked, and found mostly okay, various video specifics have been removed into an appendix (which may disappear in future), the group size indication in SDP has been removed, and the need for congestion control is noted (to be dealt with in the feedback usage drafts). Regarding timer reconsideration, feedback was solicited especially on the numbers for T_dither_max: are these sensible? Steve Casner said that they seem reasonable, but noted the danger in picking arbitrary numbers when the application may scale to a range of scenarios. Colin Perkins asked if the TFRC work had anything appropriate? Experimentation may be needed. When to send an immediate/early RR was also discussed: need reconsideration in the case where the group size has changed between message scheduling time and the time the message is sent. The next steps are some editing including aligning variable names with the RTP spec. The the draft will be resubmitted as an AVT WG draft, aiming for last call in April 2001. Feedback is solicited. The chairs noted that this doesn't make a profile by itself; it needs to be merged with the packet format drafts (discussed later). It also needs simulation to prove the timers work correctly without causing packet storms, congestion, etc. Carsten Burmeister then led discussion of the RTCP feedback packet format draft (draft-fukunaga-low-delay-rtcp-02.txt). Changes include a new section on reaction to feedback, congestion control recommendations and how a sender should react. The "general feedback behaviour" section has been deleted, since it is covered by Joerg's draft. Steve Casner thinks thought the words on congestion control and reaction to feedback are too vague and unconvincing. Maybe we can't consider this work complete until we have an algorithm defined and tested? Especially in this case, where we have closed loop congestion control. Maybe we can go to experimental for now? We should expect pushback from the IESG if we try to go to proposed standard without words on congestion control. Magnus Westerlund noted that the draft defines two types of feedback: one for general applicability, another for specific functions. The specific functions need specific congestion control; the general case can have more general words? Reha Civanlar asked what is the acceptable congestion control so that we don't get pushback from the IESG? RFC 2914 (although we couldn't remember the reference at the time...). Discussion of the correct status continued for a while, with it becoming clear that the authors did not favour experimental. Outcome: complete the documents, and we'll ask the AD's for their opinion. Carsten Burmeister then presented an RTP Retransmission Payload Format (draft-ietf-avt-rtp-selret-01.txt). Note that IPR exists on this draft. The draft has changed since the last meeting, and now comprises two parts: 1) an RTP payload format for retransmitted packets which implies that retransmissions get a new sequence number from the original space, so their loss can be detected (the original seqnum is sent in the payload header); 2) a low priority payload format with a different sequence number space for the "important" packets which is used to enable receiver to report only important packet losses. Open issues include: non-constant SN-TS relation when retransmissions occur (but this also occurs due to silence suppression, so this is not a problem), and gaps in the received sequence number space (as seen by the application, not in the RTP packets) once the data has been recovered (this is an application design issue, not a protocol issue). Since this depends on the RTCP feedback profile, it cannot advance until that is complete. There followed more discussion of the need for congestion control, and where congestion control should be specified. When asked, Joerg Ott noted that it might be better to avoid tying the timing rules draft too closely to the rest of the RTCP feedback profile. Steve Casner noted that many users would want to use them together, so why not a combined document? Joerg noted that there are advantages in allowing the possibility of other timing rules. After some discussion, the consensus emerged that a single profile should be produced, which has explicit discussion of usage of the timing rules, and that the RTP retransmission work should advance as a draft which uses this profile. The next section of the meeting was devoted to the revision of the RTP specification and audio/video profile, which have now completed a second working group last call. These drafts have been updated with new text on congestion control, to address concerns raised at the last meeting. This now references RFC 2914 for background information, and clarifies that fairness with TCP is measured on a "reasonable" timeframe, and is intended to be "order of magnitude" fairness. The consensus was that this text is "definitely better", and so the spec will be submitted to the IESG with this text as it is. Regarding the RTP interop matrix, good progress has been made: most items are either tested or have tests promised. Unfortunately, a few were not tested and have been removed from the spec (primarily the following codecs: 1016, G.723, GSM-HR, GSM-EFR, MP2T, H.263, BT.656, MP1S, MP2P, BMPEG). The chairs aim to complete all interop testing by April 15: Colin Perkins and Magnus Westerlund have promised to complete some outstanding tests by that date, others who are testing are also urged to complete their tests by then also (G.723 and H.263 have since been tested and reinstated). In discussion of the outstanding tests, Jonathan Lennox said that he has a program which converts RTP/UDP into RTP/TCP. If anyone else has an RTP over TCP implementation, he is willing to test with then, to re-instate this feature. Magnus Westerlund noted that GSM-EFR is part of AMR, GSM-HR isn't. Hence it is more likely that there will be implementations of GSM-EFR, or that it will be subsumed into AMR: Cisco have an implementation, and will do some testing with Magnus. Glenn Parsons asked about the use of audio/32kadpcm (used in VPIM) versus audio/g726-32 (as specified by the A/V profile). Are we tied to the particular name? Yes, use is already established. Steve Casner will edit our registration for G726-32 to make a cross-reference to the other registration (noting the two MIME types imply different transports). Steve reminded the group of a number of other issues which have been raised during the last call: Harald Alvestrand asked if the RTP spec as written precludes the use of SSM? No, but we have extensions in progress to better support this. Magnus Westerlund noted that the requirement for an SDES CNAME in every RTCP packet was wasteful and insecure in the case where RTCP is split into encrypted and unencrypted packets. The spec will be edited to clarify that it's not needed in both packets. There are several of companion drafts which are also complete, and last call will to be issued shortly: testing strategies, bandwidth modifiers, comfort noise, and MIME registration. Once the RTP interop results are done, on April 15th, RTP and the A/V profile will be passed to the IESG for last call for draft standard. Jonathan Lennox asked if there are people interested in a particular payload format, but don't have interop results, can that payload format spec be split out into a separate proposed standard RFC? Yes. Once the RTP specification has advanced, it is also necessary to advance RTP header compression (RFC 2508) to draft standard. Carsten Bormann noted that moving RFC 2508 to draft standard requires RFC 2507 and RFC 2509 to go forward also. He's not sure that the authors of those drafts would want them to go forward, and wants discussion of ROHC vs CRTP to happen before we set milestones for advancing these. Steve Casner wondered when and where should this be discussed? Carsten also noted the problem that RFC 2507 TCP compression is rapidly becoming historic. Also not all the proposed enhancements to CRTP are needed for TCRTP. We should try to figure out which make sense, and maybe just advance those? No consensus was reached: we need to discuss this further. Moving into the second day, the RTP payload format for Generic FEC with ULP (draft-ietf-avt-ulp-00.txt) was presented by Adam Li. The author asked for suggestions on how to add the extension flag to facilitate future expansion (e.g. as in RFC 2733), but no spare bit exists in the header. Options are to add an extra byte between FEC header and level zero header, or to shorten one of the fields by one bit. Jonathan Rosenberg seemed to prefer the second approach, but Steve Casner noted that trying to shoe-horn an extension which won't fit is unwise. An alternative is to have a different extension to generic FEC, rather than extending this format. It was agreed to keep this ULP proposal as is. Simulation results were presented, showing performance of H.263/ULP with with random packet drop and various MTU sizes, using a rate distortion curve to measure the effects of loss. Stephan Wenger said the curves are impressive, but have a systematic problem since adding ULP adds bits, but adding bits give the increased possibility that the protection data gets lost. Jonathan Rosenberg noted that this is included in the data. Colin Perkins asked if random loss was the only loss model they have used, or if more realistic choices have been used? Random loss is the only test (someone suggested the Gilbert model as an alternative). Luca Martini gave a brief overview of the SONET over RTP proposal, which is under consideration in the PWE3 working group. This is one of the proposals for pseudo-wire emulation in PWE3, but they are also considering other solutions and there is an alternative MPLS-based proposal with reduced headers relative to RTP. Members of the AVT working group are encouraged to follow the work in PWE3, since there could be considerable overlap with RTP (the PWE3 group will have an interim meeting between now and next IETF - possibly end of May.) Magnus Westerlund presented the combined RTP payload format for AMR and AMR-WB (this is a combination of the two drafts mentioned on the agenda). The motivation is to have the same payload format for AMR-WB and AMR-NB, supporting the frame interleaving for AMR NB as well. After a brief description of the combined solution, Magnus noted that the biggest issue is the split into two modes, bandwidth efficient and octet aligned, which can lead to interop problems: both modes SHOULD be implemented. In addition, robust sorting, CRC and interleaving are OPTIONAL but their support must be signaled, this also has the potential for interop problems. It was noted that 3GPP is very keen to see this advance to RFC status, and that a new draft was to be produced within a week (since the meeting this has become available as draft-ietf-avt-rtp-amr-06.txt). Steve Casner asked if it would be better if the X and S bits were sent out of band since the mode is not likely to change during the session, thereby also saving a couple of bits in the payload. Magnus agreed with X but not with S since you may want to switch sorting during the session. Much discussion ensued, with little consensus emerging. Qiaobing Xie asked about the two tables in the current draft which show mode and rate mapping: those mappings might change in 3GPP, why not refer to that draft? Magnus replied that the 3GPP spec will be approved before this goes to proposed standard, so don't expect this to be a problem. The number of class A bits is also an issue, since this is informational in 3GPP, and left to operator choice. Not sure it can be specified in 3GPP. Steve Casner asked, in that case, why is it reasonable to specify it here? We don't want to specify an aspect of codec operation which is the domain of another standards body. Magnus replied that we need to discuss this with other 3GPP folks. Qiaobing suggested moving the table into an appendix to make it clear that it's not part of our definition? No conclusion was reached. The RTP payload format for EVRC speech (draft-ietf-avt-evrc-01.txt) was presented by Adam Li. After providing a summary of the codec, Adam noted that it was brought to our attention in San Diego that the ITU has an alternative packetisation. After discussion and consultation with several ITU participants, it was decided to continue here, and take the result to ITU. There were several changes from the previous version of this payload format. It now states that you SHOULD NOT bundle more frames than would fit into the packet MTU (rather than MUST NOT). The text stating "MUST never set the M bit" has been changed to "It is recommended that the marker bit should not be set". It is unclear what is to be gained by this. Perhaps it would be better to say that applications may choose to not set this bit to help with header compression? The limit of 10 frames per packet has been relaxed: the number should be flexible, and signaled in SDP. Why does any maximum need to be specified? It is to accommodate buffer limitations on small devices. Steve Casner asked if this is not what the a=ptime SDP parameter is for? Philippe Gentric noted that same problem in exists with MPEG-4. The discussion continued for some time, about the possibility of using ptime instead, no conclusion was reached. The main concern is that ptime only recommends a length, rather than fixing a maximum. The restriction that the interleaving index can never increase without changing SSRC was relaxed: it can now change as long as it does not exceed the value specified in the SDP (again, due to limited buffer space). Why only one bit for "reduce rate" when there are multiple modes? Wouldn't you want to signal which mode to switch to? This was in an earlier version, but it was decided that only one of the modes is implemented in most cases, so one bit was sufficient. The choice between a byte-aligned and non-aligned format was discussed at length, with a number of proposals: 1) reduce the header, so full rate frames fit without padding (but makes the start of payload non-byte aligned); 2) frame headers are shortened to 4 bits each and can be stacked together in a TOC at start of frame, providing a similar bandwidth saving to the first approach; 3) restrict to one frame per packet with no payload header. Steve Casner noted the tradeoff between greater flexibility or constraining to one choice. There is no absolute way to decide this question. Discussion ensued and was eventually curtailed due to lack of time, with the suggestion that it move to the mailing list. If conclusion cannot be reached the authors either have to make a choice and see if it is accepted, or accept that there will be multiple modes and implementers have to choose. The RTP Payload Format for Vorbis Encoded Audio was presented by Jack Moffitt (draft-moffitt-vorbis-rtp-00.txt). After giving a brief overview of the Vorbis codec and payload format, the author noted that the big issue is transport of the code-books, which are variable size, large (up to 8k), and need to be sent reliably. Whilst it is certainly possible to send them at the beginning of a session, this does not handle changes during the stream (e.g. an Internet radio station is likely to need to send new codebooks when switching between pre-recorded tracks). There are a number of options: carrousel them, request via RTCP and resend, or send a code-book only stream. Steve Casner noted that sending a separate stream makes most sense: if sent inline, the timestamps and sequence numbers of the data packets will be perturbed, and by sending out of band, we can use a different protocol (e.g. TCP or reliable multicast). He also noted that the M bit definition does not follow the convention for audio, and that there is plenty of room to carry the desired bit in the payload header instead so the M bit could be as usual. Stephan Wenger suggested that if you change codebooks on the fly, it is best to send them in a different transport stream. He asked is there anything in the headers of the data packet saying which codebook to use? How do you associate codebooks with data packets? Steve Casner suggested relating them to the RTP timestamp. Ross Finlayson asked if there is something in the frames which points to which codebook is used? Yes, but that indexes into the table which is updated by the codebooks which are sent, so it doesn't help much. Ross also agreed that using a separate protocol is the correct approach. Marshall Eubanks noted that the trouble with this is that any packet could, in theory, have a different codebook; and this can blow your bandwidth allocation. Steve Casner agreed, but noted that it doesn't matter if these are sent in one stream or two, since this bandwidth is the same in both cases. Henning Schulzrinne asked if there is a finite universe of codebooks, or is it infinite? (If finite, we can just send the index to the well known table and not worry about sending them at run-time). Jack Moffitt replied that the set of codebooks is infinite, so you can't just index into the fixed set. (There are tools to generating optimized codebooks.) Steve Casner noted that this is another reason for separate transmission, so you can cache codebooks or request them in advance. Catherine Roux presented an initial RTP payload format for MPEG-4 FlexMux (draft-curet-avt-rtp-mpeg4-flexmux-00.txt). This is a very early draft, and there are many issues to be resolved: why is the signaling descriptor using a non-obvious range? Because those numbers are those used in FlexMux already (are other values valid?) The "a=mpeg4-flexmuxinfo:" SDP attribute should be an "a=fmtp:" attribute. The balance between in-band signaling and initialisation signaling has to be resolved. The FlexMux descriptors tag values assignment needs to be resolved. The dynamic FlexMux reconfiguration needs to be resolved. Steve Casner expressed concern about reliability requirements. Stephan Wenger noted that the draft is unclear about one channel with muxed data, or two channels (one for control, one for data). Stephan also noted that FlexMux data has to be an integer number of FlexMux packets and recommended that the authors look at the Gentric draft for fragmentation rules, etc. The RTP payload format for MPEG-4 SL was presented by Philippe Gentric. He started by noting that a new profile, draft-gentric-avt-profile-00.txt was proposed, but abandoned since the use of additional marker bits broke header compression. Steve Casner said he hoped that header compression can be adapted to work with this sort of thing, since this profile could possibly have made transport more efficient (but these gains are nullified if header compression doesn't work). Philippe described the other changes to the draft: description of transformation of SL headers into "mapped SL header" and "remaining SL header" portions. This makes the description much cleaner, and separates out those parts for which MPEG systems knowledge is required from those all applications are expected to know about. New SDP parameters are specified and the text clarifies when various SDP parameters are needed, which are optional, etc. This specification has been adapted so that for video streams in single SL mode you can make the packet format be identical on the wire to RFC3016. For multiple-SL mode, the headers are reordered so all mapped headers come before all remaining SL headers; several additional SL parameters were added. Loss of BIFS packets is noted as being a problem, but a carrousel scheme exists in MPEG-4 (and the BIFS streams have random access points anyway). The draft also mentions reliable transport for the initial data. Steve Casner noted that he has a couple of pages of editorial comments. The draft is getting there, but it's complex. To proceed: 1) the draft should not mandate use of SDP, instead it should specify the required parameters and give SDP as an example signaling protocol; 2) the scene description and loss discussion is not sufficient (Gentric disagrees, saying this exactly fits the design of the system). Stephan Wenger likes section 5.1 (BIFS) and section 9 (Examples). One technical issue: doesn't like mandating a non-random (zero) initial timestamp. He suggests allowing the initial timestamp to be random, and transmitting the offset in SDP instead? Steve Casner countered that the SDP may come from a different level of the application that has no way to know the initial timestamp. Stephan also asked about section 9.5.1 on inserting OCR: why is this needed? (This seems to be a misunderstanding of the draft - needs clarification). The MPEG-4 Committee has forwarded a liaison statement saying the payload format for MPEG-4 SL streams is complete. Whilst major progress has been made, it is clear that there are a relatively small number of technical issues to resolve, and a fairly large number of editorial clarifications. We expect this to be completed by the time of the London meeting. Charter bashing and other work was omitted due to lack of time. A message outlining the issues was sent to the mailing list, and a new charter based on this is under discussion with the area directors. From rem-conf Fri Apr 13 11:34:26 2001 From rem-conf-request@es.net Fri Apr 13 11:34:25 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14o8Og-0004xa-00; Fri, 13 Apr 2001 11:34:18 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14o8Oe-0004xQ-00; Fri, 13 Apr 2001 11:34:16 -0700 Received: from mailhub.fokus.gmd.de ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Fri, 13 Apr 2001 11:34:15 -0700 Received: from fokus.gmd.de (dial-03 [193.174.152.252]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA08729; Fri, 13 Apr 2001 20:33:55 +0200 (MET DST) Message-ID: <3AD747AF.6060802@fokus.gmd.de> Date: Fri, 13 Apr 2001 20:38:39 +0200 From: sisalem User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en, de-de, ar MIME-Version: 1.0 To: tme@21rst-century.com CC: csljc@ust.hk, "rem-conf@es.net" Subject: Re: RTT estimation for multicast References: <200104120804.f3C846M16086@smtp.ust.hk> <3AD58830.1B04CA5@21rst-century.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list while RTCP does give a usefull method for RTT estimation it does so only for senders. If the receivers need to estimate RTT as well you will need something more. Now the resason why the receivers need to know the RTT to the sender might vary but estimating the TCP-friendly rate the sender should be using is surely one, another is simply the need to collect path statistics to control if we are getting the service we were expecting. Now we can discuss rather longly whether these features are really needed-and we actually did this a few times at least for the TCP-friendly stuff. If we agreed that the receivers of a large multicast group want to know the RTT to the sender, the RTCP methods simply do not scale (even with reconsideration) that is if we want to get the estimation in a timely manner (i.e., every a few seconds). Our MLDA appraoch is a first step that we probably need to further refine as it is still based on supression (i.e., many-to-many communication while we seem to be heading to a one-to-many solutions) but the results we have achieved are encouraging. Regards Marshall Eubanks wrote: > Use RTCP. Remember, you do NOT need to know > anything about the receiver's clock to estimate a RTT. > > >From draft-ietf-avt-rtp-new-09.txt > > (from section 4) > > Wallclock time (absolute date and time) is represented using the > timestamp format of the Network Time Protocol (NTP), which is in > seconds relative to 0h UTC on 1 January 1900 [11]. The full > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > the integer part in the first 32 bits and the fractional part in the > last 32 bits. In some fields where a more compact representation is > appropriate, only the middle 32 bits are used; that is, the low 16 > bits of the integer part and the high 16 bits of the fractional part. > The high 16 bits of the integer part must be determined > independently. > > and (From 6.4.1) > > Let SSRC_r denote the receiver issuing this receiver > report. Source SSRC_n can compute the round-trip > propagation delay to SSRC_r by recording the time A when > this reception report block is received. It calculates the > total round-trip time A-LSR using the last SR timestamp > (LSR) field, and then subtracting this field to leave the > round-trip propagation delay as (A- LSR - DLSR). This is > illustrated in Fig. 2. > > > Remember, though, that in the real Internet multicast routing will frequently be asymmetric, and > will commonly be different than for unicast traffic, which might cause problems depending > on what you want to do. > > Rito Ljc wrote: > >> Can any one give some directions on how to efficiently estimate Round-trip time >> for each receivers in a mulciast environment. >> >> Thanks > From rem-conf Fri Apr 13 16:14:09 2001 From rem-conf-request@es.net Fri Apr 13 16:14:07 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14oClN-00011o-00; Fri, 13 Apr 2001 16:14:01 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14oClL-00011e-00; Fri, 13 Apr 2001 16:13:59 -0700 Received: from web-2.star2.net ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Fri, 13 Apr 2001 16:13:58 -0700 Received: from 21rst-century.com (1Cust123.tnt4.lorton.va.da.uu.net [63.24.102.123]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Fri, 13 Apr 2001 19:24:16 -0400 Message-ID: <3AD78879.F37141FA@21rst-century.com> Date: Fri, 13 Apr 2001 19:15:06 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: sisalem , Colin Perkins , Bill Fenner CC: csljc@ust.hk, "rem-conf@es.net" Subject: Re: RTT estimation for multicast References: <200104120804.f3C846M16086@smtp.ust.hk> <3AD58830.1B04CA5@21rst-century.com> <3AD747AF.6060802@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sisalem; As we move to SSM, we plan to set up a secondary SSM group from the source with information from the receiver reports. We will not be multicasting out all receiver reports, but some sort of aggregated information for people interested in doing multicast network monitoring (which is much more in need of work than estimating RTT's, IMHO). Anyone who has any suggestions on what information it would be useful to provide to the world at large for monitoring should e-mail me. Regards Marshall Eubanks sisalem wrote: > > while RTCP does give a usefull method for RTT estimation it does so only > for senders. If the receivers need to estimate RTT as well you will need > something more. Now the resason why the receivers need to know the RTT > to the sender might vary but estimating the TCP-friendly rate the sender > should be using is surely one, another is simply the need to collect > path statistics to control if we are getting the service we were > expecting. Now we can discuss rather longly whether these features are > really needed-and we actually did this a few times at least for the > TCP-friendly stuff. > > If we agreed that the receivers of a large multicast group want to know > the RTT to the sender, the RTCP methods simply do not scale (even with > reconsideration) that is if we want to get the estimation in a timely > manner (i.e., every a few seconds). Our MLDA appraoch is a first step > that we probably need to further refine as it is still based on > supression (i.e., many-to-many communication while we seem to be heading > to a one-to-many solutions) but the results we have achieved are > encouraging. > > Regards > > Marshall Eubanks wrote: > > > Use RTCP. Remember, you do NOT need to know > > anything about the receiver's clock to estimate a RTT. > > > > >From draft-ietf-avt-rtp-new-09.txt > > > > (from section 4) > > > > Wallclock time (absolute date and time) is represented using the > > timestamp format of the Network Time Protocol (NTP), which is in > > seconds relative to 0h UTC on 1 January 1900 [11]. The full > > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > > the integer part in the first 32 bits and the fractional part in the > > last 32 bits. In some fields where a more compact representation is > > appropriate, only the middle 32 bits are used; that is, the low 16 > > bits of the integer part and the high 16 bits of the fractional part. > > The high 16 bits of the integer part must be determined > > independently. > > > > and (From 6.4.1) > > > > Let SSRC_r denote the receiver issuing this receiver > > report. Source SSRC_n can compute the round-trip > > propagation delay to SSRC_r by recording the time A when > > this reception report block is received. It calculates the > > total round-trip time A-LSR using the last SR timestamp > > (LSR) field, and then subtracting this field to leave the > > round-trip propagation delay as (A- LSR - DLSR). This is > > illustrated in Fig. 2. > > > > > > Remember, though, that in the real Internet multicast routing will frequently be asymmetric, and > > will commonly be different than for unicast traffic, which might cause problems depending > > on what you want to do. > > > > Rito Ljc wrote: > > > >> Can any one give some directions on how to efficiently estimate Round-trip time > >> for each receivers in a mulciast environment. > >> > >> Thanks > > -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Sat Apr 14 15:04:20 2001 From rem-conf-request@es.net Sat Apr 14 15:04:19 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14oY9O-0002Ql-00; Sat, 14 Apr 2001 15:04:14 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14oY9M-0002QM-00; Sat, 14 Apr 2001 15:04:12 -0700 Received: from smtp1.radiant.net ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Sat, 14 Apr 2001 15:04:12 -0700 Received: (qmail 10550 invoked from network); 15 Apr 2001 00:06:58 -0000 Received: from radiant.net (207.194.200.18) by 216-21-129-155.ip.van.radiant.net with SMTP; 15 Apr 2001 00:06:58 -0000 Received: from santrajlxnsyoo [208.181.72.94] by radiant.net (SMTPD32-6.05) id A81E9360066; Sat, 14 Apr 2001 14:58:54 -0700 Reply-To: From: "Shashi Kant" To: Subject: Indians of Silicon Valley - Interesting articel from Fortune Date: Sat, 14 Apr 2001 14:55:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi guys Very interesting article from Fortune about the Indians of Silicon Valley http://www.fortune.com/indexw.jhtml?channel=artcol.jhtml&doc_id=00001216 Thanks Shashi From rem-conf Mon Apr 16 08:20:27 2001 From rem-conf-request@es.net Mon Apr 16 08:20:26 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pAnd-0004wP-00; Mon, 16 Apr 2001 08:20:21 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pAnb-0004wF-00; Mon, 16 Apr 2001 08:20:19 -0700 Received: from east.isi.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 16 Apr 2001 08:20:18 -0700 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA00232; Mon, 16 Apr 2001 11:20:06 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f3GFKBP29574; Mon, 16 Apr 2001 11:20:11 -0400 Message-Id: <200104161520.f3GFKBP29574@chiron.east.isi.edu> To: tme@21rst-century.com cc: sisalem , Bill Fenner , csljc@ust.hk, "rem-conf@es.net" Subject: Re: RTT estimation for multicast In-Reply-To: Your message of "Fri, 13 Apr 2001 19:15:06 EDT." <3AD78879.F37141FA@21rst-century.com> Date: Mon, 16 Apr 2001 11:20:11 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm curious to more fully explore your decision not to multicast out the receiver reports, since they would be relatively low bandwidth. If you did that, you could run the standard RTCP algorithms for an SSM session, with only the address to send RTCP to changed. That would seem to be a deployment win? Colin --> Marshall Eubanks writes: >Dear Sisalem; > >As we move to SSM, we plan to set up a secondary SSM group from the source >with information from the receiver reports. We will not be multicasting out >all receiver reports, but some sort of aggregated information for people >interested in doing multicast network monitoring (which is much more in need >of work than estimating RTT's, IMHO). > >Anyone who has any suggestions on what information it would be useful >to provide to the world at large for monitoring should e-mail me. > > > Regards > Marshall Eubanks > > > >sisalem wrote: >> >> while RTCP does give a usefull method for RTT estimation it does so only >> for senders. If the receivers need to estimate RTT as well you will need >> something more. Now the resason why the receivers need to know the RTT >> to the sender might vary but estimating the TCP-friendly rate the sender >> should be using is surely one, another is simply the need to collect >> path statistics to control if we are getting the service we were >> expecting. Now we can discuss rather longly whether these features are >> really needed-and we actually did this a few times at least for the >> TCP-friendly stuff. >> >> If we agreed that the receivers of a large multicast group want to know >> the RTT to the sender, the RTCP methods simply do not scale (even with >> reconsideration) that is if we want to get the estimation in a timely >> manner (i.e., every a few seconds). Our MLDA appraoch is a first step >> that we probably need to further refine as it is still based on >> supression (i.e., many-to-many communication while we seem to be heading >> to a one-to-many solutions) but the results we have achieved are >> encouraging. >> >> Regards >> >> Marshall Eubanks wrote: >> >> > Use RTCP. Remember, you do NOT need to know >> > anything about the receiver's clock to estimate a RTT. >> > >> > >From draft-ietf-avt-rtp-new-09.txt >> > >> > (from section 4) >> > >> > Wallclock time (absolute date and time) is represented using the >> > timestamp format of the Network Time Protocol (NTP), which is in >> > seconds relative to 0h UTC on 1 January 1900 [11]. The full >> > resolution NTP timestamp is a 64-bit unsigned fixed-point number with >> > the integer part in the first 32 bits and the fractional part in the >> > last 32 bits. In some fields where a more compact representation is >> > appropriate, only the middle 32 bits are used; that is, the low 16 >> > bits of the integer part and the high 16 bits of the fractional part. >> > The high 16 bits of the integer part must be determined >> > independently. >> > >> > and (From 6.4.1) >> > >> > Let SSRC_r denote the receiver issuing this receiver >> > report. Source SSRC_n can compute the round-trip >> > propagation delay to SSRC_r by recording the time A when >> > this reception report block is received. It calculates the >> > total round-trip time A-LSR using the last SR timestamp >> > (LSR) field, and then subtracting this field to leave the >> > round-trip propagation delay as (A- LSR - DLSR). This is >> > illustrated in Fig. 2. >> > >> > >> > Remember, though, that in the real Internet multicast routing will frequently be asymmetric, a >nd >> > will commonly be different than for unicast traffic, which might cause problems depending >> > on what you want to do. >> > >> > Rito Ljc wrote: >> > >> >> Can any one give some directions on how to efficiently estimate Round-trip time >> >> for each receivers in a mulciast environment. >> >> >> >> Thanks >> > > >-- > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > > Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Mon Apr 16 09:25:55 2001 From rem-conf-request@es.net Mon Apr 16 09:25:54 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pBoz-0001AP-00; Mon, 16 Apr 2001 09:25:49 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pBow-0001AF-00; Mon, 16 Apr 2001 09:25:46 -0700 Received: from sippie.star2.net ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Mon, 16 Apr 2001 09:25:45 -0700 Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Mon, 16 Apr 2001 12:23:09 -0400 Received: from 21rst-century.com (1Cust186.tnt2.lorton.va.da.uu.net [63.23.103.186]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Mon, 16 Apr 2001 12:35:37 -0400 Message-ID: <3ADB1D5A.92A54E2A@21rst-century.com> Date: Mon, 16 Apr 2001 12:27:07 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: sisalem , Bill Fenner , csljc@ust.hk, "rem-conf@es.net" , Tech team , Julian Chesterfield Subject: Re: RTT estimation for multicast References: <200104161520.f3GFKBP29574@chiron.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin; Colin Perkins wrote: > > I'm curious to more fully explore your decision not to multicast out the > receiver reports, since they would be relatively low bandwidth. If you did > that, you could run the standard RTCP algorithms for an SSM session, with > only the address to send RTCP to changed. > This is basically Julian's idea - draft-chesterfield-avt-rtcpssm-00.txt - and I think it has merit if you want to run many to many type services using SSM. That's not what I was getting at, though. Let's get specific. We are multicasting 3 x 38 samples (packets) per second at our high data rate. For now we are using standard RTCP RR's. For licensing and advertising purposes it is essential that any receiver report interval be kept to about 100 seconds or less. (You might push that by a factor of 2, maybe, but this will really start to impact on the business utility of these reports. 100 seconds seems a good upper bound on this.) Our receiver reports include reports on at most 3 separate substreams, so they are in length IP (4 x 32 bits) + UDP (2 x 32 bits) + RR header (2 x 32 bits) + 3 x (6 x 32 bits) = 26 x 32 bits = 832 bits or 104 bytes. If we assume a minimum reporting rate of 0.01 Hz (i.e., one per 100 seconds) then Audience Size | Minimum Bit Rate Returned 1000 8 kbps 10,000 80 kbps 100,000 800 kbps 1,000,000 8 mbps Now, the receiver report RTCP packet basically only includes low order information about packet loss and jitter. (And jitter is frequently trashed anyway.) If we were sending packets to Mars over a deep space link, this would be sufficient to tell us everything we might want to know about packet losses. We're not, and recently certain non-random packet loss patterns (see http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example ) have convinced me that more information needs to be supplied. As we discussed briefly when you came over to our offices, one way of doing this would be to send a bit pattern for every packet that should have been received during the RR interval. Suppose, for example, that you are sending 38 packets per second, and the RR interval is 100 seconds. Then the RR will cover 3800 packets (and will completely obscure the pattern shown in u_oregon.12_apr.gif). You could then send 3800 bits (or a little fewer, as packets that should have arrived after the last packet that did arrive will of necessity be missed), in the form 11110111110111111111011111000000000001 etc., where 1 means the packet was received, 0 means it wasn't (this represents one second of traffic, btw.) If you send this naively, as such a bit pattern, then the RR packet will be ~ 832 bits + (3 x 3800 bits) = 12,232 bits or 1529 bytes. Now the minimum returned bit rate becomes Audience Size | Minimum Bit Rate Returned 1000 120 kbps 10,000 1.2 mbps 100,000 12 mbps 1,000,000 122 mbps This is a real hit, and suggests that more thought should be given to this area - maybe the loss bit patterns could be compressed. either losslessly or lossily, say by applying a Walsh transform and only sending a certain number of coefficients in order of size, or by sending the location of the largest continuous block of dropped packet, by using runs of zeros and ones or by some other means. (A different means would be to have the source inform the sender in the stream that the RR report rate should be changed.) In any case, for an audience size of 100,000, the RTCP RR bit rate will be _at least_ order 1 megabit per second. Now, for a broadcaster receiving SSM receiver reports, that's OK. Anyone with that size audience can afford that much bandwidth. If we then set up a SSM group sending out 1 mbps of receiver reports, who would want to receive it ? Who would want to get that much bandwidth ? My guess is, no actual receivers, and very few monitoring groups. My assumption is that both from the broadcasters end and the monitoring groups end, some aggregation (compression) would be desired. The one that came to our minds was to average loss on a per AS basis, as receivers tend to be (so far) highly clustered in terms of ASNs. I think that you will find strong resistance on the part of broadcasters to sharing all information (including IP addresses) for all receivers at all time to everyone. This information is simply too valuable to assume that this will fly. (Seen any RR from Real Networks lately ?) I do not think that these kind of aggregated RR information (and the current RTCP RR's represent one particular kind of aggregation) will serve to diagnose ALL network problems. That is just not realistic. The goal should be to set up sufficient information sharing to serve as an early warning of most problems, hopefully able to diagnose at least some, and to get this established as a BCP. I think that it will be difficult enough to keep multicasting flowing smoothly that there is a chance of establishing this as a principle. Otherwise I can guarantee you that such information will be treated as proprietary and not revealed at all. Regards Marshall > That would seem to be a deployment win? > > Colin > > --> Marshall Eubanks writes: > >Dear Sisalem; > > > >As we move to SSM, we plan to set up a secondary SSM group from the source > >with information from the receiver reports. We will not be multicasting out > >all receiver reports, but some sort of aggregated information for people > >interested in doing multicast network monitoring (which is much more in need > >of work than estimating RTT's, IMHO). > > > >Anyone who has any suggestions on what information it would be useful > >to provide to the world at large for monitoring should e-mail me. > > > > > > Regards > > Marshall Eubanks > > > > > > > >sisalem wrote: > >> > >> while RTCP does give a usefull method for RTT estimation it does so only > >> for senders. If the receivers need to estimate RTT as well you will need > >> something more. Now the resason why the receivers need to know the RTT > >> to the sender might vary but estimating the TCP-friendly rate the sender > >> should be using is surely one, another is simply the need to collect > >> path statistics to control if we are getting the service we were > >> expecting. Now we can discuss rather longly whether these features are > >> really needed-and we actually did this a few times at least for the > >> TCP-friendly stuff. > >> > >> If we agreed that the receivers of a large multicast group want to know > >> the RTT to the sender, the RTCP methods simply do not scale (even with > >> reconsideration) that is if we want to get the estimation in a timely > >> manner (i.e., every a few seconds). Our MLDA appraoch is a first step > >> that we probably need to further refine as it is still based on > >> supression (i.e., many-to-many communication while we seem to be heading > >> to a one-to-many solutions) but the results we have achieved are > >> encouraging. > >> > >> Regards > >> > >> Marshall Eubanks wrote: > >> > >> > Use RTCP. Remember, you do NOT need to know > >> > anything about the receiver's clock to estimate a RTT. > >> > > >> > >From draft-ietf-avt-rtp-new-09.txt > >> > > >> > (from section 4) > >> > > >> > Wallclock time (absolute date and time) is represented using the > >> > timestamp format of the Network Time Protocol (NTP), which is in > >> > seconds relative to 0h UTC on 1 January 1900 [11]. The full > >> > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > >> > the integer part in the first 32 bits and the fractional part in the > >> > last 32 bits. In some fields where a more compact representation is > >> > appropriate, only the middle 32 bits are used; that is, the low 16 > >> > bits of the integer part and the high 16 bits of the fractional part. > >> > The high 16 bits of the integer part must be determined > >> > independently. > >> > > >> > and (From 6.4.1) > >> > > >> > Let SSRC_r denote the receiver issuing this receiver > >> > report. Source SSRC_n can compute the round-trip > >> > propagation delay to SSRC_r by recording the time A when > >> > this reception report block is received. It calculates the > >> > total round-trip time A-LSR using the last SR timestamp > >> > (LSR) field, and then subtracting this field to leave the > >> > round-trip propagation delay as (A- LSR - DLSR). This is > >> > illustrated in Fig. 2. > >> > > >> > > >> > Remember, though, that in the real Internet multicast routing will frequently be asymmetric, a > >nd > >> > will commonly be different than for unicast traffic, which might cause problems depending > >> > on what you want to do. > >> > > >> > Rito Ljc wrote: > >> > > >> >> Can any one give some directions on how to efficiently estimate Round-trip time > >> >> for each receivers in a mulciast environment. > >> >> > >> >> Thanks > >> > Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Mon Apr 16 10:23:25 2001 From rem-conf-request@es.net Mon Apr 16 10:23:23 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pCib-00059I-00; Mon, 16 Apr 2001 10:23:17 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pCiZ-000598-00; Mon, 16 Apr 2001 10:23:15 -0700 Received: from mail-green.research.att.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 16 Apr 2001 10:23:13 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id DF1BF1E041; Mon, 16 Apr 2001 13:23:12 -0400 (EDT) Received: from research.att.com ([135.197.2.51]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA05220; Mon, 16 Apr 2001 13:23:08 -0400 (EDT) Sender: julian@research.att.com Message-ID: <3ADB2A12.CD033FD9@research.att.com> Date: Mon, 16 Apr 2001 10:21:22 -0700 From: Julian Chesterfield Organization: AT&T Labs X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: tme@21rst-century.com Cc: Colin Perkins , sisalem , Bill Fenner , csljc@ust.hk, "rem-conf@es.net" , Tech team , Joerg Ott Subject: Re: RTT estimation for multicast References: <200104161520.f3GFKBP29574@chiron.east.isi.edu> <3ADB1D5A.92A54E2A@21rst-century.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Marshall, I agree with your concerns about the scalability/usefulness of all the RTCP data for very large groups of receivers. I'm sure content providers will have different concerns about what information, if any, they want to share regarding group membership etc.. I can see how summarising RR's by AS might be useful, but I can also see how this information could be sensitive and hard to obtain. Perhaps we need to define a solution which leaves the method of feedback to the discretion of the source. In this way, the source could simply forward all RTCP information to the whole group (scaling algorithm works as usual), or the source can control the feedback in a different manner such as specifying the size of the group and listing all SSRCs currently active with a summary of packet loss, jitter etc... (as a minimum receivers must know all the SSRCs or have some method of negotiating an SSRC which is unused). Another option for the source may be to explicitly control which receivers should provide feedback. That way, in instances such as the one you described in your message, the source, or a designated feedback monitor, could focus on feedback from a receiver that is experiencing high levels of loss at more frequent intervals for example. These are just some suggestions, obviously the down side to this is that there is no single algorithm for feedback making implementation/specification more complicated as well as introducing issues with backwards compatibility. But perhaps this is necessary if groups are going to scale to the sizes you are indicating. Thanks, Julian Chesterfield > Dear Colin; > > Colin Perkins wrote: > > > > I'm curious to more fully explore your decision not to multicast out the > > receiver reports, since they would be relatively low bandwidth. If you did > > that, you could run the standard RTCP algorithms for an SSM session, with > > only the address to send RTCP to changed. > > > > This is basically Julian's idea - > draft-chesterfield-avt-rtcpssm-00.txt - and I think it has merit if you want to run > many to many type services using SSM. That's not what I was getting at, though. > > Let's get specific. We are multicasting 3 x 38 samples (packets) per second at our high > data rate. For now we are using standard RTCP RR's. For licensing and advertising purposes it is > essential that any receiver report interval be kept to about 100 seconds > or less. (You might push that by a factor of 2, maybe, but > this will really start to impact on the business utility of these reports. > 100 seconds seems a good upper bound on this.) > > Our receiver reports include reports on at most 3 separate substreams, so > they are in length > > IP (4 x 32 bits) + UDP (2 x 32 bits) + RR header (2 x 32 bits) + 3 x (6 x 32 bits) = > 26 x 32 bits = 832 bits or 104 bytes. > > If we assume a minimum reporting rate of 0.01 Hz (i.e., one per 100 seconds) then > > Audience Size | Minimum Bit Rate Returned > 1000 8 kbps > 10,000 80 kbps > 100,000 800 kbps > 1,000,000 8 mbps > > Now, the receiver report RTCP packet basically only > includes low order information about packet loss and jitter. (And jitter is frequently trashed anyway.) > If we were sending packets to Mars over a deep space link, this would be sufficient to > tell us everything we might want to know about packet losses. We're not, and > recently certain non-random packet loss patterns (see > > http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example ) > > have convinced me that > more information needs to be supplied. As we discussed briefly when you came over > to our offices, one way of doing this would be to send a bit pattern for every packet that should > have been received during the RR interval. > > Suppose, for example, that you are sending 38 packets per second, and the RR interval is 100 seconds. > Then the RR will cover 3800 packets (and will completely obscure the pattern shown in u_oregon.12_apr.gif). > You could then send 3800 bits (or a little fewer, as packets that should have > arrived after the last packet that did arrive will of necessity be missed), in the form > 11110111110111111111011111000000000001 etc., where 1 means the packet was received, 0 means it wasn't (this represents > one second of traffic, btw.) > > If you send this naively, as such a bit pattern, then the RR packet will be ~ 832 bits + (3 x 3800 bits) = 12,232 bits or 1529 bytes. > Now the minimum returned bit rate becomes > > Audience Size | Minimum Bit Rate Returned > 1000 120 kbps > 10,000 1.2 mbps > 100,000 12 mbps > 1,000,000 122 mbps > > This is a real hit, and suggests that more thought should be given to this area - maybe the loss bit > patterns could be compressed. either losslessly or lossily, say by applying a Walsh transform and only > sending a certain number of coefficients in order of size, or by sending the location of the largest > continuous block of dropped packet, by using runs of zeros and ones or by some other means. (A different > means would be to have the source inform the sender in the stream that the RR report rate should be changed.) > > In any case, for an audience size of 100,000, the RTCP RR bit rate will be _at least_ order 1 megabit per second. > Now, for a broadcaster receiving SSM receiver reports, that's OK. Anyone with that size audience can afford > that much bandwidth. If we then set up a SSM group sending out 1 mbps of receiver reports, who would > want to receive it ? Who would want to get that much bandwidth ? My guess is, no actual receivers, and > very few monitoring groups. > > My assumption is that both from the broadcasters end and the monitoring groups end, some aggregation (compression) > would be desired. The one that came to our minds was to average loss on a per AS basis, as receivers tend > to be (so far) highly clustered in terms of ASNs. > > I think that you will find strong resistance on the part of broadcasters to sharing all information (including IP addresses) for > all receivers at all time to everyone. This information is simply too valuable to assume that this will fly. (Seen any > RR from Real Networks lately ?) > > I do not think that these kind of aggregated RR information (and the current RTCP RR's > represent one particular kind of aggregation) will serve to diagnose ALL network problems. That > is just not realistic. The goal should be to set up sufficient information sharing to serve as an early warning of > most problems, hopefully able to diagnose at least some, and to get this established as a BCP. > I think that it will be difficult enough to keep multicasting flowing smoothly that there is a chance > of establishing this as a principle. Otherwise I can guarantee you that such information will be treated as > proprietary and not revealed at all. > > Regards > Marshall > > > That would seem to be a deployment win? > > > > Colin > > > > --> Marshall Eubanks writes: > > >Dear Sisalem; > > > > > >As we move to SSM, we plan to set up a secondary SSM group from the source > > >with information from the receiver reports. We will not be multicasting out > > >all receiver reports, but some sort of aggregated information for people > > >interested in doing multicast network monitoring (which is much more in need > > >of work than estimating RTT's, IMHO). > > > > > >Anyone who has any suggestions on what information it would be useful > > >to provide to the world at large for monitoring should e-mail me. > > > > > > > > > Regards > > > Marshall Eubanks > > > > > > > > > > > >sisalem wrote: > > >> > > >> while RTCP does give a usefull method for RTT estimation it does so only > > >> for senders. If the receivers need to estimate RTT as well you will need > > >> something more. Now the resason why the receivers need to know the RTT > > >> to the sender might vary but estimating the TCP-friendly rate the sender > > >> should be using is surely one, another is simply the need to collect > > >> path statistics to control if we are getting the service we were > > >> expecting. Now we can discuss rather longly whether these features are > > >> really needed-and we actually did this a few times at least for the > > >> TCP-friendly stuff. > > >> > > >> If we agreed that the receivers of a large multicast group want to know > > >> the RTT to the sender, the RTCP methods simply do not scale (even with > > >> reconsideration) that is if we want to get the estimation in a timely > > >> manner (i.e., every a few seconds). Our MLDA appraoch is a first step > > >> that we probably need to further refine as it is still based on > > >> supression (i.e., many-to-many communication while we seem to be heading > > >> to a one-to-many solutions) but the results we have achieved are > > >> encouraging. > > >> > > >> Regards > > >> > > >> Marshall Eubanks wrote: > > >> > > >> > Use RTCP. Remember, you do NOT need to know > > >> > anything about the receiver's clock to estimate a RTT. > > >> > > > >> > >From draft-ietf-avt-rtp-new-09.txt > > >> > > > >> > (from section 4) > > >> > > > >> > Wallclock time (absolute date and time) is represented using the > > >> > timestamp format of the Network Time Protocol (NTP), which is in > > >> > seconds relative to 0h UTC on 1 January 1900 [11]. The full > > >> > resolution NTP timestamp is a 64-bit unsigned fixed-point number with > > >> > the integer part in the first 32 bits and the fractional part in the > > >> > last 32 bits. In some fields where a more compact representation is > > >> > appropriate, only the middle 32 bits are used; that is, the low 16 > > >> > bits of the integer part and the high 16 bits of the fractional part. > > >> > The high 16 bits of the integer part must be determined > > >> > independently. > > >> > > > >> > and (From 6.4.1) > > >> > > > >> > Let SSRC_r denote the receiver issuing this receiver > > >> > report. Source SSRC_n can compute the round-trip > > >> > propagation delay to SSRC_r by recording the time A when > > >> > this reception report block is received. It calculates the > > >> > total round-trip time A-LSR using the last SR timestamp > > >> > (LSR) field, and then subtracting this field to leave the > > >> > round-trip propagation delay as (A- LSR - DLSR). This is > > >> > illustrated in Fig. 2. > > >> > > > >> > > > >> > Remember, though, that in the real Internet multicast routing will frequently be asymmetric, a > > >nd > > >> > will commonly be different than for unicast traffic, which might cause problems depending > > >> > on what you want to do. > > >> > > > >> > Rito Ljc wrote: > > >> > > > >> >> Can any one give some directions on how to efficiently estimate Round-trip time > > >> >> for each receivers in a mulciast environment. > > >> >> > > >> >> Thanks > > >> > > > Multicast Technologies, Inc. > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@on-the-i.com http://www.on-the-i.com > > Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Mon Apr 16 20:30:28 2001 From rem-conf-request@es.net Mon Apr 16 20:30:28 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14pLxP-0007jo-00; Mon, 16 Apr 2001 20:15:11 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14pLxN-0007jO-00; Mon, 16 Apr 2001 20:15:09 -0700 Received: from va1.dslextreme.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 16 Apr 2001 20:15:08 -0700 Received: from scope (hyervision.com [64.165.147.162]) by va1.dslextreme.com (8.9.3/8.9.3) with SMTP id UAA17998; Mon, 16 Apr 2001 20:07:09 -0700 From: "Adam Li" To: "Ietf-Avt" Cc: "Colin Perkins" , "Marcello Lioy" , "Thomas Zeng" , "Greg Sherwood" , "'Stephen Casner'" , "'John D. Villasenor'" , "'Yung Lyul Lee'" , "'Jeong-Hoon Park'" , "'Keith Miller'" , "'Craig Greer'" , "'Tom Hiller'" , "'Peter J. McCann'" , "'David Leon'" , "'Nikolai Leung'" , "'Dan Gal'" , , , "'Lars-Erik Jonsson \(EPL\)'" , , "'Vivek Bhargava'" Subject: draft-ietf-avt-evrc-02.txt Date: Mon, 16 Apr 2001 20:12:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, We are submitting to the ID-manager the following Internet Draft, titled "An RTP Payload Format for EVRC Speech" from Ericsson, Lucent, Nokia, PacketVideo, Qualcomm, Samsung, and UCLA. The text of the Internet Draft is accessable by anonymous ftp at ftp://ftp.icsl.ucla.edu/pub/EVRC/draft-ietf-avt-evrc-02.txt. We have at least one issue that is not complete resolved that we would like to hear your comments and suggestions. For the Type 1 packet in the current draft, multiple codec frame data are in the order of [frame header][data block][frame header][data block] etc. It is proposed to put all the frame headers together in the starting of the packet as ToC (Table of Contents), and stack the data blocks in the rest of the packets. Current draft: interleaved header-data-header-data ... Proposed change: ToC (all the headers), all the data ... The difference in complexity and overhead is very minimum and negligible. So, it makes sense to choose one that follows the common practice and be consistant. However, the choice is not very obvious in this case. This current draft (loosely) follows RFC 2658, which did not use ToC. However, many other many other current formats in AVT bundle the headers together in the beginning of the packet. We would appreciate very much your comments and suggestion on this. Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) From rem-conf Mon Apr 16 22:11:45 2001 From rem-conf-request@es.net Mon Apr 16 22:11:43 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14pNiA-0000t9-00; Mon, 16 Apr 2001 22:07:34 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14pNi9-0000sz-00; Mon, 16 Apr 2001 22:07:33 -0700 Received: from scaup.mail.pas.earthlink.net ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 16 Apr 2001 22:07:32 -0700 Received: from hauraki.live.com (pool1152.cvx19-bradley.dialup.earthlink.net [209.179.248.132]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA18685 for ; Mon, 16 Apr 2001 22:07:31 -0700 (PDT) Message-Id: <4.3.1.1.20010416215023.00c39910@pop.earthlink.net> X-Sender: rossfinlayson@pop.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 16 Apr 2001 21:59:26 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: Re: RTT estimation for multicast In-Reply-To: <3ADB1D5A.92A54E2A@21rst-century.com> References: <200104161520.f3GFKBP29574@chiron.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:27 AM 4/16/01, Marshall Eubanks wrote: >If we were sending packets to Mars over a deep space link, this would be >sufficient to >tell us everything we might want to know about packet losses. We're not, and >recently certain non-random packet loss patterns (see > >http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example ) > >have convinced me that >more information needs to be supplied. This particular packet loss behavior is interesting - it shows that packet loss is occurring regularly, with a period of roughly 65 seconds. Does anyone know why this is occurring? It reminds me a little of the congestion patterns that Van Jacobson was seeing in the Internet in the late '80s (prior to instituting slow-start, etc.). If there's a systemic problem here, we should try to track it down and fix it. Ross. From rem-conf Tue Apr 17 03:46:08 2001 From rem-conf-request@es.net Tue Apr 17 03:46:06 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pSzg-00051q-00; Tue, 17 Apr 2001 03:46:00 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pSze-00051e-00; Tue, 17 Apr 2001 03:45:58 -0700 Received: from sippie.star2.net ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Tue, 17 Apr 2001 03:45:57 -0700 Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Tue, 17 Apr 2001 06:43:19 -0400 Received: from 21rst-century.com (1Cust172.tnt1.lorton.va.da.uu.net [63.23.102.172]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Tue, 17 Apr 2001 06:55:43 -0400 Message-ID: <3ADC1F39.37ABF649@21rst-century.com> Date: Tue, 17 Apr 2001 06:47:23 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ross Finlayson , Zaid Albanna , Dave Meyer CC: rem-conf@es.net Subject: Re: RTT estimation for multicast References: <200104161520.f3GFKBP29574@chiron.east.isi.edu> <4.3.1.1.20010416215023.00c39910@pop.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ross Finlayson wrote: > > At 09:27 AM 4/16/01, Marshall Eubanks wrote: > >If we were sending packets to Mars over a deep space link, this would be > >sufficient to > >tell us everything we might want to know about packet losses. We're not, and > >recently certain non-random packet loss patterns (see > > > >http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example ) > > > >have convinced me that > >more information needs to be supplied. > > This particular packet loss behavior is interesting - it shows that packet > loss is occurring regularly, with a period of roughly 65 seconds. > > Does anyone know why this is occurring? It reminds me a little of the > congestion patterns that Van Jacobson was seeing in the Internet in the > late '80s (prior to instituting slow-start, etc.). If there's a systemic > problem here, we should try to track it down and fix it. > > Ross. Hi Ross; We had a very similar 65 second periodicity problem with our vBNS link, which was occuring right at our first hop. I have attached an explaination from Zaid Albanna (now at Juniper) for this problem. The problem with the link to U Oregon is not on our vBNS link, is apparently not local to us, and actually has a period of 64 seconds. Dave Meyer has been working on it Plots in http://www.multicasttech.com/rr/ include http://www.multicasttech.com/rr/u_oregon.9_apr.gif http://www.multicasttech.com/rr/u_oregon.10_apr.gif http://www.multicasttech.com/rr/u_oregon.12_apr.gif http://www.multicasttech.com/rr/u_oregon.13_apr.gif http://www.multicasttech.com/rr/u_oregon.14_apr.gif http://www.multicasttech.com/rr/u_oregon.16_apr.gif It still seems to be present, but at a lower level (!). Multicast streaming is a more more demanding use of the Internet than e-mail or html. You could use the vBNS link to access web pages and not notice any problems. (Bill Owens of Nysernet discovered the vBNS problem by listening to the (unprotected) stream, which dropped every 65 seconds. Now that we use staggered erasure protection it plays through without dropping out through short periods of total packet loss, so that wouldn't work today :) The promise of multicast here is tomography of the Internet. I suspect that there are problems like this all over the place, and rtcp receiver reports will flush them out. As the audience grows, it will become ever more possible to localize the source of the problem, and, hopefully, get people to do something about them. The is why I think sharing some information about RTCP RR's globally will be a good idea, and has a chance to make BCP. BTW, further discussion of these specific problems really belongs on the MBoneD mailing list. Regards Marshall Date: Sat, 3 Mar 2001 15:06:49 -0800 From: "Zaid" To: Zaid wrote: > > Hi Marshal, > > I did not realize that at 4:00am :-). I went ahead and re-did it the correct > way. > As for the frame relay, We are still waiting to here if you were seeing > the problems again. What we fixed was a config parameter that was not set > properly. > When the circuit came up initially the timing on our ATM switch was derived > from the net (i.e. Verizon). We did a card swap which reset the config of > the > network timing parameter (FORE BUG) to internal. We corrected that by > reseting it back to be derived from the net. I cannot recall the symptoms of > the problem you were having, but the difference in the derived timing config > causes a shift in the clock, and that can lead to different symptoms > dependding > on the kind of traffic (data or audio/video). > > FYI, I am no longer woking for worldcom. I am now helping Juniper out > with multicast. Please feel free to drop any questions you have regarding > the network to vbns-eng@mci.net. > > Regards, > Zaid > Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Tue Apr 17 05:35:58 2001 From rem-conf-request@es.net Tue Apr 17 05:35:56 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pUhz-0000NW-00; Tue, 17 Apr 2001 05:35:51 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pUhx-0000NM-00; Tue, 17 Apr 2001 05:35:49 -0700 Received: from TYO202.gate.nec.co.jp ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Tue, 17 Apr 2001 05:35:47 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.9.3/3.7W01041220) with ESMTP id VAA05127; Tue, 17 Apr 2001 21:35:45 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP id VAA26880; Tue, 17 Apr 2001 21:35:45 +0900 (JST) Received: from mgw1.netlab.nec.co.jp (mgw1.netlab.nec.co.jp [133.201.4.10]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id VAA21844; Tue, 17 Apr 2001 21:35:44 +0900 (JST) Received: from mail.netlab.nec.co.jp (mail.netlab.nec.co.jp [172.16.3.22]) by mgw1.netlab.nec.co.jp (8.9.3/3.7W-MGW1_NETLAB) with ESMTP id VAA02261; Tue, 17 Apr 2001 21:35:44 +0900 (JST) Received: from splpe792.netlab.nec.co.jp (splpe792.netlab.nec.co.jp [172.16.161.39]) by mail.netlab.nec.co.jp (8.9.3/3.7W-MAIL.NETLAB) with ESMTP id VAA06646; Tue, 17 Apr 2001 21:35:44 +0900 (JST) Received: from splwp25 (splwp25.netlab.nec.co.jp [172.16.4.31]) by splpe792.netlab.nec.co.jp (8.9.3/3.7W06/29/00) with ESMTP id VAA02315; Tue, 17 Apr 2001 21:35:43 +0900 (JST) Date: Tue, 17 Apr 2001 21:35:46 +0900 From: Takuya Murakami To: Johan =?ISO-2022-JP?B?U2oOdg9iZXJn?= Subject: Re: draft-ietf-avt-rtp-amr-06.txt submitted Cc: rem-conf@es.net In-Reply-To: <3AC49CD0.E1DACB01@ericsson.com> References: <3AC49CD0.E1DACB01@ericsson.com> Message-Id: <20010417212456.5A3C.MURAKAMI@da.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello. I have a comment on draft-ietf-avt-rtp-amr-06.txt. I think the following code for robust sorting in page 14 is incorrect, because the variable l is not used. -------------------------------------------- /* payload frames */ for (j = 0; j < N; j++){ P(j) = F(j)%8 == 0 ? 0 : 8 - F(j)%8; } max = (max(F(0),..,F(N-1))-1)/8 +1; for (i = 0; i < max; i++){ for (j = 0; j < N; j++){ for (l = 0; l < 8; l++){ if (i < F(j)+P(j)){ if (i < F(j)){ b(k++) = f(j,i); }else{ b(k++) = 0; } } } } } --------------------------------------------- I believe correct code is following. -------------------------------------------- /* payload frames */ for (j = 0; j < N; j++){ P(j) = F(j)%8 == 0 ? 0 : 8 - F(j)%8; } max = (max(F(0),..,F(N-1))-1)/8 +1; for (i = 0; i < max; i+=8){ <--- for (j = 0; j < N; j++){ for (l = 0; l < 8; l++){ if (i+l < F(j)+P(j)){ <--- if (i+l < F(j)){ <--- b(k++) = f(j,i+l); <--- }else{ b(k++) = 0; } } } } } --------------------------------------------- Is this correct? ----- Takuya Murakami murakami@da.jp.nec.com From rem-conf Tue Apr 17 12:00:08 2001 From rem-conf-request@es.net Tue Apr 17 12:00:08 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14pafP-0000Nz-00; Tue, 17 Apr 2001 11:57:35 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14pafN-0000Np-00; Tue, 17 Apr 2001 11:57:34 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Tue, 17 Apr 2001 11:57:33 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id LAA11636; Tue, 17 Apr 2001 11:43:32 -0700 Message-ID: <3ADC8FFC.C2E2237B@bmrc.berkeley.edu> Date: Tue, 17 Apr 2001 11:48:29 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/18 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces, and Graphics Seminar bmrc.berkeley.edu/mig Perceptual Scheduling in Real-Time Music and Audio Applications PhD Dissertation April 18, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Amar Chaudhary Computer Science Division - EECS U.C. Berkeley Academic research of computer music and commercial sound systems is moving from special-purpose hardware towards software implementations on general-purpose computers. The enormous gains in general-purpose processor performance gives musicians and composers richer and more complex control of sound in their performances and compositions. Just a geometric modeling has given graphic designers more control of their scens and objects, (e.g., independent control of size, position and texture), sound synthesis allows more control of musical parameters such as duration, frequency and timbre. Examples of sound-synthesis algorithms include additive synthesis, resonance modeling, frequency-modulation(FM) synthesis and physical models. Applications, called synthesis servers, allow musicians to dynamically speecify models for these algorithms and synthesize sound from them in real time in response to user input. A synthesis server is an expressive, software-only musical instrument. However, the widespread use of synthesis servers has been frustrated by high computational requirements. This problem is particularly true of the sinusoidal and resonance models described in this dissertation. Typical sinusoidal and resonance models contain hundreds of elements, called partials, that together represent an approximation of the original sound. Even though computers are now running above the 1GHz clock rate, it is still not possible to use many large models in polyphonic or multi-channel settings. For example, a typical composition might include eight models with 120 partials each, or 960 partials total. Additionally, current operating systems do not guarantee quality of service (QoS) necessary for interactive real-time musical performance, particulary when the system is running at or near full computational capacity. Traditional approaches that pre-compute audio samples or perform optimal scheduling off line do not lend themselves to musical applications that are built dynamically and must be responsive to variations in live musical performance. We introduce a novel approach to reducing the computational requirements in real-time music applications, called perceptual scheduling, in which QoS guarantees are maintained using voluntary detected, the perceptual scheduler requests that the synthesis algorithms reduce computational requirements. Each algorithm reduces its computation using specific psychoacoustic metrics that preserve audio quality while reducing computational complexity. This dissertation describes the perceptual scheduling framework and its application to musical works using additive synthesis and resonance modeling. Reduction strategies are developed based on the results of listening experiments. The reduction strategies and the perceptual scheduling framework are implemented in "Open Sound World," a prototype programming system for synthesis servers. This implementation is then tested on several short musical examples. The computation saved is measured for each example. The quality of the audio output from the servers with and without perceptual scheduling enabled is evaluated by human listeners in a controlled experiment. The result of this experiment have been encouraging. In one example, the average CPU time decreased by about 75%, yet listeners perceivced little degradation in audio quality. The perceptual scheduling framework can be applied to other compute-intensive algorithms in computer music, such as granular synthesis, pitch detection and sound spatialization. It can also be applied to other perceptually oriented computational tasks, such as real-time graphics and video processing. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Apr 17 15:50:29 2001 From rem-conf-request@es.net Tue Apr 17 15:50:27 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14peIg-00061z-00; Tue, 17 Apr 2001 15:50:22 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14peIf-00061p-00; Tue, 17 Apr 2001 15:50:21 -0700 Received: from ns2.packetvideo.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Tue, 17 Apr 2001 15:50:20 -0700 Received: from misty.packetvideo.com ([63.214.191.76]) by ns2.packetvideo.com (8.9.3/8.9.3) with ESMTP id PAA00643; Tue, 17 Apr 2001 15:49:01 -0700 (PDT) (envelope-from zeng@PacketVideo.com) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id <20NJWHXH>; Tue, 17 Apr 2001 14:13:53 -0700 Message-ID: <72660A24B978D411BB8A00B0D03DFE01285212@misty.packetvideo.com> From: Thomas Zeng To: "'Adam Li'" , "'Vivek Bhargava'" , magnus.westerlund@era-t.ericsson.se, "'Lars-Erik Jonsson (EPL)'" , ajayrajkumar@lucent.com, mdturner@lucent.com, "'Dan Gal'" , "'Nikolai Leung'" , "'Colin Perkins'" , "'David Leon'" , "'Peter J. McCann'" , "'Tom Hiller'" , "'Craig Greer'" , "'Keith Miller'" , "'Jeong-Hoon Park'" , "'Yung Lyul Lee'" , "'John D. Villasenor'" , "'Stephen Casner'" , Greg Sherwood , Thomas Zeng , Marcello Lioy Cc: "'rem-conf@es.net'" Subject: RE: Re-Revised EVRC RTP draft Date: Tue, 17 Apr 2001 14:13:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Adam: I second Colin in favor of having ToC to maintain consistency with other vocoder RTP formats. Having said that, after some thoughts, I realized that UDP-lite probably will not help EVRC very much in that if a received EVRC frame contains any bit error, it should probably be treated as a erasure frame. Therefor in current implementations CRC coverage should really be the entire RTP packet. Whenever CRC does not check, all the bundled frames should probably be treated as erasures as described in section 7. thanks thomas -----Original Message----- From: Adam Li [mailto:adamli@icsl.ucla.edu] Sent: Monday, April 16, 2001 3:37 PM To: 'Vivek Bhargava'; magnus.westerlund@era-t.ericsson.se; 'Lars-Erik Jonsson (EPL)'; ajayrajkumar@lucent.com; mdturner@lucent.com; 'Dan Gal'; 'Nikolai Leung'; 'Colin Perkins'; 'David Leon'; 'Peter J. McCann'; 'Tom Hiller'; 'Craig Greer'; 'Keith Miller'; 'Jeong-Hoon Park'; 'Yung Lyul Lee'; 'John D. Villasenor'; 'Stephen Casner'; Greg Sherwood; Thomas Zeng; Marcello Lioy Cc: Adam Li Subject: Re-Revised EVRC RTP draft Hi, gentlemen, Here is the re-revised EVRC RTP draft. The following changes are made (no particular order): (1) Section 4: "...frame header will be ignored when..." changed to "...frame header will not be used when...". (2) section 3.1.2: The first byte of type 1 is changed to IRLLLNNN with I interleaved bit, R reserved bits, etc... (3) section 3.3: Text changed to "The association of payload type number with the packet type is done out-of-band, for example by SDP at the setup of a session" (4) Section 10: Added ptype in example. (5) Section 4: Name of Reduced Bitrate bit is changed to D to avoid comflict with R (Reserved Bit). (6) Section 3.1.2: Change to allow LLL to be 0 to 7. Note1: The restriction comes from RFC 2658. But as commented by two authors, I also do not see the reason for restricting the LLL to below 5. So it is changed now unless someone has some significant reasons otherwise. Note2: (For Magnus) Yes, the number of frames in each packet is LLL + 1 (section 6). So we should keep "subject to MTU limitations". (7) Section 9: Default value is given for maxbundle and maxinterleave values. Please let me know if you think we should put in different values. As of the latest suggestion on bundling TOC together: > The reason UDP-lite does not work well with the current EVRC payload > format is that when multiple frames > are grouped the per-frame header bytes are scattered in the > playload and > is impossible to be protected by the CRC > in UDP lite header. In this case, protecting the frame headers will not help much when the frame data are lost. All the information gained is on how many frames are lost, which can also be deducted from the time-stamp of the next packet. The handling of lost packet is described in Section 7, which may work as well. > 2. The fact that the per-frame header bytes are scattered in the playload > also makes it hard to use > the scatter/gather array data structure in Unix based > streaming servers. > For instance, we use Linux io-vec, a form > of scatter/gather array data structure to avoid extra copying > of payload > data. I think we should not change protocol based on implementation of one particular platform/OS. That's it for now. Please provide me with your feedback and suggestions. Thanks. Adam ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) From rem-conf Wed Apr 18 01:37:29 2001 From rem-conf-request@es.net Wed Apr 18 01:37:26 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14pnJ4-0004Q0-00; Wed, 18 Apr 2001 01:27:22 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14pnEx-0004Oz-00; Wed, 18 Apr 2001 01:23:07 -0700 Received: from eden.dei.uc.pt ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 18 Apr 2001 01:23:04 -0700 Received: from pan (pan.dei.uc.pt [10.2.0.27]) by eden.dei.uc.pt (8.11.3/8.11.3) with SMTP id f3I8FkD63788; Wed, 18 Apr 2001 09:15:48 +0100 (WEST) Message-Id: <3.0.6.32.20010418091839.008da590@eden.dei.uc.pt> X-Sender: boavida@eden.dei.uc.pt X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 18 Apr 2001 09:18:39 +0100 To: webmaster@ercim.org, office@ercim.org, sacj_production@cs.up.ac.za, sdelman@wkap.com, jorg@cs.virginia.edu, msj@microsoft.com, cecileh@total.emap.com, ole@cisco.com, helpdesk@cordis.lu, end2end-interest@ISI.EDU, tccc@ieee.org, int-serv@ISI.EDU, conf@colmar.colmar.uha.fr, rem-conf@es.net, qbone@internet2.edu, diffserv-interest@external.cisco.com From: Fernando Boavida Subject: QofIS'2001 Last Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We apologize if you receive multiple copies. ==================================================================== QofIS 2001 http://qofis2001.dei.uc.pt/ Second International Workshop on Quality of future Internet Services September 24-26, 2001, University of Coimbra, Coimbra, Portugal LAST CALL FOR PAPERS -------------------------------------------------------------------- Due to numerous requests, the paper submission deadline has been extended to APRIL 30TH, 2001 ==================================================================== From rem-conf Thu Apr 19 01:57:44 2001 From rem-conf-request@es.net Thu Apr 19 01:57:42 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qA6W-0001JI-00; Thu, 19 Apr 2001 01:47:56 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14q9yt-0001GC-00; Thu, 19 Apr 2001 01:40:03 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 19 Apr 2001 01:40:02 -0700 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f3J8e0O18264 for ; Thu, 19 Apr 2001 10:40:00 +0200 (MEST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0GC100B016QNRQ@mbb1.ericsson.se> for rem-conf@es.net; Thu, 19 Apr 2001 10:40:00 +0200 (MET DST) Received: from ericsson.com (rcur34ip175.ericsson.se [147.214.34.175]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GC100AJG6QNYP@mbb1.ericsson.se> for rem-conf@es.net; Thu, 19 Apr 2001 10:39:59 +0200 (MET DST) Date: Thu, 19 Apr 2001 10:39:58 +0200 From: Johan =?iso-8859-1?Q?Sj=F6berg?= Subject: draft-ietf-avt-rtp-amr-07.txt submitted To: rem-conf@es.net Message-id: <3ADEA45E.4FB5BD8E@ericsson.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=iso-8859-1 X-Accept-Language: sv,en-US,en Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id f3J8e0O18264 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have just submitted the draft-ietf-avt-rtp-amr-07.txt version of the "RTP payload format and file storage format for AMR and AMR-WB audio". The changes from the -06 version is basically editorial. You can download the draft from: http://standards.ericsson.net/rtp-pf/draft-ietf-avt-rtp-amr-07.txt Best regards, Johan=20 --=20 Johan Sj=F6berg Audio Technology, Ericsson Research ----------------------------------------------------------------- Ericsson Radio Systems AB | Phone: +46 8 50878230 Torshamnsgatan 23 | Fax: +46 8 7575550 S-164 80 Stockholm, SWEDEN | mailto:johan.sjoberg@ericsson.com From rem-conf Thu Apr 19 02:39:51 2001 From rem-conf-request@es.net Thu Apr 19 02:39:48 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qAka-0003l8-00; Thu, 19 Apr 2001 02:29:20 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qAcl-0002r6-00; Thu, 19 Apr 2001 02:21:15 -0700 Received: from mail5.nc.rr.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 19 Apr 2001 02:21:14 -0700 Received: from v3f6b5 ([24.162.246.42]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 19 Apr 2001 05:21:12 -0400 From: "Injong Rhee" To: Subject: source code for GSM-AMR or EVRC Date: Thu, 19 Apr 2001 05:13:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Is there any publically available C source code for GSM-AMR or EVRC voice coders? If so, I would appreciate it very much if you could provide some pointers for them. Best regards, thanks in advance Injong Rhee Assistant Professor rhee@eos.ncsu.edu NCSU From rem-conf Thu Apr 19 03:47:45 2001 From rem-conf-request@es.net Thu Apr 19 03:47:44 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qBpl-0000Sv-00; Thu, 19 Apr 2001 03:38:45 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qBgt-0007jr-00; Thu, 19 Apr 2001 03:29:35 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 19 Apr 2001 03:29:34 -0700 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f3JATWO10761 for ; Thu, 19 Apr 2001 12:29:32 +0200 (MEST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0GC100701BT8YY@mbb1.ericsson.se> for rem-conf@es.net; Thu, 19 Apr 2001 12:29:32 +0200 (MET DST) Received: from ericsson.com (rcur34ip175.ericsson.se [147.214.34.175]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GC100MPFBT7DA@mbb1.ericsson.se> for rem-conf@es.net; Thu, 19 Apr 2001 12:29:31 +0200 (MET DST) Date: Thu, 19 Apr 2001 12:29:30 +0200 From: Johan =?iso-8859-1?Q?Sj=F6berg?= Subject: Re: source code for GSM-AMR or EVRC To: Injong Rhee Cc: rem-conf@es.net Message-id: <3ADEBE0A.A5E8FC24@ericsson.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (Win98; I) Content-type: text/plain; charset=iso-8859-1 X-Accept-Language: sv,en-US,en References: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id f3JATWO10761 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The AMR codec can be found in: ftp://ftp.3gpp.org/Specs/2001-03/Rel-4/26_series/ Fix point code in 26073-400.zip and floating point code in 26104-400.zip Best regards Johan Injong Rhee wrote: >=20 > Hi, >=20 > Is there any publically available C source code for GSM-AMR or EVRC voi= ce > coders? If so, I would appreciate it very much if you could provide som= e > pointers for them. >=20 > Best regards, >=20 > thanks in advance > Injong Rhee >=20 > Assistant Professor > rhee@eos.ncsu.edu > NCSU --=20 Johan Sj=F6berg Audio Technology, Ericsson Research ----------------------------------------------------------------- Ericsson Radio Systems AB | Phone: +46 8 50878230 Torshamnsgatan 23 | Fax: +46 8 7575550 S-164 80 Stockholm, SWEDEN | mailto:johan.sjoberg@ericsson.com From rem-conf Thu Apr 19 05:47:43 2001 From rem-conf-request@es.net Thu Apr 19 05:47:40 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qDgo-0004xc-00; Thu, 19 Apr 2001 05:37:38 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qDcE-0004wo-00; Thu, 19 Apr 2001 05:32:54 -0700 Received: from giasmd01.vsnl.net.in ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 19 Apr 2001 05:32:52 -0700 Received: from dev_wks_17 (unknown [203.197.135.29]) by giasmd01.vsnl.net.in (Postfix) with SMTP id 494ACD571; Thu, 19 Apr 2001 18:13:08 +0530 (IST) From: skillometer_beta@vsnl.net To: Skmeter_Beta@giasmd01.vsnl.net.in Subject: ADV: How good are your IT skills? X-Mailer: AMLC 2.7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C0C339.C85771A0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-Id: <20010419124308.494ACD571@giasmd01.vsnl.net.in> Date: Thu, 19 Apr 2001 18:13:08 +0530 (IST) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C0C339.C85771A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take the Skillometer Skills Challenge! Win $100 and a Free Palm VIIx = handheld! Get the recognition you deserve. As an accomplished IT professional, we = invite you to take the Skillometer Skills Challenge. Skillometer = provides web-based skills testing for current and leading-edge = Information Technologies. Our tests measure the proficiency of the IT = professional in a respective technology. If you're good enough, we'll = feature you on our website. Choose your test, beat the high score, and = we'll put your name and picture on our homepage. =20 Win a Free Palm VIIx handheld! Go to www.skillometer.com/indexbeta.asp. = Fill out the form, choose the technologies in which you want to be = tested, and you'll immediately receive an email with a hyperlink to your = test(s). For each correct answer, you'll receive an entry into our Palm = VIIx Handheld giveaway. Detailed contest rules are located at our = website.=20 Think you're good? Show everyone. Take the Skillometer Skills = Challenge! =20 -------------------------------------------------------------------------= ------- Skillometer, LLC Manor Oak One, Suite 170 1910 Cochran Road Pittsburgh, PA 15220 (010412) ------=_NextPart_000_002C_01C0C339.C85771A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Take the = Skillometer Skills=20 Challenge!  Win $100 and a Free Palm VIIx = handheld!
 
Get the = recognition=20 you deserve.  As an accomplished IT professional, we = invite you to=20 take the Skillometer Skills Challenge. Skillometer = provides web-based skills testing for current and leading-edge = Information=20 Technologies.  Our tests measure the proficiency of the IT = professional in=20 a respective technology.  If you're good enough, we'll feature you = on our=20 website.  Choose your test, beat the high score, and we'll put your = name=20 and picture on our homepage. 
 
Win a Free Palm VIIx = handheld!  Go=20 to www.skillometer.com/indexbeta.asp.  Fill out the form, choose the technologies in which = you want=20 to be tested, and you'll immediately receive an email with a = hyperlink to=20 your test(s).  For each correct answer, you'll = receive an=20 entry into our Palm VIIx Handheld giveaway.  Detailed contest rules = are=20 located at our website. 
 
Think you're good?  Show = everyone. =20 Take the Skillometer Skills Challenge!

 =20
Skillometer,=20 LLC
Manor Oak One,=20 Suite 170
1910 Cochran=20 Road
Pittsburgh,=20 PA  15220
 
(010412)
------=_NextPart_000_002C_01C0C339.C85771A0-- From rem-conf Thu Apr 19 12:11:56 2001 From rem-conf-request@es.net Thu Apr 19 12:11:55 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qJqK-0001ja-00; Thu, 19 Apr 2001 12:11:52 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qJqJ-0001jQ-00; Thu, 19 Apr 2001 12:11:51 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 19 Apr 2001 12:11:51 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA22022; Thu, 19 Apr 2001 12:01:49 -0700 Message-ID: <3ADF3747.61FF8B94@bmrc.berkeley.edu> Date: Thu, 19 Apr 2001 12:06:47 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/25 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces, and Graphics Seminar bmrc.berkeley.edu/mig An Overview of Context-Aware Computing April 25, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Jason I. Hong Computer Science Division - EECS U.C. Berkeley Context-aware computing combines sensing technologies, recognition algorithms, and wireless networking to make systems more responsive to the people, places and activities surrounding their use. Such systems can be used to enhance human safety, provide convenience, improve efficiency, and augment how we find and remember information. For example, clothes could be embedded with health-monitoring sensors and location sensors. The combined system could be programmed to detect serious health problems and automatically call for an ambulance, providing the wearer's current location. In this talk, I survey the current state of the art in context-aware computing. I will describe applications that have been built, offer a taxonomy of context-awarey systems. I will also provide an overview of our work here at Berkeley on the Context Fabric, an infrastructure for building context-aware systems. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Fri Apr 20 11:54:52 2001 From rem-conf-request@es.net Fri Apr 20 11:54:50 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qg3K-0003DI-00; Fri, 20 Apr 2001 11:54:46 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qg3J-0003D8-00; Fri, 20 Apr 2001 11:54:45 -0700 Received: from plum.iecs.fcu.edu.tw ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 20 Apr 2001 11:54:44 -0700 Received: from eva (EVA.netlab.iecs.fcu.edu.tw [140.134.25.15]) by plum.iecs.fcu.edu.tw (8.9.1b+Sun/8.9.1) with SMTP id CAA04052 for ; Sat, 21 Apr 2001 02:54:34 +0800 (CST) Message-ID: <006e01c0c9ce$3252b160$0f19868c@netlab.iecs.fcu.edu.tw> From: =?big5?B?q1S03A==?= To: Subject: How many G.723.1 frames were packetized into a RTP packet ? Date: Sat, 21 Apr 2001 03:15:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C0CA11.40205750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C0CA11.40205750 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, I have a question in RTP. How many G.723.1 frames were packetized into a RTP packet ? thanks.... andy huang=20 ------=_NextPart_000_006B_01C0CA11.40205750 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hello,
I have a = question in=20 RTP.
 
How many = G.723.1 frames were=20 packetized into a RTP packet ?
 
thanks....
 
andy huang=20
------=_NextPart_000_006B_01C0CA11.40205750-- From rem-conf Fri Apr 20 11:57:15 2001 From rem-conf-request@es.net Fri Apr 20 11:57:14 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qg5d-0003g9-00; Fri, 20 Apr 2001 11:57:09 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qg5c-0003fy-00; Fri, 20 Apr 2001 11:57:08 -0700 Received: from plum.iecs.fcu.edu.tw ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 20 Apr 2001 11:57:07 -0700 Received: from eva (EVA.netlab.iecs.fcu.edu.tw [140.134.25.15]) by plum.iecs.fcu.edu.tw (8.9.1b+Sun/8.9.1) with SMTP id CAA04067 for ; Sat, 21 Apr 2001 02:56:58 +0800 (CST) Message-ID: <008401c0c9ce$87efcea0$0f19868c@netlab.iecs.fcu.edu.tw> From: =?big5?B?q1S03A==?= To: Subject: How many G.723.1 frames were packetized into a RTP packet ? Date: Sat, 21 Apr 2001 03:17:24 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C0CA11.95EE6FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C0CA11.95EE6FA0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hello, I have two question in RTP. How many G.723.1 frames were packetized into a RTP packet ? And what is its RTP format ? thanks.... andy huang=20 ------=_NextPart_000_0081_01C0CA11.95EE6FA0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hello,
I = have two question in=20 RTP.
 
How many = G.723.1 frames were=20 packetized into a RTP packet ?
And what is its RTP format ?
 
thanks....
 
andy huang=20
= ------=_NextPart_000_0081_01C0CA11.95EE6FA0-- From rem-conf Fri Apr 20 12:47:55 2001 From rem-conf-request@es.net Fri Apr 20 12:47:55 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14qgr3-0004wI-00; Fri, 20 Apr 2001 12:46:09 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14qgr2-0004w8-00; Fri, 20 Apr 2001 12:46:08 -0700 Received: from almso1.proxy.att.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Fri, 20 Apr 2001 12:46:08 -0700 Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f3KJk2I19435; Fri, 20 Apr 2001 15:46:02 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA22579; Fri, 20 Apr 2001 15:45:26 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 15:46:01 -0400 Message-ID: <47D99458148BD411BE2E00902761557903821323@njc240po04.mt.att.com> From: "Baker, Maurice R, ALNTK" To: ?? , rem-conf@es.net Subject: RE: How many G.723.1 frames were packetized into a RTP packet ? Date: Fri, 20 Apr 2001 15:45:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="big5" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (1) Obviously there is an upper limit on # of speech frames per packet, based on the maximum allowable # of bytes in a packet. However, you will most likely be constrained by packetization delay long before reaching it. G.723.1 frames contain 30 msec of speech. Typically, you would not put more than 1 or maybe 2 frames in a packet since (for the majority of interactive applications, anyhow) you want to keep total end-to-end delay from all contributors (coding, packetization, propagation, jitter buffer, etc.) to less than 150 msec one-way. If your particular application perhaps allows you to loosen (or even eliminate) the delay requirement then you could put more frames per packet. (2) See RFC 1889, et al. for the full details ftp://ftp.isi.edu/in-notes/rfc1889.txt Also, you may want to start by first looking at Prof. Schulzrinne's webpage http://www.cs.columbia.edu/~hgs/rtp/ -----Original Message----- From: m8802241@plum.iecs.fcu.edu.tw [mailto:m8802241@plum.iecs.fcu.edu.tw] Sent: Friday, April 20, 2001 3:17 PM To: rem-conf@es.net Subject: How many G.723.1 frames were packetized into a RTP packet ? Hello, I have two question in RTP. How many G.723.1 frames were packetized into a RTP packet ? And what is its RTP format ? thanks.... andy huang From rem-conf Fri Apr 20 13:06:11 2001 From rem-conf-request@es.net Fri Apr 20 13:06:10 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qhAM-000538-00; Fri, 20 Apr 2001 13:06:06 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qhAK-00052y-00; Fri, 20 Apr 2001 13:06:04 -0700 Received: from ckmso1.proxy.att.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 20 Apr 2001 13:05:59 -0700 Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f3KK5vV04800 for ; Fri, 20 Apr 2001 16:05:57 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id QAA26745; Fri, 20 Apr 2001 16:04:46 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 16:05:57 -0400 Message-ID: <47D99458148BD411BE2E00902761557903821442@njc240po04.mt.att.com> From: "Baker, Maurice R, ALNTK" To: rem-conf@es.net Subject: RE: How many G.723.1 frames were packetized into a RTP packet ? Date: Fri, 20 Apr 2001 16:05:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="big5" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With regard to (2) below, an additional comment would be that RFC1890 ftp://ftp.isi.edu/in-notes/rfc1890.txt may also be generally informative although it too does not contain specific mention of G.723.1 coding in RTP payloads. http://search.ietf.org/internet-drafts/draft-ietf-avt-profile-new-10.txt is a recent Internet Draft which could perhaps be considered a more up-to-date version of RFC1890. I couldn't tell whether you were asking a general question, or had actually tried to find information on the RTP Profile to be used with G.723.1 coded speech. -----Original Message----- From: Baker, Maurice R, ALNTK Sent: Friday, April 20, 2001 3:46 PM To: ??; rem-conf@es.net Subject: RE: How many G.723.1 frames were packetized into a RTP packet ? (1) Obviously there is an upper limit on # of speech frames per packet, based on the maximum allowable # of bytes in a packet. However, you will most likely be constrained by packetization delay long before reaching it. G.723.1 frames contain 30 msec of speech. Typically, you would not put more than 1 or maybe 2 frames in a packet since (for the majority of interactive applications, anyhow) you want to keep total end-to-end delay from all contributors (coding, packetization, propagation, jitter buffer, etc.) to less than 150 msec one-way. If your particular application perhaps allows you to loosen (or even eliminate) the delay requirement then you could put more frames per packet. (2) See RFC 1889, et al. for the full details ftp://ftp.isi.edu/in-notes/rfc1889.txt Also, you may want to start by first looking at Prof. Schulzrinne's webpage http://www.cs.columbia.edu/~hgs/rtp/ -----Original Message----- From: m8802241@plum.iecs.fcu.edu.tw [mailto:m8802241@plum.iecs.fcu.edu.tw] Sent: Friday, April 20, 2001 3:17 PM To: rem-conf@es.net Subject: How many G.723.1 frames were packetized into a RTP packet ? Hello, I have two question in RTP. How many G.723.1 frames were packetized into a RTP packet ? And what is its RTP format ? thanks.... andy huang From rem-conf Fri Apr 20 17:59:21 2001 From rem-conf-request@es.net Fri Apr 20 17:59:20 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qlk4-0007Dx-00; Fri, 20 Apr 2001 17:59:16 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qlk2-0007Dn-00; Fri, 20 Apr 2001 17:59:14 -0700 Received: from TmpStr ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 20 Apr 2001 17:59:13 -0700 Reply-To: "MASTER AREA" From: "MASTER AREA" To: "" Organization: MASTER X-Priority: 3 X-MSMail-Priority: Normal Subject: PARA:rem-conf@es.net Sender: "MASTER AREA" Mime-Version: 1.0 Content-Type: text/html; charset="windows-1250" Date: Sat, 21 Apr 2001 03:03:50 +0200 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Pagina nueva 1 CURSOS MASTER Pagina nueva 1

          & nbsp;               OFERTAS CURSOS MASTER

 

GRATAMENTE NOS DIRIGIMOS A VDS.PARA MOSTRARLES NUESTROS NUEVOS CURSOS..PUBLI/DIFUSION.

DISPONEMOS DE ALGUNOS OTROS QUE ESTAMOS INCORPORANDO,MEDICINA NATURAL,HIPNO-PSICOLOGIA,COSMETOLOGIA,ECOLOGIA,ESTETI CA.ECT

puede verlos:

http://www.bio-desarrollo.org/cabecu.htm


ASI COMO ALREDEDOR DE 30.CURSOS TECNICOS MONOGRAFICOS,RELACIONADOS CON EL AREA DE LA SALUD Y DE LAS MEDICINAS ALTERNATIVAS EN ESPECIAL.
TODOS LOS CURSOS ESTAN ACOGIDOS AL ART.126 DEL TRATADO DE MAASTRICH.ECC.(SOBRE EDUCACION A DISTANCIA) AL CONCLUIR EL EXAMEN FINAL"EVALUACION" SE LE HARA ENTREGA DEL CORRESPONDIENTE DIPLOMA MASTER,CERTIFICADO NORMA CEE,FOTO DIPLOMA PROMOCION. 

SIN OTRA QUE APROVECHAR LA OCASION PARA ENVIARLES UN CORDIAL SALUDO:

ATENTAMENTE:

JOSE BLAZQUEZ

DIRECTOR

CUE.DEL MUNDO SHOP SL 

c/Isaac Albeniz 16.2.B.
30.009-MURCIA-España 
TLF.968.28.16.72 

si desea ser borrado:

brosalud@infonegocio.com

 

From rem-conf Sat Apr 21 09:09:45 2001 From rem-conf-request@es.net Sat Apr 21 09:09:44 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14qzx6-0000ns-00; Sat, 21 Apr 2001 09:09:40 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14qzx4-0000ni-00; Sat, 21 Apr 2001 09:09:38 -0700 Received: from amex.Cox.SMU.Edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Sat, 21 Apr 2001 09:09:37 -0700 Received: from cm39617-a.mail.cox.smu.edu (cm39517-a.pkcty1.tx.home.com [65.10.7.20]) by amex.Cox.SMU.Edu (8.11.0/8.11.0) with ESMTP id f3LEkmJ11459; Sat, 21 Apr 2001 09:46:48 -0500 Message-Id: <4.3.0.20010421103114.0216c368@mail.cox.smu.edu> X-Sender: gavishb@mail.cox.smu.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 21 Apr 2001 10:37:07 -0500 To: (Recipient list suppressed) From: Bezalel Gavish Subject: ICTSM 10 Call for Papers Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_56159072==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_56159072==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed ICTSM 10 Call for Papers [sorry if you receive multiple copies of this message] Below please find the URL for "The 10th International Conference on Telecommunication Systems Management" which will be held March 14-17, 2002 at the Cox School of Business, SMU, Dallas TX. http://tecom.cox.smu.edu/icts10/ The deadline for submitting papers for consideration is October 1, 2001. Regards, Bezalel Gavish Professor Bezalel Gavish Eugene J. and Ruth F. Constantin Distinguished Chair in Business, Chairman of the Information Technology and Operations Management Department. Edwin L. Cox School of Business Southern Methodist University P.O. Box 750333 Dallas, TX 75275-0333 E-mail: gavishb@mail.cox.smu.edu Tel: Office (214) 768-8258 FAX (305) 832-3767 Assistant (214) 768-8256 Home (214) 528-3584 --=====================_56159072==_.ALT Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by amex.Cox.SMU.Edu id f3LEkmJ11459
ICTSM 10 Call for Papers

[sorry if you receive multiple copies of this message]

Below please find the URL for =93The 10th International Conference on Telecommunication Systems Management" which will be held March 14-17, 2002 at the Cox School of Business, SMU, Dallas TX.
http://tecom.cox.smu.edu/icts10/

The deadline for submitting papers for consideration is October 1, 2001.



Regards,
Bezalel Gavish


Professor Bezalel Gavish
Eugene J. and Ruth F. Constantin Distinguished Chair in Business,
Chairman of the Information Technology and Operations Management Department.
Edwin L. Cox School of Business
Southern Methodist University
P.O. Box 750333
Dallas, TX 75275-0333
E-mail: gavishb@mail.cox.smu.edu


Tel: Office (214) 768-8258         FAX (305) 832-3767     Assistant (214) 768-8256
      Home (214) 528-3584

--=====================_56159072==_.ALT-- From rem-conf Sat Apr 21 09:31:48 2001 From rem-conf-request@es.net Sat Apr 21 09:31:47 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14r0Fs-00079R-00; Sat, 21 Apr 2001 09:29:04 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14r0Fq-00079F-00; Sat, 21 Apr 2001 09:29:02 -0700 Received: from odin.unik.no ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Sat, 21 Apr 2001 09:28:57 -0700 Received: from tomkri by odin.unik.no with local (Exim 3.16 #2) id 14r0Bm-00064l-00; Sat, 21 Apr 2001 18:24:50 +0200 To: ecoop-info@ecoop.org,tcgn@ieee.org,odp@dstc.edu.au,reflective-middleware@cs.uiuc.edu,cabernet-events@newcastle.ac.uk,confctrl@isi.edu,phdoos@ecoop.org,wg7@dstc.edu.au,rem-conf@es.net,dist-obj@distributedcoalition.org Newsgroups: comp.os.research Subject: Reminder - CfP: International Workshop on Multimedia Middleware (M3W 01) Reply-To: m3w-org@ifi.uio.no From: Tom Kristensen Date: 21 Apr 2001 18:24:48 +0200 Message-ID: <7rpue6rzjj.fsf@odin.unik.no> Organization: Department of Informatics, University of Oslo Lines: 105 X-Newsreader: Gnus v5.7/Emacs 20.4 Posted-To: comp.os.research Sender: Tom Kristensen X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The following message is a courtesy copy of an article that has been posted to comp.os.research as well. Please, find the Call for Papers to the International Workshop on Multimedia Middleware (M3W'01= enclosed. The workshop is held in conjunction with ACM Multimediaj 2001 in Ottawa, Canada. The deadline is now approaching! (May 15.) -------------------------------------------------------- M3W'01 International Workshop on Multimedia Middleware October 5th, 2001, Ottawa, Canada in conjunction with ACM Multimedia 2001 http://www.ifi.uio.no/~m3w Middleware technologies like the Common Object Request Broker (CORBA) implementations, Microsoft's Distributed Component Object Model (DCOM), and Java RMI have proved their suitability for "standard" client-server applications. Middleware abstracts from particular network services and allows application developers to focus on the application. However, it is well known in the research community, that today's middleware solutions are not suited for distributed multimedia systems, and do not provide the required levels of adaptation and configurability that is needed to accommodate the diversity of modern distributed multimedia applications. The goal of the workshop is to bring together researchers from academia and industry to identify why today's middleware technologies and standards fail to appropriately support multimedia applications and especially to discuss new requirements, approaches, and solutions. Areas of interest for this workshop include (but are not limited to) the following topics: - Experiences with middleware platforms in multimedia application domains - The design and implementation of multimedia middleware platforms - Performance analysis of multimedia middleware platforms - Quality of Service and Realtime support in middleware platforms - Stream support in middleware platforms - Support for persistent multimedia objects - Resolving heterogeneity in multimedia middleware platforms - Services and APIs for multimedia application development (incl. security and management) Format of the workshop: ----------------------- To enable a highly interactive workshop, attendance will be limited to about 50 participants. Participants will be invited based on the originality, technical merit and topical relevance of their submissions, as well as the likelihood that the ideas expressed in their submissions will lead to insightful technical discussions at the workshop. Proceedings and submission guidelines: ----------------------------------------- We seek short paper submissions describing original and unpublished work. The page limit for submissions is four pages. All accepted papers will be published in a proceeding printed by ACM. We strongly encurage electronic submissions via the workshop's web page (http://www.ifi.uio.no/~m3w). Important dates: ----------------- Submission Deadline: May 15th Notification: June 15th Final version: July 15th Workshop Co-Chairs: ------------------- T. Plagemann, U of Oslo F. Eliassen, Simula RL Publicity Chair: ---------------- T. Kristensen, U of Oslo Program Committee: -------------------- G. Blair, Lancaster U V. Cahill, Trinity C. Dublin A. Campbell, Columbia U R. Campbell, U of Illinois at UC V. Goebel, U of Oslo D. Ionescu, U of Ottawa D. Karr, BBN D. Schmidt, DARPA M. v. Sinderen, U of Enschede B. Thuraisingham, MITRE W. Yu, U of Tromsĝ -------------------------------------------------------- -- # Tom Kristensen (Research Associate) # ## Department of Informatics, University of Oslo ## ### tel +47 2285 2532 # http://www.ifi.uio.no/~tomkri ### From rem-conf Mon Apr 23 05:22:43 2001 From rem-conf-request@es.net Mon Apr 23 05:22:42 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14rfMU-000478-00; Mon, 23 Apr 2001 05:22:38 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14rfMS-00046y-00; Mon, 23 Apr 2001 05:22:36 -0700 Received: from ensias.um5souissi.ac.ma ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 23 Apr 2001 05:22:34 -0700 Received: from default (dafir.um5souissi.ac.ma [212.217.32.68]) by ensias.um5souissi.ac.ma (8.9.3/8.9.3) with SMTP id MAA21932 for ; Mon, 23 Apr 2001 12:14:55 GMT Message-ID: <005801c0cbf0$54a5de80$4420d9d4@default> From: "M.D. El Kettani" To: Subject: Recent mbone topology Date: Mon, 23 Apr 2001 12:24:18 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C0CBF0.5161FE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0055_01C0CBF0.5161FE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I need detailed and recent information about the current topology of the = Mbone, such as the number of connected machines, the number of = subnetworks, and even a map of the Mbone. All the references that I find in the Internet are very old (up to = 1994), or they are limited to a country or a region. I need global = information. Could you please give me some information, any website describing that. Thank you in advance. Dafir Kettani ------=_NextPart_000_0055_01C0CBF0.5161FE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I need detailed and recent information = about the=20 current topology of the Mbone, such as the number of connected machines, = the=20 number of subnetworks, and even a map of the Mbone.
 
All the references that I find in the = Internet are=20 very old (up to 1994), or they are limited to a country or a region. I = need=20 global information.
Could you please give me some information, any website describing=20 that.
 
Thank you in advance.
 
Dafir=20 Kettani
------=_NextPart_000_0055_01C0CBF0.5161FE20-- From rem-conf Mon Apr 23 06:46:33 2001 From rem-conf-request@es.net Mon Apr 23 06:46:32 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14rgZU-0000ee-00; Mon, 23 Apr 2001 06:40:08 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14rgZS-0000eU-00; Mon, 23 Apr 2001 06:40:06 -0700 Received: from multicasttech.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 23 Apr 2001 06:40:05 -0700 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 860004; Mon, 23 Apr 2001 08:44:55 -0400 Message-ID: <3AE43058.4D43056C@21rst-century.com> Date: Mon, 23 Apr 2001 09:38:33 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "M.D. El Kettani" CC: rem-conf@es.net Subject: Re: Recent mbone topology References: <005801c0cbf0$54a5de80$4420d9d4@default> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "M.D. El Kettani" wrote: > Hello, I need detailed and recent information about the current topology of the Mbone, such as the number of connected machines, the number of subnetworks, and even a map of the > Mbone. All the references that I find in the Internet are very old (up to 1994), or they are limited to a country or a region. I need global information.Could you please give me > some information, any website describing that. Thank you in advance. Dafir Kettani Hello; Mantra at caida http://www.caida.org/tools/measurement/mantra/ has (among lots of other useful information) a topology visual tool : http://www.caida.org/tools/measurement/Mantra/topology/topology.html We have a global status page http://www.multicasttech.com/status/ with a list of autonomous systems available http://www.multicasttech.com/status/mbgp.sum There is also the access grid beacon server project with real time connectivity info : http://beaconserver.accessgrid.org:9999/ Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Mon Apr 23 12:55:50 2001 From rem-conf-request@es.net Mon Apr 23 12:55:49 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14rmR0-0006cE-00; Mon, 23 Apr 2001 12:55:46 -0700 Received: from postal2.es.net ([198.128.3.206]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14rmQy-0006c4-00; Mon, 23 Apr 2001 12:55:44 -0700 Received: from helios.cstp.umkc.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 23 Apr 2001 12:55:43 -0700 Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id OAA12523; Mon, 23 Apr 2001 14:51:40 -0500 (CDT) Date: Mon, 23 Apr 2001 14:51:40 -0500 (CDT) From: Eun Kyo Park Message-Id: <200104231951.OAA12523@helios.cstp.umkc.edu> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.ccrc.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc.tac@tab.ieee.org, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, itc@fokus.gmd.de, multicomm@cc.bellcore.com, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, tccc@ieee.org, xtp-relay@cs.concordia.ca Subject: IEEE ICCCN2001 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE ICCCN2001's paper submission deadline is approaching fast! About two weeks left and we would like to invite you to visit our webiste icccn.cstp.umkc.edu to submit your paper electronically ! Thanks, ICCCN2001 Program Chairs Jenny Li and Ronlad Luijten ----------------------------------------------------------------------------- (Our apologies if you receive this multiple times) *************************** ICCCN 10TH ANNIVERSARY !! *************************** IEEE IC3N'2001 CALL FOR PAPERS TENTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS (ICCCN2001) October 15 -- 17, 2001 Chaparral Suites Hotel Scottsdale, Arizona USA Website: icccn.cstp.umkc.edu Sponsored by IEEE Communications Society (tech. co-sponsor), Telcordia Technologies, Army Research Lab/Office, IBM, Avaya Labs, NOKIA. (*pending approval of sponsorships) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results.The topics include, but are not limited to: Communication Software Software Architecture eCommerce Voice over LAN, IP, and/or ATM Internet Services/Applications Security/Reliability/Dependability Protocols Network Interoperability Network Control Management Multicast Intelligent Networks Streaming Networks Data Traffic Engineering Performance Network Management/Billing Video-on-Demand Networked Databases Network Architectures Optical Communication Networks Terabit Optical Technologies Wireless/Mobile/Satellite Networks Wireless Multimedia Applications Cable Broadband Technologies DSL Technologies ATM Networking Real-time Communications SUBMISSION: Authors are invited to submit complete and original papers. Papers to be submitted should not have been previously published in another forum, and should not be currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a paper as a long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax/phone numbers and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (ps or pdf format is preferred). Please contact Dr. Li if you have to submit with hard copies. Manuscripts should be submitted by Monday, May 7, 2001 to ICCCN2001 website or contact program co-chairs with any questions: Dr. J. Jenny Li Ronald Luijten Avaya Labs (formerly Lucent Bell-Labs) IBM Research Zurich 600 Mountain Ave. RM 2A417 Saumerstrasse 4 Murray Hill, NJ USA CH8803 Ruschlikon, Switzerland jjli@research.bell-labs.com lui@zurich.ibm.com 908-582-5264; 908-582-5809(fax) +41-1-724 8111; +41-1-7248955(fax) IMPORTANT DATES: Paper submission deadline : May 7, 2001 Notification of acceptance: June 29, 2001 Camera ready papers due : July 31, 2001 TUTORIALS: Proposals are solicited for tutorials. Please email your proposals in ASCII format by May 7, 2001 to one of the Program Chairs above. STUDENT FORUM: We encourage submissions from students. Some travel assistance will be available for students with top quality papers. WEBSITE: Electronic paper submission system is READY to accept paper submissions now! Please visit ICCCN2001 web site: icccn.cstp.umkc.edu for more up-to-date information. Honorary Conference Chair: Dr. Sudhir Dixit, Nokia; sudhir.dixit@nokia.com General Chair: Dr. Ton Engbersen, IBM Research; apj@zurich.ibm.com Local Arrangement Chair: Prof. Yann-Hang Lee, Arizona State University; yhlee@asu.edu From rem-conf Mon Apr 23 12:59:52 2001 From rem-conf-request@es.net Mon Apr 23 12:59:52 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14rmTk-00051o-00; Mon, 23 Apr 2001 12:58:36 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14rmTi-00050s-00; Mon, 23 Apr 2001 12:58:34 -0700 Received: from helios.cstp.umkc.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Mon, 23 Apr 2001 12:58:33 -0700 Received: (from ekpark@localhost) by helios.cstp.umkc.edu (8.9.1/8.9.1) id OAA12506; Mon, 23 Apr 2001 14:49:01 -0500 (CDT) Date: Mon, 23 Apr 2001 14:49:01 -0500 (CDT) From: Eun Kyo Park Message-Id: <200104231949.OAA12506@helios.cstp.umkc.edu> To: Hossam.Afifi@enst-bretagne.fr, MariaLuisa.Rossari@cselt.it, Omar.Elloumi@enst-bretagne.fr, enternet@bbn.com, events@teco.edu, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, ftroup@dsl.cis.upenn.edu, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, heads@hpovua.org, hipparch@entropy.inria.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@louisiana.edu, lanoms99@lrg-gw.lrg.ufsc.br, lyko@kt.agh.edu.pl, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@dpnm.postech.ac.kr, nmkorea@dpnm.postech.ac.kr, opensig-announce@ctr.columbia.edu, performance@haven.epm.ornl.gov, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca Subject: IEEE ICCCN2001 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE ICCCN2001's paper submission deadline is approaching fast! About two weeks left and we would like to invite you to visit our webiste icccn.cstp.umkc.edu to submit your paper electronically ! Thanks, ICCCN2001 Program Chairs Jenny Li and Ronlad Luijten ----------------------------------------------------------------------------- (Our apologies if you receive this multiple times) *************************** ICCCN 10TH ANNIVERSARY !! *************************** IEEE IC3N'2001 CALL FOR PAPERS TENTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS (ICCCN2001) October 15 -- 17, 2001 Chaparral Suites Hotel Scottsdale, Arizona USA Website: icccn.cstp.umkc.edu Sponsored by IEEE Communications Society (tech. co-sponsor), Telcordia Technologies, Army Research Lab/Office, IBM, Avaya Labs, NOKIA. (*pending approval of sponsorships) ICCCN is a major international forum to present original and fundamental advances in the field of Computer Communications and Networks. It also serves to foster communication among researchers and practitioners working in a wide variety of scientific areas with a common interest in improving Computer Communications and Networks. SCOPE: The primary focus of the conference is on new and original research results in the areas of design, implementation and applications of Computer Communications and Networks. We invite you to submit papers that address novel, challenging, and innovative results.The topics include, but are not limited to: Communication Software Software Architecture eCommerce Voice over LAN, IP, and/or ATM Internet Services/Applications Security/Reliability/Dependability Protocols Network Interoperability Network Control Management Multicast Intelligent Networks Streaming Networks Data Traffic Engineering Performance Network Management/Billing Video-on-Demand Networked Databases Network Architectures Optical Communication Networks Terabit Optical Technologies Wireless/Mobile/Satellite Networks Wireless Multimedia Applications Cable Broadband Technologies DSL Technologies ATM Networking Real-time Communications SUBMISSION: Authors are invited to submit complete and original papers. Papers to be submitted should not have been previously published in another forum, and should not be currently under review by another journal or conference. All submitted papers will be refereed for quality, correctness, originality and relevance. The program committee reserves the right to accept a paper as a long, short, or poster presentation. Of particular interest are papers which address experiences with concrete Computer Communications and applications. All accepted papers will be published in the conference proceedings. Special issues of journals containing outstanding papers from the conference are being planned. Manuscripts should include an abstract and be limited to 5000 words. Submissions should include the title, author(s), author's affiliation, e-mail address, fax/phone numbers and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera ready paper for the proceedings should also be included. Electronic submission is strongly encouraged (ps or pdf format is preferred). Please contact Dr. Li if you have to submit with hard copies. Manuscripts should be submitted by Monday, May 7, 2001 to ICCCN2001 website or contact program co-chairs with any questions: Dr. J. Jenny Li Ronald Luijten Avaya Labs (formerly Lucent Bell-Labs) IBM Research Zurich 600 Mountain Ave. RM 2A417 Saumerstrasse 4 Murray Hill, NJ USA CH8803 Ruschlikon, Switzerland jjli@research.bell-labs.com lui@zurich.ibm.com 908-582-5264; 908-582-5809(fax) +41-1-724 8111; +41-1-7248955(fax) IMPORTANT DATES: Paper submission deadline : May 7, 2001 Notification of acceptance: June 29, 2001 Camera ready papers due : July 31, 2001 TUTORIALS: Proposals are solicited for tutorials. Please email your proposals in ASCII format by May 7, 2001 to one of the Program Chairs above. STUDENT FORUM: We encourage submissions from students. Some travel assistance will be available for students with top quality papers. WEBSITE: Electronic paper submission system is READY to accept paper submissions now! Please visit ICCCN2001 web site: icccn.cstp.umkc.edu for more up-to-date information. Honorary Conference Chair: Dr. Sudhir Dixit, Nokia; sudhir.dixit@nokia.com General Chair: Dr. Ton Engbersen, IBM Research; apj@zurich.ibm.com Local Arrangement Chair: Prof. Yann-Hang Lee, Arizona State University; yhlee@asu.edu From rem-conf Tue Apr 24 00:17:16 2001 From rem-conf-request@es.net Tue Apr 24 00:17:16 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14rwzA-0002CA-00; Tue, 24 Apr 2001 00:11:44 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14rwz8-0002C0-00; Tue, 24 Apr 2001 00:11:42 -0700 Received: from exchange.Ic4ic.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Tue, 24 Apr 2001 00:11:42 -0700 Received: through eSafe SMTP Relay 987951068; Tue Apr 24 10:12:56 2001 content-class: urn:content-classes:message Subject: TCRTP x ML/MC-PPP MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2001 10:10:50 +0200 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D02DDCE@exchange.Ic4ic.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCRTP x ML/MC-PPP Thread-Index: AcDMlhMkz8Lk89z5RhS6w5CC3JbUig== From: "Daniel Feldman" To: "Tmima Koren (E-mail)" Cc: , "Doron Greenbaum" , "Alex Trigub" , "Eyal Gutman" , "Giora Ariel" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Tmima, how are you doing? Do you know if there is any standard way to use TCRTP with ML/MC-PPP, i.e., segment the PPP packet (which can be a PPPmux packet as well) into ML-PPP fragments and then with L2TP put them in the same link and get some header compression done? The protocol stack would be something like: Data UDP (xN) IP (xN) (PPPmux) PPP ML-PPP L2TP UDP IP Thanks in advance, looking forward to see you at the Pusan 3GPP meeting, Daniel. ~~~~~~~~~~~~~~~~~~~~~~~~ Daniel Feldman System Engineer, IC4IC ltd. office: +972(4)959-4644 ext. 121 mobile: +972(53)980-442 fax: +972(4)959-4944 ~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Tue Apr 24 08:48:19 2001 From rem-conf-request@es.net Tue Apr 24 08:48:19 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14s4uN-0001CG-00; Tue, 24 Apr 2001 08:39:19 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14s4uL-0001C5-00; Tue, 24 Apr 2001 08:39:17 -0700 Received: from www5.chinadns.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Tue, 24 Apr 2001 08:39:17 -0700 Received: (qmail 41659 invoked from network); 24 Apr 2001 15:41:35 -0000 Received: from unknown (HELO localhost) (211.96.141.115) by 211.99.199.74 with SMTP; 24 Apr 2001 15:41:35 -0000 X-Sender: audio@cngoldline.com From: Sonia To: rem-conf@es.net Date: Sat, 24 Feb 2001 23:41:09 +0800 Subject: audio products Reply-To: audio@cngoldline.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir or Madam, It is an honor to send this message to you introducing our factory and products. Coby Electronics Corporation is a "prime" manufacturer of quality consumer electronics that are designed to provide years of outstanding performance and sound reproduction.The brand of our products is from U.S. and the factory is located in Foshan, Guangdong, mainland China . Unlike many other consumer electronics companies, Coby possesses an in-house art & design department and an in-house research & development department. These departments have been responsible for creating award winning packaging designs and exclusive & patented products. Currently Coby has a wide variety of products which were created to fill every desire and need. Those products include personal CD players, portable CD stereos, MP3 players, MP3 CD players, portable stereos, personal portable stereos, AM/FM radios, NOAA weather alert radios, short wave multi band radios, fashion & feature telephones, caller ID products, telephones with built-in digital answering machine, professional stereo headphones & earphones, mini-speaker systems, hands-free cellular & cordless telephone accessories, audio/video accessories, audio & video cleaning care products, and microphones. If you are interested in our products or want to establish a corporation with us, Please contact us without hesitate. Tel:0086-757-6239656 Fax:0086-757-6336141 E-mail:audio@cngoldline.com Website: http://www.cobyusa.com Contact Person: Ms.Sonia From rem-conf Tue Apr 24 12:38:02 2001 From rem-conf-request@es.net Tue Apr 24 12:38:01 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14s8ZO-0003HN-00; Tue, 24 Apr 2001 12:33:54 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14s8ZN-0003HD-00; Tue, 24 Apr 2001 12:33:53 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Tue, 24 Apr 2001 12:33:52 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA07142; Tue, 24 Apr 2001 12:18:08 -0700 Message-ID: <3AE5D29E.5C05DDCF@bmrc.berkeley.edu> Date: Tue, 24 Apr 2001 12:23:10 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 4/25 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces, and Graphics Seminar bmrc.berkeley.edu/mig An Overview of Context-Aware Computing April 25, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Jason I. Hong Computer Science Division - EECS U.C. Berkeley Context-aware computing combines sensing technologies, recognition algorithms, and wireless networking to make systems more responsive to the people, places, and activities surrounding their use. Such systems can be used to enhance human safety, provide convenience, improve efficiency, and augment how we find and remember information. For example, clothes could be embedded with health monitoring sensors and location sensors. The combined system could be programmed to detect serious health problems and automatically call for an ambulance, providing the wearer's current location. In this talk, I survey the current state of the art in context-aware computing. I will describe applications that have been built, offer a taxonomy of context-aware systems. I will also provide an overview of our work here at Berkeley on the Context Fabric, an infrastructure for building context-aware systems. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Wed Apr 25 02:12:31 2001 From rem-conf-request@es.net Wed Apr 25 02:12:31 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sLCz-0002ih-00; Wed, 25 Apr 2001 02:03:37 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sLCx-0002iX-00; Wed, 25 Apr 2001 02:03:35 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 02:03:34 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3P93WO20363; Wed, 25 Apr 2001 11:03:33 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA14911; Wed, 25 Apr 2001 11:03:18 +0200 Message-ID: <3AE6927B.1247133A@era.ericsson.se> Date: Wed, 25 Apr 2001 11:01:47 +0200 From: Mats =?iso-8859-1?Q?N=E4slund?= (ERA) Organization: Ericsson Research, ERA/T/NF X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Harrison , rem-conf@es.net Subject: Re: Secure RTP; crypto context References: <3AC6309E.A27F5EBC@iname.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Chuck, Thanks for your comments. Apologize for the (to say the least) late answer, but we've been keeping busy and wanted to discuss your questions internally (among the SRTP authors) before answering. Chuck Harrison wrote: > While > http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt > describes particular default methods, I think there is an implicit > longing for a way to generalize the protocol. Could we piggyback on RFC > 2630, Cryptographic Message Syntax, and its AES update? > http://www.ietf.org/rfc/rfc2630.txt > http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-01.txt > > I am visualizing a "detached content" mode, wherein the encrypted > content (a big chunk of it...as much as you encrypt under a single key > context) is separated from the "header" info. The content is packetized, > and transmitted over an RTP stream pretty much as in the srtp-00 draft. Not sure I understand you correctly, but I interpret your suggestion as, more or less, encapsulating the RTP payload in something that looks like an "S/MIME email" (?) It seems that this would make the protocol somewhat "chatty" and bandwidth consuming, and that was one of the things we wanted to avoid >from the very beginning. > It seems that the "classic" RTP approach would then be to send the rest > of the CMS message (i.e. the "crypto header") out-of-band. However, I > think the "new paradigm" is to consider it to be an additional media > stream. Over in MPEG they call it an IPMP stream. In this paradigm, the > crypto header info is part of the multimedia session. Because transport > is likely to be unreliable, and participants may "hop on", it will > probably be retransmitted periodically. If key change is required, this > is handled by sending a new crypto header on the IPMP stream, and > starting a corresponding new piece of "detached content" on the media > stream. Group key management and support for DRM is of course important. I believe we will not cover key management in the SRTP draft, but we will most likely provide some discussion on what is _needed_ from the key mgmt and make sure that SRTP as such allows for scenarios like the one you describe. [snip] > .... > And another detail from srtp-00. It states, > When RTP authentication is not present, robust synchronization is not > possible. In this case, transmission errors or an active attacker may > force the receiver to erroneously update his rollover counter and > thus to become completely out of synch. It is not possible to protect > against active attackers in such case [...] > > I would think that, if the rollover counter is only updated when the > packet is successfully decrypted, then active attacks would be > suppressed without authentication overhead. Determining "successful > decryption" may be trivial with some highly structured payload formats > and impossible with others. Thus this technique is a definite MAY. *If* you allow SRTP to make use of knowledge in the application there are certainly many "tricks" of this form. However, we would like SRTP to be transparent so that it can work for any application. What you suggest is to let the application tell SRTP: "hey, the last ten packets were junk". Moreover, enumerating all possible techniques of this type, all with "MAY"s, would make the draft complex. Moreover, even *if* there is redundancy in the payload format, sufficient to tell garbage from real data, how can be we sure that it was due to the roll over counter being wrong that this garbage was produced? It may as well have been any other header field, corrupted during transmission over unreliable channel (at least with the currently suggested IV format). Another point is that occasionally, garbage will look like a perfectly normal packet (if the packet format is not *very* redundant). Thus, not even such a technique will, in the most general case, provide robustness, and we are back were we currently are. It is possible though that some improvements can be made, for instance by looking at RTCP, we will look into that. Best, /Mats From rem-conf Wed Apr 25 04:23:54 2001 From rem-conf-request@es.net Wed Apr 25 04:23:53 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sNFy-00048Q-00; Wed, 25 Apr 2001 04:14:50 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sNFw-00048G-00; Wed, 25 Apr 2001 04:14:48 -0700 Received: from ietf.org ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 04:14:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10485; Wed, 25 Apr 2001 07:14:44 -0400 (EDT) Message-Id: <200104251114.HAA10485@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-evrc-01.txt Date: Wed, 25 Apr 2001 07:14:44 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for EVRC Speech Author(s) : A. Li Filename : draft-ietf-avt-evrc-01.txt Pages : Date : 24-Apr-01 This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech. The packet format supports variable interleaving to reduce the effect of packet loss on Speech quality. In additional, the non-interleaving format is also supported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-evrc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-evrc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-evrc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010424133239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-evrc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-evrc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010424133239.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Apr 25 06:12:46 2001 From rem-conf-request@es.net Wed Apr 25 06:12:45 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sP3H-0005Yr-00; Wed, 25 Apr 2001 06:09:51 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sP3E-0005Yb-00; Wed, 25 Apr 2001 06:09:48 -0700 Received: from sj-msg-core-2.cisco.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 06:09:48 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA19266 for ; Wed, 25 Apr 2001 06:10:14 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f3PD9lr25586 for ; Wed, 25 Apr 2001 06:09:47 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA25731 for ; Wed, 25 Apr 2001 06:09:46 -0700 (PDT) Message-ID: <3AE6CD88.4FCDAD0F@cisco.com> Date: Wed, 25 Apr 2001 09:13:44 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf Subject: RTCP optional ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is my understanding, that an RFC 1889 conformant RTP implementation includes both RTP and RTCP (whether used for unicast or multicast), however there is apparently not universal agreement on this. I'd appreciate it if somebody could either confirm or deny the above. It is also my understanding, that RFC 1890 requires implementers of the RTP/AVP profile to support RTCP as specified in RFC 1889. I'd appreciate it if somebody could either confirm or deny that as well. Thanks Flemming -- Flemming Andreasen Cisco Systems From rem-conf Wed Apr 25 06:38:52 2001 From rem-conf-request@es.net Wed Apr 25 06:38:52 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sPTL-0006UD-00; Wed, 25 Apr 2001 06:36:47 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sPTK-0006U3-00; Wed, 25 Apr 2001 06:36:46 -0700 Received: from cs.columbia.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 06:36:40 -0700 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA18145; Wed, 25 Apr 2001 09:36:39 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA24606; Wed, 25 Apr 2001 09:36:38 -0400 (EDT) Message-ID: <3AE6D2BB.CB7BDCB6@cs.columbia.edu> Date: Wed, 25 Apr 2001 09:35:55 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: rem-conf Subject: Re: RTCP optional ? References: <3AE6CD88.4FCDAD0F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is peculiar - there must be a giant RTCP debating club be somewhere, since I just got a similar question from somebody working at another large telecom company. The answer is: SHOULD. Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. Transmission of RTCP MAY be controlled separately for .. (page 18, avt-rtp-new) In other words, if you don't implement RTCP, you're only conditionally compliant and the protocol police will force you to put an asterisk next to your list of RFC in your product literature. Flemming Andreasen wrote: > > It is my understanding, that an RFC 1889 conformant RTP implementation > includes both RTP and RTCP (whether used for unicast or multicast), > however there is apparently not universal agreement on this. > > I'd appreciate it if somebody could either confirm or deny the above. > > It is also my understanding, that RFC 1890 requires implementers of the > RTP/AVP profile to support RTCP as specified in RFC 1889. > > I'd appreciate it if somebody could either confirm or deny that as well. > > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems From rem-conf Wed Apr 25 06:53:29 2001 From rem-conf-request@es.net Wed Apr 25 06:53:28 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sPjQ-0004Om-00; Wed, 25 Apr 2001 06:53:24 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sPjP-0004Oc-00; Wed, 25 Apr 2001 06:53:23 -0700 Received: from redball.dynamicsoft.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 06:53:22 -0700 Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA03628; Wed, 25 Apr 2001 09:56:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 09:53:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Flemming Andreasen Cc: rem-conf Subject: RE: RTCP optional ? Date: Wed, 25 Apr 2001 09:53:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Wednesday, April 25, 2001 9:36 AM > To: Flemming Andreasen > Cc: rem-conf > Subject: Re: RTCP optional ? > > > This is peculiar - there must be a giant RTCP debating club be > somewhere, since I just got a similar question from somebody > working at > another large telecom company. Even more peculiar is that I too just got this question privately from someone working at a small telecom company. He indicated that Packetcable was debating whether to include RTCP or not. > > The answer is: SHOULD. > > Functions 1-3 SHOULD be used in all environments, but > particularly in > the IP multicast environment. RTP application designers > SHOULD avoid > mechanisms that can only work in unicast mode and will not scale to > larger numbers. Transmission of RTCP MAY be controlled > separately for I often get asked what the benefits are in unicast, point-to-point calls where no adaptation is performed. One clear benefit we have found is that RTCP is a good, end-to-end keepalive mechanism. Its sent even when there is no media being sent, and its sent very frequently. It can provide a much more robust and rapid indication of failure of the far-end device than something like SIP session timer. In fact, if the far end device fails, you might even get some ICMP errors to RTCP packets (which works even during silence), which can give failure detection in a matter of seconds. This is in addition to the benefits outlined in the RTP bis draft. Also, note that for MCU based conferences, RTCP SDES is the only specified way to learn the identity of conference participants. So, if you ever want your gateway or phone to join a conference call, you might want to have RTCP support. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From rem-conf Wed Apr 25 07:13:13 2001 From rem-conf-request@es.net Wed Apr 25 07:13:12 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sQ2W-0004wS-00; Wed, 25 Apr 2001 07:13:08 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sQ2U-0004w5-00; Wed, 25 Apr 2001 07:13:06 -0700 Received: from www5.chinadns.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 07:13:05 -0700 Received: (qmail 8163 invoked from network); 25 Apr 2001 07:15:44 -0000 Received: from unknown (HELO localhost) (211.96.141.115) by 211.99.199.74 with SMTP; 25 Apr 2001 07:15:44 -0000 X-Sender: audio@cngoldline.com From: Sonia To: rem-conf@es.net Date: Sun, 25 Feb 2001 15:15:31 +0800 Subject: audio products Reply-To: audio@cngoldline.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir or Madam, It is an honor to send this message to you introducing our factory and products. Coby Electronics Corporation is a "prime" manufacturer of quality consumer electronics that are designed to provide years of outstanding performance and sound reproduction.The brand of our products is from U.S. and the factory is located in Foshan, Guangdong, mainland China . Unlike many other consumer electronics companies, Coby possesses an in-house art & design department and an in-house research & development department. These departments have been responsible for creating award winning packaging designs and exclusive & patented products. Currently Coby has a wide variety of products which were created to fill every desire and need. Those products include personal CD players, portable CD stereos, MP3 players, MP3 CD players, portable stereos, personal portable stereos, AM/FM radios, NOAA weather alert radios, short wave multi band radios, fashion & feature telephones, caller ID products, telephones with built-in digital answering machine, professional stereo headphones & earphones, mini-speaker systems, hands-free cellular & cordless telephone accessories, audio/video accessories, audio & video cleaning care products, and microphones. If you are interested in our products or want to establish a corporation with us, Please contact us without hesitate. Tel:0086-757-6239656 Fax:0086-757-6336141 E-mail:audio@cngoldline.com Website: http://www.cobyusa.com Contact Person: Ms.Sonia From rem-conf Wed Apr 25 07:21:51 2001 From rem-conf-request@es.net Wed Apr 25 07:21:50 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sQAs-0005kp-00; Wed, 25 Apr 2001 07:21:46 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sQAq-0005kf-00; Wed, 25 Apr 2001 07:21:44 -0700 Received: from sj-msg-core-2.cisco.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 07:21:43 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23156; Wed, 25 Apr 2001 07:15:41 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f3PEFEH10893; Wed, 25 Apr 2001 07:15:14 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA05551; Wed, 25 Apr 2001 07:15:13 -0700 (PDT) Message-ID: <3AE6DCDE.D8542A0A@cisco.com> Date: Wed, 25 Apr 2001 10:19:11 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Henning Schulzrinne'" , rem-conf Subject: Re: RTCP optional ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > Sent: Wednesday, April 25, 2001 9:36 AM > > To: Flemming Andreasen > > Cc: rem-conf > > Subject: Re: RTCP optional ? > > > > > > This is peculiar - there must be a giant RTCP debating club be > > somewhere, since I just got a similar question from somebody > > working at > > another large telecom company. > > Even more peculiar is that I too just got this question privately from > someone working at a small telecom company. He indicated that Packetcable > was debating whether to include RTCP or not. > Unfortunately (IMHO) yes. > > > > > The answer is: SHOULD. > > > > Functions 1-3 SHOULD be used in all environments, but > > particularly in > > the IP multicast environment. RTP application designers > > SHOULD avoid > > mechanisms that can only work in unicast mode and will not scale to > > larger numbers. Transmission of RTCP MAY be controlled > > separately for > > I often get asked what the benefits are in unicast, point-to-point calls > where no adaptation is performed. One clear benefit we have found is that > RTCP is a good, end-to-end keepalive mechanism. Its sent even when there is > no media being sent, and its sent very frequently. It can provide a much > more robust and rapid indication of failure of the far-end device than > something like SIP session timer. In fact, if the far end device fails, you > might even get some ICMP errors to RTCP packets (which works even during > silence), which can give failure detection in a matter of seconds. That was my assumption too, however if we can't rely on an RTP implementations actually supporting RTCP, then this doesn't work (rather strange considering the definition of an RTP session). If this is indeed the consensus then I think it should to be pointed out more clearly in the spec. -- Flemming > > > This is in addition to the benefits outlined in the RTP bis draft. > > Also, note that for MCU based conferences, RTCP SDES is the only specified > way to learn the identity of conference participants. So, if you ever want > your gateway or phone to join a conference call, you might want to have RTCP > support. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Flemming Andreasen Cisco Systems From rem-conf Wed Apr 25 07:34:03 2001 From rem-conf-request@es.net Wed Apr 25 07:34:02 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sQLY-0002My-00; Wed, 25 Apr 2001 07:32:48 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sQLX-0002Mo-00; Wed, 25 Apr 2001 07:32:47 -0700 Received: from multicasttech.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 07:32:46 -0700 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 861735; Wed, 25 Apr 2001 10:32:44 -0400 Message-ID: <3AE6E015.FB71812C@21rst-century.com> Date: Wed, 25 Apr 2001 10:32:54 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , 'Henning Schulzrinne' , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Flemming Andreasen wrote: > Jonathan Rosenberg wrote: > > > > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > > Sent: Wednesday, April 25, 2001 9:36 AM > > > To: Flemming Andreasen > > > Cc: rem-conf > > > Subject: Re: RTCP optional ? > > > > > > > > > This is peculiar - there must be a giant RTCP debating club be > > > somewhere, since I just got a similar question from somebody > > > working at > > > another large telecom company. > > > > Even more peculiar is that I too just got this question privately from > > someone working at a small telecom company. He indicated that Packetcable > > was debating whether to include RTCP or not. > > > > Unfortunately (IMHO) yes. > > > > > > > > > The answer is: SHOULD. > > > > > > Functions 1-3 SHOULD be used in all environments, but > > > particularly in > > > the IP multicast environment. RTP application designers > > > SHOULD avoid > > > mechanisms that can only work in unicast mode and will not scale to > > > larger numbers. Transmission of RTCP MAY be controlled > > > separately for > > > > I often get asked what the benefits are in unicast, point-to-point calls > > where no adaptation is performed. One clear benefit we have found is that > > RTCP is a good, end-to-end keepalive mechanism. Its sent even when there is > > no media being sent, and its sent very frequently. It can provide a much > > more robust and rapid indication of failure of the far-end device than > > something like SIP session timer. In fact, if the far end device fails, you > > might even get some ICMP errors to RTCP packets (which works even during > > silence), which can give failure detection in a matter of seconds. > > That was my assumption too, however if we can't rely on an RTP implementations > actually supporting RTCP, then this doesn't work (rather strange considering the > definition of an RTP session). If this is indeed the consensus then I think it > should to be pointed out more clearly in the spec. > > -- Flemming > > > > > > > This is in addition to the benefits outlined in the RTP bis draft. > > > > Also, note that for MCU based conferences, RTCP SDES is the only specified > > way to learn the identity of conference participants. So, if you ever want > > your gateway or phone to join a conference call, you might want to have RTCP > > support. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > -- > Flemming Andreasen > Cisco Systems Dear Flemming; If Real Network's players support RTCP they give no sign of it - they certainly do not use it by default. Do you have a contact at packetcable ? -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Wed Apr 25 08:27:08 2001 From rem-conf-request@es.net Wed Apr 25 08:27:07 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sR72-00047Z-00; Wed, 25 Apr 2001 08:21:52 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sR71-00047P-00; Wed, 25 Apr 2001 08:21:51 -0700 Received: from cs.columbia.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 08:21:50 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA25461; Wed, 25 Apr 2001 11:21:45 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3AE6EB89.CA0ABD8C@cs.columbia.edu> Date: Wed, 25 Apr 2001 11:21:45 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Flemming Andreasen wrote: > > > That was my assumption too, however if we can't rely on an RTP implementations > actually supporting RTCP, then this doesn't work (rather strange considering the > definition of an RTP session). If this is indeed the consensus then I think it > should to be pointed out more clearly in the spec. Wording suggestions are most welcome. I'm all for making this as clear as we possibly can. One approach would be to make this a 'MUST', for the social reasons you mention (i.e., my implementation laziness affects your reliability). Is there any reason for a data sender not to also send RTCP, particularly now that we have the ability to scale the rate, so that systems can dynamically adjust the right percentage via SDP? In other words, I would like operations people to make a conscious choice that RTCP somehow is bad for them in their specific circumstances rather than implementors making the choice for them. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 25 09:27:21 2001 From rem-conf-request@es.net Wed Apr 25 09:27:20 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sRzH-0005DS-00; Wed, 25 Apr 2001 09:17:55 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sRzG-0005DI-00; Wed, 25 Apr 2001 09:17:54 -0700 Received: from hazard.aciri.org ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 09:17:53 -0700 Received: from hazard.aciri.org (localhost [127.0.0.1]) by hazard.aciri.org (8.11.3/8.11.1) with ESMTP id f3PGIap22178; Wed, 25 Apr 2001 09:18:36 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Flemming Andreasen cc: rem-conf Subject: Re: RTCP optional ? In-reply-to: Your message of "Wed, 25 Apr 2001 09:13:44 EDT." <3AE6CD88.4FCDAD0F@cisco.com> Date: Wed, 25 Apr 2001 09:18:36 -0700 Message-ID: <22176.988215516@hazard.aciri.org> Sender: mjh@aciri.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >It is my understanding, that an RFC 1889 conformant RTP implementation >includes both RTP and RTCP (whether used for unicast or multicast), >however there is apparently not universal agreement on this. > >I'd appreciate it if somebody could either confirm or deny the above. Note that irrespective of the issue of receivers sending RTCP (which several people have commented on), the sender must send RTCP Sender Reports if receivers are to do A/V synchronization between RTP streams. SRs are the way RTP timestamps are mapped to a common media-independent time base. Cheers, Mark From rem-conf Wed Apr 25 09:36:22 2001 From rem-conf-request@es.net Wed Apr 25 09:36:22 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sSDE-0005rd-00; Wed, 25 Apr 2001 09:32:20 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sSDD-0005rS-00; Wed, 25 Apr 2001 09:32:19 -0700 Received: from sj-msg-core-4.cisco.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 09:32:18 -0700 Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA09153; Wed, 25 Apr 2001 09:32:22 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEU01259; Wed, 25 Apr 2001 09:32:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11842; Wed, 25 Apr 2001 09:32:16 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15078.64528.95608.772992@thomasm-u1.cisco.com> Date: Wed, 25 Apr 2001 09:32:16 -0700 (PDT) To: Jonathan Rosenberg Cc: "'Henning Schulzrinne'" , Flemming Andreasen , rem-conf Subject: RE: RTCP optional ? In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg writes: > I often get asked what the benefits are in unicast, point-to-point calls > where no adaptation is performed. One clear benefit we have found is that > RTCP is a good, end-to-end keepalive mechanism. Its sent even when there is > no media being sent, and its sent very frequently. It can provide a much > more robust and rapid indication of failure of the far-end device than > something like SIP session timer. In fact, if the far end device fails, you > might even get some ICMP errors to RTCP packets (which works even during > silence), which can give failure detection in a matter of seconds. Right. An even more pathological situation is when the a media gateway is partitioned from its mgc as can happen in MGCP/MEGACO. Without RTCP, the MG's could never know the difference between failure and VAD. At least with straight SIP you have the signaling plane to make a (possibly wrong) guess. The question I have is that I thought that there was a fair amount of concern that RTP do its part to be network friendly and not contribute to congestive collapse. How can a sender do that without feedback ala RTCP? To my mind, that alone should make RTCP a MUST. Mike From rem-conf Wed Apr 25 10:42:44 2001 From rem-conf-request@es.net Wed Apr 25 10:42:43 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sTDy-0007Wr-00; Wed, 25 Apr 2001 10:37:10 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sTDx-0007WA-00; Wed, 25 Apr 2001 10:37:09 -0700 Received: from real.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 10:37:08 -0700 Received: from jeffa-laptop.real.com ([172.23.106.160]) by real.com (8.9.2/8.9.0) with ESMTP id KAA00228; Wed, 25 Apr 2001 10:36:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425102317.02c964d8@mail.real.com> X-Sender: jeffa@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Apr 2001 10:36:00 -0700 To: tme@21rst-century.com, Flemming Andreasen From: Jeff Ayars Subject: Re: RTCP optional ? Cc: Jonathan Rosenberg , "'Henning Schulzrinne'" , rem-conf In-Reply-To: <3AE6E015.FB71812C@21rst-century.com> References: <3AE6DCDE.D8542A0A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:32 AM 4/25/2001 -0400, Marshall Eubanks wrote: >Dear Flemming; > >If Real Network's players support RTCP they give no sign of it - they >certainly do >not use it by default. Any time RTP is the data transport, RTCP is also used. By default RealPlayers use RDT - a proprietary data transport when playing from RealServers. We use RTP/RTCP when it is the transport selected by the server in the RTSP SETUP response, as well as with our "Scalable Multicast" feature. When we had Mbone access (in our old building before our ISP cut it off) we used NASA TV's H.261/DVI4 streams to test the Scalable Multicast feature, we still use VAT and VIC for testing. There were RTSP interop issues keeping us from taking to Darwin servers last year, I've not checked recently. When we hacked our RTSP client around the interop issues (support of OPTIONS and multiple transports in SETUP if I remember correctly) we were able to play just fine from Darwin servers using RTP/RTSP for media types we both supported. JEff From rem-conf Wed Apr 25 10:44:20 2001 From rem-conf-request@es.net Wed Apr 25 10:44:20 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sTKp-00008b-00; Wed, 25 Apr 2001 10:44:15 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sTKn-00008R-00; Wed, 25 Apr 2001 10:44:13 -0700 Received: from sj-msg-core-2.cisco.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 10:44:13 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27712; Wed, 25 Apr 2001 10:44:06 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f3PHhdc09604; Wed, 25 Apr 2001 10:43:39 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA25044; Wed, 25 Apr 2001 10:43:38 -0700 (PDT) Message-ID: <3AE70DB7.304EA9BE@cisco.com> Date: Wed, 25 Apr 2001 13:47:35 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <3AE6EB89.CA0ABD8C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Henning G. Schulzrinne" wrote: > Flemming Andreasen wrote: > > > > > > > That was my assumption too, however if we can't rely on an RTP implementations > > actually supporting RTCP, then this doesn't work (rather strange considering the > > definition of an RTP session). If this is indeed the consensus then I think it > > should to be pointed out more clearly in the spec. > > Wording suggestions are most welcome. I'm all for making this as clear > as we possibly can. One approach would be to make this a 'MUST', for the > social reasons you mention (i.e., my implementation laziness affects > your reliability). That would be the preferred outcome. > Is there any reason for a data sender not to also > send RTCP, particularly now that we have the ability to scale the rate, > so that systems can dynamically adjust the right percentage via SDP? In > other words, I would like operations people to make a conscious choice > that RTCP somehow is bad for them in their specific circumstances rather > than implementors making the choice for them. I agree. There's a lot of strong arguments for requiring RTCP and not a whole lot against so far. -- Flemming > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Flemming Andreasen Cisco Systems From rem-conf Wed Apr 25 10:57:51 2001 From rem-conf-request@es.net Wed Apr 25 10:57:50 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sTW8-0001I6-00; Wed, 25 Apr 2001 10:55:56 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sTW6-0001Hv-00; Wed, 25 Apr 2001 10:55:54 -0700 Received: from canospam.agcs.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 10:55:54 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id KAA24980 for ; Wed, 25 Apr 2001 10:55:53 -0700 (MST) Posted-Date: Wed, 25 Apr 2001 10:55:53 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Apr 25 10:55:54 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id KAA09329 for ; Wed, 25 Apr 2001 10:55:25 -0700 (MST) Received: from agcs.com ([130.131.56.60]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA4B02; Wed, 25 Apr 2001 10:55:51 -0700 Message-ID: <3AE70F93.96546325@agcs.com> Date: Wed, 25 Apr 2001 10:55:31 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: "Henning G. Schulzrinne" , Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <3AE6EB89.CA0ABD8C@cs.columbia.edu> <3AE70DB7.304EA9BE@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list One argument against requiring RTCP at this point might come from the folks with existing implementations that took advantage of it's optionality. RFC 1889 has been around for over five years now. That could be a lot of implementations! I think the approach that needs to be taken is to leave RTCP as optional so that these existing implementations are not suddenly sub-standard. If those putting requirements on a specific application decide to make it mandatory for their application (e.g.-PacketCable) then that's really their business, not the IETF's. Rex Flemming Andreasen wrote: > "Henning G. Schulzrinne" wrote: > > > Is there any reason for a data sender not to also > > send RTCP, particularly now that we have the ability to scale the rate, > > so that systems can dynamically adjust the right percentage via SDP? In > > other words, I would like operations people to make a conscious choice > > that RTCP somehow is bad for them in their specific circumstances rather > > than implementors making the choice for them. > > I agree. There's a lot of strong arguments for requiring RTCP and not a whole lot > against so far. > > -- Flemming > > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > -- > Flemming Andreasen > Cisco Systems From rem-conf Wed Apr 25 11:02:40 2001 From rem-conf-request@es.net Wed Apr 25 11:02:39 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sTaV-0001VZ-00; Wed, 25 Apr 2001 11:00:27 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sTaU-0001VI-00; Wed, 25 Apr 2001 11:00:26 -0700 Received: from cs.columbia.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 11:00:21 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA13139; Wed, 25 Apr 2001 14:00:10 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3AE710AA.24B6A89C@cs.columbia.edu> Date: Wed, 25 Apr 2001 14:00:10 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: Flemming Andreasen , Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <3AE6EB89.CA0ABD8C@cs.columbia.edu> <3AE70DB7.304EA9BE@cisco.com> <3AE70F93.96546325@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Rex Coldren wrote: > > One argument against requiring RTCP at this point might come from the > folks with existing implementations that took advantage of it's optionality. > RFC 1889 has been around for over five years now. That could be a lot > of implementations! RTCP was never optional. Optional has a well-defined meaning in RFC 2119, and the word MAY or "optional" is not used in the context of RFC 1889, 1890 or anywhere else. Recommended and SHOULD, which are used, have well-defined meanings, which loosely translated means "if you choose to not implement this, you face the consequences and you're not compliant (just conditionally compliant)". I have zero sympathy for people who want to force others into their own design trade-offs. > > I think the approach that needs to be taken is to leave RTCP as optional > so that these existing implementations are not suddenly sub-standard. If > those putting requirements on a specific application decide to make it > mandatory for their application (e.g.-PacketCable) then that's really their > business, not the IETF's. > They should then not claim that they're using RTP. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 25 11:04:42 2001 From rem-conf-request@es.net Wed Apr 25 11:04:42 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sTeZ-00013o-00; Wed, 25 Apr 2001 11:04:39 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sTeX-00013e-00; Wed, 25 Apr 2001 11:04:37 -0700 Received: from canospam.agcs.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 11:04:37 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id LAA26340 for ; Wed, 25 Apr 2001 11:04:33 -0700 (MST) Posted-Date: Wed, 25 Apr 2001 11:04:33 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Apr 25 11:04:34 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id LAA10034 for ; Wed, 25 Apr 2001 11:04:05 -0700 (MST) Received: from agcs.com ([130.131.56.60]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA4E95; Wed, 25 Apr 2001 11:04:30 -0700 Message-ID: <3AE7119A.60955D04@agcs.com> Date: Wed, 25 Apr 2001 11:04:10 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Flemming Andreasen , Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <3AE6EB89.CA0ABD8C@cs.columbia.edu> <3AE70DB7.304EA9BE@cisco.com> <3AE70F93.96546325@agcs.com> <3AE710AA.24B6A89C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Henning G. Schulzrinne" wrote: > Rex Coldren wrote: > > > > One argument against requiring RTCP at this point might come from the > > folks with existing implementations that took advantage of it's optionality. > > RFC 1889 has been around for over five years now. That could be a lot > > of implementations! > > RTCP was never optional. Optional has a well-defined meaning in RFC > 2119, and the word MAY or "optional" is not used in the context of RFC > 1889, 1890 or anywhere else. Recommended and SHOULD, which are used, > have well-defined meanings, which loosely translated means "if you > choose to not implement this, you face the consequences and you're not > compliant (just conditionally compliant)". > > I have zero sympathy for people who want to force others into their own > design trade-offs. Do you happen to remember why it was decided RTCP is a SHOULD as opposed to a SHALL/MUST? > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 25 11:14:35 2001 From rem-conf-request@es.net Wed Apr 25 11:14:35 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sTkm-0003Xw-00; Wed, 25 Apr 2001 11:11:04 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sTkm-0003Xm-00; Wed, 25 Apr 2001 11:11:04 -0700 Received: from cs.columbia.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 11:11:03 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA14097; Wed, 25 Apr 2001 14:10:43 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3AE7131A.B588FCA@cs.columbia.edu> Date: Wed, 25 Apr 2001 14:10:34 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: Flemming Andreasen , Jonathan Rosenberg , rem-conf Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <3AE6EB89.CA0ABD8C@cs.columbia.edu> <3AE70DB7.304EA9BE@cisco.com> <3AE70F93.96546325@agcs.com> <3AE710AA.24B6A89C@cs.columbia.edu> <3AE7119A.60955D04@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > Do you happen to remember why it was decided RTCP is a SHOULD as > opposed to a SHALL/MUST? RFC 1889 is unfortunately somewhat sloppy about capitalizing MUST, SHALL, etc., (not too surprising, given that it predates RFC 2119...). I don't think this received much discussion at the time, with the assumption being that everyone would implement it, except possibly for things like receiver reports on one-way links (like satellite). Since PacketCable presumably has probably no more compunction about ignoring MUST as opposed to SHOULD, based on experience and the more legalistic culture of today as opposed to five years ago, strengthening seems like the right thing to do at this point. We can't fix the past, but we can fix the future. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 25 13:42:09 2001 From rem-conf-request@es.net Wed Apr 25 13:42:09 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sW16-0005RA-00; Wed, 25 Apr 2001 13:36:04 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sW15-0005R0-00; Wed, 25 Apr 2001 13:36:03 -0700 Received: from multicasttech.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 13:36:02 -0700 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 870063; Wed, 25 Apr 2001 16:36:23 -0400 Message-ID: <3AE7353A.BDC60903@21rst-century.com> Date: Wed, 25 Apr 2001 16:36:11 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Michael Thomas CC: Jonathan Rosenberg , 'Henning Schulzrinne' , Flemming Andreasen , rem-conf Subject: Re: RTCP optional ? References: <15078.64528.95608.772992@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael Thomas wrote: > Jonathan Rosenberg writes: > > I often get asked what the benefits are in unicast, point-to-point calls > > where no adaptation is performed. One clear benefit we have found is that > > RTCP is a good, end-to-end keepalive mechanism. Its sent even when there is > > no media being sent, and its sent very frequently. It can provide a much > > more robust and rapid indication of failure of the far-end device than > > something like SIP session timer. In fact, if the far end device fails, you > > might even get some ICMP errors to RTCP packets (which works even during > > silence), which can give failure detection in a matter of seconds. > > Right. An even more pathological situation is when the > a media gateway is partitioned from its mgc as can happen > in MGCP/MEGACO. Without RTCP, the MG's could never know > the difference between failure and VAD. At least with > straight SIP you have the signaling plane to make a > (possibly wrong) guess. > > The question I have is that I thought that there was a > fair amount of concern that RTP do its part to be network > friendly and not contribute to congestive collapse. How > can a sender do that without feedback ala RTCP? To my > mind, that alone should make RTCP a MUST. > > Mike OK, but you have to explicitly allow for unicasting of RR back to sender for large SSM groups. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Wed Apr 25 13:48:41 2001 From rem-conf-request@es.net Wed Apr 25 13:48:41 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sWAJ-0005kS-00; Wed, 25 Apr 2001 13:45:35 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sWAI-0005kI-00; Wed, 25 Apr 2001 13:45:34 -0700 Received: from multicasttech.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 13:45:34 -0700 Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 870075; Wed, 25 Apr 2001 16:45:55 -0400 Message-ID: <3AE73776.FD2CEC7C@21rst-century.com> Date: Wed, 25 Apr 2001 16:45:42 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeff Ayars CC: Flemming Andreasen , Jonathan Rosenberg , 'Henning Schulzrinne' , rem-conf , tech team Subject: Re: RTCP optional ? References: <3AE6DCDE.D8542A0A@cisco.com> <4.3.2.7.2.20010425102317.02c964d8@mail.real.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Jeff; Jeff Ayars wrote: > At 10:32 AM 4/25/2001 -0400, Marshall Eubanks wrote: > >Dear Flemming; > > > >If Real Network's players support RTCP they give no sign of it - they > >certainly do > >not use it by default. > > Any time RTP is the data transport, RTCP is also used. By default When I use Real Player 8 Basic Build 6.0.9.584 on my Mac G4 to play our RTP MP3 streams, it does not send out receiver reports. It plays just fine, but it does not send RR's. Their existence would be appreciated. > > RealPlayers use RDT - a proprietary data transport when playing from > RealServers. We use RTP/RTCP when it is the transport selected by the > server in the RTSP SETUP response, as well as with our "Scalable Multicast" > feature. When we had Mbone access (in our old building before our ISP cut Want a PIM-SM tunnel ? > > it off) we used NASA TV's H.261/DVI4 streams to test the Scalable Multicast > feature, we still use VAT and VIC for testing. > > There were RTSP interop issues keeping us from taking to Darwin servers > last year, I've not checked recently. When we hacked our RTSP client > around the interop issues (support of OPTIONS and multiple transports in > SETUP if I remember correctly) we were able to play just fine from Darwin > servers using RTP/RTSP for media types we both supported. > > JEff -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From rem-conf Wed Apr 25 13:59:58 2001 From rem-conf-request@es.net Wed Apr 25 13:59:57 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sWH0-0006Ky-00; Wed, 25 Apr 2001 13:52:30 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sWGz-0006Km-00; Wed, 25 Apr 2001 13:52:29 -0700 Received: from nmh.informatik.uni-bremen.de ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 13:52:28 -0700 Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f3PKq9202321; Wed, 25 Apr 2001 22:52:09 +0200 (MEST) From: "Dr. Carsten Bormann" To: , "Flemming Andreasen" Cc: "rem-conf" Subject: RE: RTCP optional ? Date: Wed, 25 Apr 2001 22:52:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3AE70F93.96546325@agcs.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > One argument against requiring RTCP at this point might come from the > folks with existing implementations that took advantage of it's > optionality. Rex, you are supplying the most convincing argument why this MUST be a MUST. There are too many people out there that read SHOULD as "I don't have to do it before 2.0 and even then only if the customers are banging at my door". That is absolutely no good for interoperability. As people said, RTCP sender reports are REQUIRED for interoperability in a VAD setting. RTCP receiver reports are the only way a phone UI can indicate whether the call is still working. RTCP SDES is what will make phone conferencing useful some day (the day the phone UI people have picked up its meaning). And so on... RTCP always was an integral part of the RTP design; RTP would have been designed differently without RTCP. > RFC 1889 has been around for over five years now. That could be a lot > of implementations! Our IP-phone test lab people certainly can attest that there are a lot of shoddy implementations out there! Declaring them conformant retroactively, again, is no good for interoperability. Gruesse, Carsten From rem-conf Wed Apr 25 14:41:50 2001 From rem-conf-request@es.net Wed Apr 25 14:41:50 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sWy6-0007b6-00; Wed, 25 Apr 2001 14:37:02 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sWy5-0007aw-00; Wed, 25 Apr 2001 14:37:01 -0700 Received: from canospam.agcs.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 14:37:00 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id OAA20822 for ; Wed, 25 Apr 2001 14:36:59 -0700 (MST) Posted-Date: Wed, 25 Apr 2001 14:36:59 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Wed Apr 25 14:37:00 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id OAA27412 for ; Wed, 25 Apr 2001 14:36:31 -0700 (MST) Received: from agcs.com ([130.131.56.60]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA2725; Wed, 25 Apr 2001 14:36:57 -0700 Message-ID: <3AE74365.DB20BED9@agcs.com> Date: Wed, 25 Apr 2001 14:36:37 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Carsten Bormann" CC: Flemming Andreasen , rem-conf Subject: Re: RTCP optional ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This will be my last volley... What we are talking about here is changing a 5-year-old SHOULD to a MUST. It is that simple. Blame it on sloppy specification, bad editing, not having rules to live by or whatever, but tightening down requirements after time seems backwards >from the way things typically work in standards. This is not a commentary on my love for or hatred of RTCP. That's not the issue. RTCP clearly provides valuable capabilities, as pointed out by several mails on this thread. Cheers, Rex "Dr. Carsten Bormann" wrote: > > One argument against requiring RTCP at this point might come from the > > folks with existing implementations that took advantage of it's > > optionality. > > Rex, you are supplying the most convincing argument why this MUST be a MUST. > > There are too many people out there that read SHOULD as "I don't have to do > it before 2.0 and even then only if the customers are banging at my door". > That is absolutely no good for interoperability. > Gruesse, Carsten From rem-conf Wed Apr 25 14:52:06 2001 From rem-conf-request@es.net Wed Apr 25 14:52:05 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sX96-0000Za-00; Wed, 25 Apr 2001 14:48:24 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sX95-0000ZQ-00; Wed, 25 Apr 2001 14:48:23 -0700 Received: from sj-msg-core-4.cisco.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 14:48:22 -0700 Received: from oranlt ([171.69.210.12]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA20971; Wed, 25 Apr 2001 14:47:51 -0700 (PDT) From: "David R. Oran" To: , "'Flemming Andreasen'" Cc: "'Jonathan Rosenberg'" , "'rem-conf'" Subject: RE: RTCP optional ? Date: Wed, 25 Apr 2001 17:48:34 -0400 Organization: Cisco Systems Message-ID: <004101c0cdd1$7c357130$0cd245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 In-reply-to: <3AE6EB89.CA0ABD8C@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would personally fall in the "MUST" camp. If RTCP is to remain a SHOULD, I would make a fervent plea to require that the Session establishment protocol be required to indicate unambiguously whether a participant is going to send RTCP or not. That way receivers can make intelligent adaptation and liveness decisions based on whether to expect RTCP reports and senders can potentially do similarly. Dave. > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 25, 2001 11:22 AM > To: Flemming Andreasen > Cc: Jonathan Rosenberg; rem-conf > Subject: Re: RTCP optional ? > > Flemming Andreasen wrote: > > > > > > > That was my assumption too, however if we can't rely on an RTP > implementations > > actually supporting RTCP, then this doesn't work (rather strange > considering the > > definition of an RTP session). If this is indeed the consensus then I > think it > > should to be pointed out more clearly in the spec. > > Wording suggestions are most welcome. I'm all for making this as clear > as we possibly can. One approach would be to make this a 'MUST', for the > social reasons you mention (i.e., my implementation laziness affects > your reliability). Is there any reason for a data sender not to also > send RTCP, particularly now that we have the ability to scale the rate, > so that systems can dynamically adjust the right percentage via SDP? In > other words, I would like operations people to make a conscious choice > that RTCP somehow is bad for them in their specific circumstances rather > than implementors making the choice for them. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Apr 25 15:28:31 2001 From rem-conf-request@es.net Wed Apr 25 15:28:29 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sXj6-0001lb-00; Wed, 25 Apr 2001 15:25:36 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sXj4-0001lR-00; Wed, 25 Apr 2001 15:25:34 -0700 Received: from sj-msg-core-4.cisco.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 15:25:33 -0700 Received: from oranlt ([171.69.210.12]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA20791; Wed, 25 Apr 2001 15:24:34 -0700 (PDT) From: "David R. Oran" To: , "'Flemming Andreasen'" Cc: "'Henning G. Schulzrinne'" , "'Jonathan Rosenberg'" , "'rem-conf'" Subject: RE: RTCP optional ? Date: Wed, 25 Apr 2001 18:24:53 -0400 Organization: Cisco Systems Message-ID: <004601c0cdd6$8d6adc60$0cd245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 In-reply-to: <3AE70F93.96546325@agcs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: Rex Coldren [mailto:coldrenr@agcs.com] > Sent: Wednesday, April 25, 2001 1:56 PM > To: Flemming Andreasen > Cc: Henning G. Schulzrinne; Jonathan Rosenberg; rem-conf > Subject: Re: RTCP optional ? > > One argument against requiring RTCP at this point might come from the > folks with existing implementations that took advantage of it's > optionality. > RFC 1889 has been around for over five years now. That could be a lot > of implementations! > [[DRO>] I do not find that argument persuasive. Things change between Proposed and Drafty standard based on experience, and my personal view is that experience has provided a lot of motivation to make RTCP mandatory. > I think the approach that needs to be taken is to leave RTCP as optional > so that these existing implementations are not suddenly sub-standard. [[DRO>] But, they are! :-) IETF does not work like ITU or ISO where somehow documents get frozen in stone and you can't introduce new requirements between Proposed and Draft standard. It happens all the time. > If > those putting requirements on a specific application decide to make it > mandatory for their application (e.g.-PacketCable) then that's really > their > business, not the IETF's. > [[DRO>] I respectfully disagree. IETF standards are all about interoperability of protocols and if we get into hanging application-specific "profiles" and the like onto IETF protocols, we are headed into the same toilet the OSI stuff went into. It is equally troubling to have organizations raising the bar over what is required for IETF protocol implementations, as lowering it. Both actions hurt interoperability. Believe me, I've had enough pain on the DCS vs. "vanilla SIP" issues that to face something even 1/10th as complicated to sort out across my whole product line makes me rather nervous. Dave. > Rex > > Flemming Andreasen wrote: > > > "Henning G. Schulzrinne" wrote: > > > > > Is there any reason for a data sender not to also > > > send RTCP, particularly now that we have the ability to scale the rate, > > > so that systems can dynamically adjust the right percentage via SDP? > In > > > other words, I would like operations people to make a conscious choice > > > that RTCP somehow is bad for them in their specific circumstances > rather > > > than implementors making the choice for them. > > > > I agree. There's a lot of strong arguments for requiring RTCP and not a > whole lot > > against so far. > > > > -- Flemming > > > > > > > > -- > > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > -- > > Flemming Andreasen > > Cisco Systems > From rem-conf Wed Apr 25 17:20:18 2001 From rem-conf-request@es.net Wed Apr 25 17:20:17 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sZSD-0003Yg-00; Wed, 25 Apr 2001 17:16:17 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sZSB-0003YW-00; Wed, 25 Apr 2001 17:16:15 -0700 Received: from sj-msg-core-2.cisco.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 17:16:14 -0700 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA02270; Wed, 25 Apr 2001 17:15:36 -0700 (PDT) Received: from tmima-w2k.cisco.com (dhcp-171-70-57-68.cisco.com [171.70.57.68]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AIM01441; Wed, 25 Apr 2001 17:15:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425161424.03347ee8@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Apr 2001 17:14:47 -0700 To: "Daniel Feldman" From: Tmima Koren Subject: Re: TCRTP x ML/MC-PPP Cc: , "Doron Greenbaum" , "Alex Trigub" , "Eyal Gutman" , "Giora Ariel" In-Reply-To: <88BC9E379956AE4DB689CC5FF6F5A43D02DDCE@exchange.Ic4ic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Daniel Just negotiate MLPPP during PPP negotiation over the L2TP tunnel An MLPPP packet is a PPP packet so it can be tunneled via L2TP If you can use L2TPHC, your packet will be shorter - you don't include the UDP and L2TP headers when tunneling with L2TPHC. The stack ends with: PPPMux MLPPP IP (L2TPHC protocol) Here is a link to the L2TPHC draft: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tphc-03.txt Tmima At 10:10 AM 4/24/2001 +0200, Daniel Feldman wrote: > Hi Tmima, >how are you doing? Do you know if there is any standard way to use TCRTP >with ML/MC-PPP, i.e., segment the PPP packet (which can be a PPPmux >packet as well) into ML-PPP fragments and then with L2TP put them in >the same link and get some header compression done? The protocol stack >would be something like: >Data >UDP (xN) >IP (xN) >(PPPmux) >PPP >ML-PPP >L2TP >UDP >IP > > Thanks in advance, > looking forward to see you at the Pusan 3GPP meeting, > Daniel. > >~~~~~~~~~~~~~~~~~~~~~~~~ >Daniel Feldman >System Engineer, IC4IC ltd. >office: +972(4)959-4644 ext. 121 >mobile: +972(53)980-442 >fax: +972(4)959-4944 >~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Wed Apr 25 17:51:49 2001 From rem-conf-request@es.net Wed Apr 25 17:51:48 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sa0W-0004kw-00; Wed, 25 Apr 2001 17:51:44 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sa0U-0004km-00; Wed, 25 Apr 2001 17:51:42 -0700 Received: from rly-ip02.mx.aol.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 17:51:37 -0700 Received: from tot-wf1-we.proxy.aol.com (tot-wf1-we.proxy.aol.com [205.188.195.3]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id UAA27426; Wed, 25 Apr 2001 20:50:33 -0400 (EDT) Received: from icwlhn.org (AC8E8AD2.ipt.aol.com [172.142.138.210]) by tot-wf1-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f3Q0oS008972; Wed, 25 Apr 2001 20:50:28 -0400 (EDT) Message-ID: <3AE79AF4.24BCBDD@icwlhn.org> Date: Wed, 25 Apr 2001 20:50:12 -0700 From: Benny Bing X-Mailer: Mozilla 4.51 [en]C-CCK-MCD {MCIWORLDV2} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: amlist@takilab.k.dendai.ac.jp, alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, ccrc@dworkin.ccrc.wustl.edu, sc6wg4@ntd.comsat.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de Subject: CFP - Conference on Wireless LANs, PANs and Home Networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: BBing10199@aol.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS International Conference on Wireless LANs, PANs and Home Networks 5 - 7 December 2001, Singapore Conference Web Site: www.icwlhn.org Conference Outline The ICWLHN 2001 is the first conference to integrate technical presentations with live demos, allowing participants to see technologies in action. It is this uniqueness that separates ICWLHN from the rest of other conferences rather than compares ICWLHN to them. The conference will focus on practical application of current technologies with an eye towards the immediate future as well as innovative research. The purpose is to bring together engineers, practitioners, scientists, as well as industry professionals from manufacturers to service providers whose technical interests are wireless LANs (e.g., IEEE 802.11, HiperLAN, Wi-Fi) and personal area/home wireless networks (IEEE 802.15, Bluetooth, HomeRF, WAP). In doing so, technical ideas can be exchanged, potentially leading to the development of new innovations. Conference Highlights Keynote Speaker: Dr. Leonard Kleinrock, UCLA and Nomadix Inc Plenary Speakers: Greg Dicillio, Director, Wireless LAN Association Bob Heile, Chairman, IEEE 802.15 Working Group for WPANs Technology Presentors: Ericsson, Agilent, Mobilian, 3Com and more Paper Topics Suggestions for paper topics include the following: - Channel Modeling - Modulation - Signal Propagation - Channel Measurements - Multicarrier (OFDM) Systems - Smart Antennas - Emerging Technologies - Network Performance Analysis - Smart Spaces - Error Control Coding - Optical Wireless Networks - Standards Coexistence - Interference Control - Power Control and Management - Synchronization - Internetworking - QoS Provisioning - System Integration - Media Access - Receiver Implementation - Wireless Ethernet - Mobility Management - RF/IC Technology - Wireless Internet - Mobile Computing - Security - Wireless Local Loop Best Papers Authors of best papers will invited to submit full-length papers for possible publication in a special issue of the IEEE Personal Communications, a premier magazine of the IEEE Communications Society. The issue is scheduled to appear in June 2002. Submission Instructions Authors should submit an electronic version of a 2000-word abstract to bennybing@icwlhn.org. Preferred file formats include Microsoft Word and Acrobat PDF. The submission should include the name, affiliation, mailing address, email address, telephone and fax numbers of the corresponding author. The submission should be compressed if the file size is larger than 1 Mbyte. In view of an anticipated large number of submissions, it is important that authors keep to the 2000-word limit and discuss key points of their abstracts as concisely as possible. Important Deadlines 2000-Word Abstract Due: 15 June 2001. Notification of Acceptance: 15 August 2001. Camera-Ready Paper Due: 1 September 2001. Author Registration Due: 1 September 2001. International Advisory Committee: Lek Ariyavisitakul, Home Wireless Networks, USA. Ben Arzine, British Telecom, UK. Ender Ayanoglu, Cisco Systems, USA. Victor Bahl, Microsoft Research, USA. Yeheskel Bar-Ness, New Jersey Institute of Technology, USA. John Barr, Motorola, USA. Steve Bell, Agilent Interoperability Certification Labs, USA. Kwang-Cheng Chen, National Taiwan University, Taiwan. Justin Chuang, AT&T Research, USA. David Cohen, 3Com, USA. Greg Ennis, Symbol Technologies, USA. David Everitt, Swinburne University of Technology, Australia. Laurent Frelechoux, IBM Research, Switzerland. Alex Gelman, Panasonic Research, USA. Nada Golmie, National Institute of Standards and Technology, USA Lon Gowen, Mitre Corporation, USA. Bob Heile, Consultant, USA. Mika Kasslin, Nokia, Finland. Chih-Lin I, AT&T Research, USA. Konosuke Kawashima, NTT Advanced Technology, Japan. Parviz Kermani, IBM Research, USA. Leonard Kleinrock, University of California at Los Angeles, USA. Victor Li, University of Hong Kong, China. Pascal Lorenz, University of Haute Alsace, France. Teresa Meng, Stanford University, USA. Jouni Mikkonen, Nokia, Finland. Hiroyuki Morikawa, University of Tokyo, Japan. Guy Pujolle, University of Paris, France. Mike Sheppard, Ericsson, USA. Matthew Shoemake, Texas Instruments, USA. Tom Siep, Texas Instruments, USA. Roj Snellman, Intersil, USA. Peter Steenkiste, Carnegie Mellon University, USA. Richard van Nee, Lucent Technologies, The Netherlands. Sergio Verdu, Princeton University, USA. Naoaki Yamanaka, NTT Network Service Systems, Japan. Hatim Zaghloul, Wi-LAN, Canada. Rodger Ziemer, National Science Foundation, USA. From rem-conf Wed Apr 25 21:40:32 2001 From rem-conf-request@es.net Wed Apr 25 21:40:32 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sdVw-0001VA-00; Wed, 25 Apr 2001 21:36:24 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sdVu-0001V0-00; Wed, 25 Apr 2001 21:36:22 -0700 Received: from sj-msg-core-2.cisco.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 21:36:22 -0700 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA09107; Wed, 25 Apr 2001 21:36:44 -0700 (PDT) Received: from tmima-w2k.cisco.com (tmima-dsl4.cisco.com [144.254.211.45]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AIM07543; Wed, 25 Apr 2001 21:36:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425212953.03356e08@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Apr 2001 21:30:01 -0700 To: "Daniel Feldman" From: Tmima Koren Subject: Re: TCRTP x ML/MC-PPP Cc: , "Doron Greenbaum" , "Alex Trigub" , "Eyal Gutman" , "Giora Ariel" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Daniel Just negotiate MLPPP during PPP negotiation over the L2TP tunnel An MLPPP packet is a PPP packet so it can be tunneled via L2TP If you can use L2TPHC, your packet will be shorter - you don't include the UDP and L2TP headers when tunneling with L2TPHC. The stack ends with: PPPMux MLPPP IP (L2TPHC protocol) Here is a link to the L2TPHC draft: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tphc-03.txt Tmima At 10:10 AM 4/24/2001 +0200, Daniel Feldman wrote: > Hi Tmima, >how are you doing? Do you know if there is any standard way to use TCRTP >with ML/MC-PPP, i.e., segment the PPP packet (which can be a PPPmux >packet as well) into ML-PPP fragments and then with L2TP put them in >the same link and get some header compression done? The protocol stack >would be something like: >Data >UDP (xN) >IP (xN) >(PPPmux) >PPP >ML-PPP >L2TP >UDP >IP > > Thanks in advance, > looking forward to see you at the Pusan 3GPP meeting, > Daniel. > >~~~~~~~~~~~~~~~~~~~~~~~~ >Daniel Feldman >System Engineer, IC4IC ltd. >office: +972(4)959-4644 ext. 121 >mobile: +972(53)980-442 >fax: +972(4)959-4944 >~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Wed Apr 25 22:51:20 2001 From rem-conf-request@es.net Wed Apr 25 22:51:19 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14sed7-0002cx-00; Wed, 25 Apr 2001 22:47:53 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14sed6-0002cn-00; Wed, 25 Apr 2001 22:47:52 -0700 Received: from cs.columbia.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Wed, 25 Apr 2001 22:47:51 -0700 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id BAA19502; Thu, 26 Apr 2001 01:47:49 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id BAA26842; Thu, 26 Apr 2001 01:47:43 -0400 (EDT) Message-ID: <3AE7E1AC.B7D86A2A@cs.columbia.edu> Date: Thu, 26 Apr 2001 01:51:56 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: "Dr. Carsten Bormann" , Flemming Andreasen , rem-conf Subject: Re: RTCP optional ? References: <3AE74365.DB20BED9@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can somebody explain the harm to me of making an old conditionally compliant implementation non-compliant on paper? Particularly for this one, where compliance is about 30 lines of code for unicast if you send a constant RTCP message with minimal information (since you don't need to worry about timer scaling). Rex Coldren wrote: > > This will be my last volley... > > What we are talking about here is changing a 5-year-old SHOULD to a MUST. > It is that simple. Blame it on sloppy specification, bad editing, not having rules to > live by or whatever, but tightening down requirements after time seems backwards > from the way things typically work in standards. > > This is not a commentary on my love for or hatred of RTCP. That's not the issue. > RTCP clearly provides valuable capabilities, as pointed out by several mails on this > thread. > > Cheers, > Rex > > "Dr. Carsten Bormann" wrote: > > > > One argument against requiring RTCP at this point might come from the > > > folks with existing implementations that took advantage of it's > > > optionality. > > > > Rex, you are supplying the most convincing argument why this MUST be a MUST. > > > > There are too many people out there that read SHOULD as "I don't have to do > > it before 2.0 and even then only if the customers are banging at my door". > > That is absolutely no good for interoperability. > > > Gruesse, Carsten From rem-conf Thu Apr 26 04:20:22 2001 From rem-conf-request@es.net Thu Apr 26 04:20:22 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sjoo-0001zy-00; Thu, 26 Apr 2001 04:20:18 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sjom-0001zo-00; Thu, 26 Apr 2001 04:20:16 -0700 Received: from ietf.org ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 26 Apr 2001 04:20:15 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27866; Thu, 26 Apr 2001 07:20:13 -0400 (EDT) Message-Id: <200104261120.HAA27866@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-amr-07.txt Date: Thu, 26 Apr 2001 07:20:13 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format and file storage format for AMR and AMR-WB audio Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt, Q. Xie, S. Gupta Filename : draft-ietf-avt-rtp-amr-07.txt Pages : 28 Date : 25-Apr-01 This document specifies a real-time transport protocol (RTP) payload format to be used for AMR and AMR-WB speech encoded signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats. Furthermore, a file format for storage of AMR and AMR-WB speech data is specified. Two separate MIME type registrations, one for AMR and one for AMR-WB, describing both RTP payload format and storage format are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-amr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-amr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010425142625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010425142625.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Apr 26 09:59:20 2001 From rem-conf-request@es.net Thu Apr 26 09:59:19 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14soyb-0003y7-00; Thu, 26 Apr 2001 09:50:45 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14soyZ-0003xn-00; Thu, 26 Apr 2001 09:50:43 -0700 Received: from sbs.dave-world.net ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876; Thu, 26 Apr 2001 09:50:42 -0700 Received: from 63.118.137.11 by sbs.dave-world.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 2LL4GG48; Thu, 26 Apr 2001 12:07:49 -0500 From: docweb@masrawy.com To: unknown@unknown.com Reply-To: docweb@masrawy.com Subject: Free Personal Nutrition Test Message-Id: Date: Thu, 26 Apr 2001 09:50:43 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MEDICAL BREAKTHROUGH- Most physicians don't know that many of the prescriptions you are taking are depleting critical vitamins and minerals in your system that can SERIOUSLY impair your future health! Take our newly patented personal nutrition analysis online and find your perfect vitamin combination. Best of all it is FREE! To find out how send an email to docnutrition@arabia.com with the subject "test". To be removed from our list please send an email to docweb@masrawy.com with the subject "remove". From rem-conf Thu Apr 26 11:57:43 2001 From rem-conf-request@es.net Thu Apr 26 11:57:42 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sqxP-00057F-00; Thu, 26 Apr 2001 11:57:39 -0700 Received: from postal1.es.net ([198.128.3.205]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sqxN-000575-00; Thu, 26 Apr 2001 11:57:37 -0700 Received: from canospam.agcs.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Thu, 26 Apr 2001 11:57:37 -0700 Received: from mkultra.agcs.com (mkultra.agcs.com [130.131.74.113]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id LAA25371 for ; Thu, 26 Apr 2001 11:57:36 -0700 (MST) Posted-Date: Thu, 26 Apr 2001 11:57:36 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra.agcs.com ; Thu Apr 26 11:57:33 2001 -0700 Received: from pxmail2.agcs.com (pxsmtp.agcs.com [130.131.74.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id LAA21947 for ; Thu, 26 Apr 2001 11:57:07 -0700 (MST) Received: from agcs.com ([130.131.75.107]) by pxmail2.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA5B17; Thu, 26 Apr 2001 11:57:33 -0700 Message-ID: <3AE86F9F.A1588311@agcs.com> Date: Thu, 26 Apr 2001 11:57:36 -0700 From: "Rex Coldren" Reply-To: coldrenr@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Dr. Carsten Bormann" , Flemming Andreasen , rem-conf Subject: Re: RTCP optional ? References: <3AE74365.DB20BED9@agcs.com> <3AE7E1AC.B7D86A2A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Backward compatibility is always a tough issue... Rex P.S.-O.K. This really is my last volley :-) Henning Schulzrinne wrote: > Can somebody explain the harm to me of making an old conditionally > compliant implementation non-compliant on paper? > > Particularly for this one, where compliance is about 30 lines of code > for unicast if you send a constant RTCP message with minimal information > (since you don't need to worry about timer scaling). > > Rex Coldren wrote: > > > > This will be my last volley... > > > > What we are talking about here is changing a 5-year-old SHOULD to a MUST. > > It is that simple. Blame it on sloppy specification, bad editing, not having rules to > > live by or whatever, but tightening down requirements after time seems backwards > > from the way things typically work in standards. > > > > This is not a commentary on my love for or hatred of RTCP. That's not the issue. > > RTCP clearly provides valuable capabilities, as pointed out by several mails on this > > thread. > > > > Cheers, > > Rex > > > > "Dr. Carsten Bormann" wrote: > > > > > > One argument against requiring RTCP at this point might come from the > > > > folks with existing implementations that took advantage of it's > > > > optionality. > > > > > > Rex, you are supplying the most convincing argument why this MUST be a MUST. > > > > > > There are too many people out there that read SHOULD as "I don't have to do > > > it before 2.0 and even then only if the customers are banging at my door". > > > That is absolutely no good for interoperability. > > > > > Gruesse, Carsten From rem-conf Thu Apr 26 13:15:22 2001 From rem-conf-request@es.net Thu Apr 26 13:15:21 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14ss6D-0007C3-00; Thu, 26 Apr 2001 13:10:49 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14ss6B-0007Bt-00; Thu, 26 Apr 2001 13:10:47 -0700 Received: from gumby.cs.berkeley.edu ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 26 Apr 2001 13:10:47 -0700 Received: from bmrc.berkeley.edu (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with ESMTP id MAA16431; Thu, 26 Apr 2001 12:59:06 -0700 Message-ID: <3AE87F3A.5433A063@bmrc.berkeley.edu> Date: Thu, 26 Apr 2001 13:04:10 -0700 From: katherine reyes X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: 5/2 Berkeley Multimedia, Interfaces, and Graphics Seminar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces, and Graphics Seminar bmrc.berkeley.edu/mig Digital Video Bitstream Manipulation May 2, 2001, 1:10-2:30 p.m. PST Fujitsu Seminar Room (405 Soda Hall) Paul Haskell Harmonic, Inc. The entertainment video industry has almost completely migrated to the use of digital video distribution, based on MPEG-2. This talk will review the current state of today's video system architectures and will propose trends for the coming years. A number of these trends involve benefits of digital stream processing other than thoe of compression: easy storage, manipulation, multiplexing, editing, conditional access, etc. Bitrate-modification is an active area of research and development current. We will explore technologies used for bitrate-modification in different systems. These range from requantization to complicated multipass recording methods. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from:http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'), or you can visit: http://imj.ucsb.edu/sdr-monitor/ You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Apr 26 14:50:09 2001 From rem-conf-request@es.net Thu Apr 26 14:50:09 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14stYj-0000mC-00; Thu, 26 Apr 2001 14:44:21 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14stYi-0000m2-00; Thu, 26 Apr 2001 14:44:20 -0700 Received: from real.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Thu, 26 Apr 2001 14:44:19 -0700 Received: from jeffa-laptop.real.com ([172.23.106.160]) by real.com (8.9.2/8.9.0) with ESMTP id OAA09424; Thu, 26 Apr 2001 14:43:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20010426131845.02cd3988@mail.real.com> X-Sender: jeffa@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Apr 2001 13:26:04 -0700 To: tme@21rst-century.com From: Jeff Ayars Subject: Re: RTCP optional ? Cc: Flemming Andreasen , Jonathan Rosenberg , "'Henning Schulzrinne'" , rem-conf , tech team In-Reply-To: <3AE73776.FD2CEC7C@21rst-century.com> References: <3AE6DCDE.D8542A0A@cisco.com> <4.3.2.7.2.20010425102317.02c964d8@mail.real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 04:45 PM 4/25/2001 -0400, Marshall Eubanks wrote: >When I use Real Player 8 Basic Build 6.0.9.584 on my Mac G4 to play >our RTP MP3 streams, it does not send out receiver reports. > >It plays just fine, but it does not send RR's. Their existence would be >appreciated. I've verified RR's in the 8.0.3.412 basic player on Linux and 6.0.9.584 plus player on NT, looks like there may be a Mac player specific problem, looking into it. JEff From rem-conf Thu Apr 26 18:51:02 2001 From rem-conf-request@es.net Thu Apr 26 18:51:01 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14sxPN-0000Tw-00; Thu, 26 Apr 2001 18:50:57 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14sxPL-0000Tm-00; Thu, 26 Apr 2001 18:50:55 -0700 Received: from purple.east.isi.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Thu, 26 Apr 2001 18:50:54 -0700 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id VAA12021 for ; Thu, 26 Apr 2001 21:43:36 -0400 Message-Id: <200104270143.VAA12021@purple.east.isi.edu> To: rem-conf@es.net Subject: RTP interop statement Date: Thu, 26 Apr 2001 21:43:36 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just submitted draft-ietf-avt-rtp-interop-08.txt, which completes the RTP interoperability statement. Unfortunately, we are still missing interop reports for some features of the audio/video profile: - Canonicalisation of the passphrase - RTP over TCP - Audio codecs: 1016, GSM-HR, GSM-EFR, - Video codecs: MP2T, BT656, MP1S, MP2P, BMPEG This is a last call for interoperability reports: if you have implemented any of the above features, please contact the AVT chairs immediately. If implementations cannot be found, these features will not be present in the revision of RFC 1890. Thanks, Colin From rem-conf Fri Apr 27 01:19:52 2001 From rem-conf-request@es.net Fri Apr 27 01:19:51 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14t3OT-00006A-00; Fri, 27 Apr 2001 01:14:25 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14t3OR-000060-00; Fri, 27 Apr 2001 01:14:23 -0700 Received: from cs.columbia.edu ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 01:14:18 -0700 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA20983; Fri, 27 Apr 2001 04:14:17 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id EAA05988; Fri, 27 Apr 2001 04:14:10 -0400 (EDT) Message-ID: <3AE8A2DB.D43FC5B@cs.columbia.edu> Date: Thu, 26 Apr 2001 15:36:11 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: coldrenr@agcs.com CC: "Dr. Carsten Bormann" , Flemming Andreasen , rem-conf Subject: Re: RTCP optional ? References: <3AE74365.DB20BED9@agcs.com> <3AE7E1AC.B7D86A2A@cs.columbia.edu> <3AE86F9F.A1588311@agcs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Rex Coldren wrote: > > Backward compatibility is always a tough issue... Fortunately, not in this case. Compliant systems will not break non-RTCP systems (or vice versa). If the network operator decides to use RTCP for liveness detection, these non-RTCP systems may get inferior service (users may be billed for calls terminated earlier or the operator may limit the duration of silence periods), but that's unavoidable. From rem-conf Fri Apr 27 04:43:12 2001 From rem-conf-request@es.net Fri Apr 27 04:43:12 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14t6aS-0002Gb-00; Fri, 27 Apr 2001 04:39:00 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14t6aP-0002GR-00; Fri, 27 Apr 2001 04:38:57 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 04:38:56 -0700 Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3RBcsO15782 for ; Fri, 27 Apr 2001 13:38:54 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Apr 27 13:36:50 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 13:38:37 +0200 Message-ID: From: "Lars-Erik Jonsson (EPL)" To: "'rem-conf@es.net'" Subject: Tampering with RTP header fields in header compression Date: Fri, 27 Apr 2001 13:39:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id f3RBcsO15782 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On the ROHC WG mailing list, there have been proposals for "header compre= ssion" (not a real header compression as I known that term from implicitl= y being defined by all existing HC schemes) that does not work transparen= tly and not always decompress the headers to become the same as before co= mpression. The proponents have not been clear on whether they think non-t= ransparency can be allowed also for some fields in the transport and netw= ork layer protocols, but it seems like their main target is the RTP proto= col. What has been claimed is that the RTP timestamp and sequence number = do not always have to be correctly decompressed, and a typical case when = there for sure will incorrectness is for the packets following after a no= n-regular change in the timestamp (or after a loss resulting in a missing= sequence number). The reason for these arguments is that they want to tr= eat header information as "signaling" and allow that to be delayed betwee= n compressor and decompressor. The purpose is to justify a certain "heade= r compression" scheme. Even if the argumentation has only been around RTP= sequence numbers and timestamps, a solution like that would obviously af= fect all header fields in RTP/UDP/IP that some time change in a non-regul= ar way. With this mail, I would like to share with you some of the statements tha= t have been made on the ROHC list regarding RTP header field semantics an= d ask for comments. The first three quotations are regarding RTP header field semantic: 1) From: http://www.cdt.luth.se/rohc/msg01885.html | "...semantics differ from protocol to protocol. In the case | of RTP, the semantics are sequencing and timing. Furthermore, | the sequencing and timing do not have to be absolutely perfect | in the same way that they do for TCP sequence numbers. The | notion of "correct" and "incorrect" is softer in RTP. This is | why nobody is proposing "good enough" compression for TCP... | ...there is no notion of good enough in TCP---either it is | right or it is wrong." 2) From: http://www.cdt.luth.se/rohc/msg01888.html | "What does matter is what shared state exists between | compressor and decompressor and what shared state doesn't | exist. There is shared state for the IP addresses and UDP | ports that are being transmitted e2e. So it does make sense | to talk about e2e transparency there. There is not shared | state for the RTP sequence numbers and time-stamps, but these | are semantically softer values than the IPaddresses and UDP | ports. That is, they can tolerate some error." 3) From: http://www.cdt.luth.se/rohc/msg01901.html | "The authors of gehco have been very sensitive to the | end-to-end argument. They took a careful look at what the | semantics of the RTP header fields are, and made a reasoned=20 | decision that the bits can be changed without losing those | semantics." These statements says "they" have decided (after careful considerations) = that RTP semantics are kept even if the sequence number or timestamp bits= are changed on the wire between compressor and decompressor (i.e. betwee= n the RTP sender and the RTP receiver).=20 The fourth, and final, quotation is regarding SRTP. SRTP was brought up a= s an example showing that you can not "decide" that tampering with header= fields is allowed, based on some very restrictive assumptions about the = usage of RTP. 4) From: http://www.cdt.luth.se/rohc/msg01901.html | "> SRTP is RTP. | | SRTP is not quite RTP. SRTP expands the semantics of the | sequence number. Whereas before the semantics of the sequence | number field was to give the ordering of packets and some hint | as to how many are being dropped, SRTP expands the semantics | to be a signed cookie for use against replay attacks. | | Gehco preserves the semantics of (pure) RTP. It does not | preserve the semantics of SRTP. Why? Because SRTP is a | (slightly) different protocol." These are the quotations that are tightly related to the RTP semantics. F= or those who wants to take part of the whole story, please se the ROHC WG= mailing list.=20 It would be interesting to hear comments about this from the group defini= ng RTP and applications using RTP.=20 Cheers, /Lars-Erik ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research and Experiments Ericsson Research, Corporate Unit Ericsson Erisoft AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the = opinions of my company, if not explicitly stated. From rem-conf Fri Apr 27 05:26:46 2001 From rem-conf-request@es.net Fri Apr 27 05:26:45 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14t7EZ-00037p-00; Fri, 27 Apr 2001 05:20:27 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14t7EX-00037f-00; Fri, 27 Apr 2001 05:20:25 -0700 Received: from sippie.star2.net ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 05:20:24 -0700 Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.6.189) with ESMTP id for ; Fri, 27 Apr 2001 08:18:19 -0400 Received: from 21rst-century.com (1Cust116.tnt1.lorton.va.da.uu.net [63.23.102.116]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Fri, 27 Apr 2001 08:30:45 -0400 Message-ID: <3AE96479.CE0CD138@21rst-century.com> Date: Fri, 27 Apr 2001 08:22:17 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EPL)" CC: "'rem-conf@es.net'" Subject: Re: Tampering with RTP header fields in header compression References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello; This sounds very dangerous to me - almost like the result should not be called RTP - but it is not clear to me what they really mean. For the audio protocols and encoders / decoders I am familar with if the timestamps and/or the sequence numbers are not both in the correct order and with no induced gaps, you will break something (although some decoders only use timestamps, others, only sequence numbers, others, both). So the only transformation you can do to the time stamps and sequence numbers is to add (or subtract) an arbitrary constant to each, once. You cannot introduce gaps, scale them, or change the constant added, or you will break the playback. So, what do you mean by "there for sure will incorrectness is for the packets following after a non-regular change in the timestamp (or after a loss resulting in a missing sequence number)" ? If you mean that the timestamps & sequence numbers will have a break after dropped packets, you are correct. BUT you cannot arbitrarily change timestamps / sequence numbers after this gap. I know for sure that this will totally break our FEC erasure protection, and I suspect that it would break almost any FEC erasure protection. Also, don't forget that packets can both arrive out of order and be dropped. What if a packet from before the break arrives after the break (as is perfectly possible) ? So, I feel that I do not fully understand what is proposed (is there a I-draft ?), but my personal reaction is very negative. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ "Lars-Erik Jonsson (EPL)" wrote: > > On the ROHC WG mailing list, there have been proposals for "header compression" (not a real header compression as I known that term from implicitly being defined by all existing HC schemes) that does not work transparently and not always decompress the headers to become the same as before compression. The proponents have not been clear on whether they think non-transparency can be allowed also for some fields in the transport and network layer protocols, but it seems like their main target is the RTP protocol. What has been claimed is that the RTP timestamp and sequence number do not always have to be correctly decompressed, and a typical case when there for sure will incorrectness is for the packets following after a non-regular change in the timestamp (or after a loss resulting in a missing sequence number). The reason for these arguments is that they want to treat header information as "signaling" and allow that to be delayed between compressor and decompressor. The purpose is to > justify a certain "header compression" scheme. Even if the argumentation has only been around RTP sequence numbers and timestamps, a solution like that would obviously affect all header fields in RTP/UDP/IP that some time change in a non-regular way. > > With this mail, I would like to share with you some of the statements that have been made on the ROHC list regarding RTP header field semantics and ask for comments. > > The first three quotations are regarding RTP header field semantic: > > 1) From: http://www.cdt.luth.se/rohc/msg01885.html > | "...semantics differ from protocol to protocol. In the case > | of RTP, the semantics are sequencing and timing. Furthermore, > | the sequencing and timing do not have to be absolutely perfect > | in the same way that they do for TCP sequence numbers. The > | notion of "correct" and "incorrect" is softer in RTP. This is > | why nobody is proposing "good enough" compression for TCP... > | ...there is no notion of good enough in TCP---either it is > | right or it is wrong." > > 2) From: http://www.cdt.luth.se/rohc/msg01888.html > | "What does matter is what shared state exists between > | compressor and decompressor and what shared state doesn't > | exist. There is shared state for the IP addresses and UDP > | ports that are being transmitted e2e. So it does make sense > | to talk about e2e transparency there. There is not shared > | state for the RTP sequence numbers and time-stamps, but these > | are semantically softer values than the IPaddresses and UDP > | ports. That is, they can tolerate some error." > > 3) From: http://www.cdt.luth.se/rohc/msg01901.html > | "The authors of gehco have been very sensitive to the > | end-to-end argument. They took a careful look at what the > | semantics of the RTP header fields are, and made a reasoned > | decision that the bits can be changed without losing those > | semantics." > > These statements says "they" have decided (after careful considerations) that RTP semantics are kept even if the sequence number or timestamp bits are changed on the wire between compressor and decompressor (i.e. between the RTP sender and the RTP receiver). > > The fourth, and final, quotation is regarding SRTP. SRTP was brought up as an example showing that you can not "decide" that tampering with header fields is allowed, based on some very restrictive assumptions about the usage of RTP. > > 4) From: http://www.cdt.luth.se/rohc/msg01901.html > | "> SRTP is RTP. > | > | SRTP is not quite RTP. SRTP expands the semantics of the > | sequence number. Whereas before the semantics of the sequence > | number field was to give the ordering of packets and some hint > | as to how many are being dropped, SRTP expands the semantics > | to be a signed cookie for use against replay attacks. > | > | Gehco preserves the semantics of (pure) RTP. It does not > | preserve the semantics of SRTP. Why? Because SRTP is a > | (slightly) different protocol." > > These are the quotations that are tightly related to the RTP semantics. For those who wants to take part of the whole story, please se the ROHC WG mailing list. > > It would be interesting to hear comments about this from the group defining RTP and applications using RTP. > > Cheers, > /Lars-Erik > > ----------------------------------- > Lars-Erik Jonsson, M.Sc > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research and Experiments > Ericsson Research, Corporate Unit > Ericsson Erisoft AB > Box 920, S-971 28 Luleċ, Sweden > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Fax: +46 920 20 20 99 > Home: +46 920 999 57 > > My opinions are my personal opinions and should not be considered as the opinions of my company, if not explicitly stated. -- From rem-conf Fri Apr 27 06:35:37 2001 From rem-conf-request@es.net Fri Apr 27 06:35:36 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14t8JK-0004fF-00; Fri, 27 Apr 2001 06:29:26 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14t8JJ-0004ev-00; Fri, 27 Apr 2001 06:29:25 -0700 Received: from gw-nl4.philips.com ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 06:29:23 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA15278; Fri, 27 Apr 2001 15:29:13 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma015192; Fri, 27 Apr 01 15:29:14 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA06563; Fri, 27 Apr 2001 15:28:59 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA17641; Fri, 27 Apr 2001 15:27:58 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900017651196; Fri, 27 Apr 2001 15:40:42 +0200 To: Cc: Subject: Re: Tampering with RTP header fields in header compression Message-ID: <0056900017651196000002L062*@MHS> Date: Fri, 27 Apr 2001 15:40:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 04/27/01 15:26:41" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is probably true that a loss of precision in media timestamps is sometimes tolerable (for example a video timestamp expressed in milliseconds can stand errors of a few milliseconds) However generalizing this example to ANY RTP stream sounds dangerous, audio for example is other animal ! Quantifying the precision loss would be important. Errors in sequence numbers are I think very bad ! Since fragmented frames would be wrongly reconstructed this can lead to decoder crashes ! Regards Philippe Gentric Software architect MP4net - Philips Digital Networks Laboratoires d'Electronique Philips BP15 22 av. Descartes 94453 Limeil-Brevannes Cedex France tel: +33(0)145106812 fax: +33(0)145106960 philippe.gentric@philips.com http://www.mpeg-4player.com Lars-Erik.Jonsson@epl.ericsson.se on 27/04/2001 14:02:51 To: rem-conf@es.net@SMTP cc: =20 Subject: Tampering with RTP header fields in header compression Classification:=09 On the ROHC WG mailing list, there have been proposals for "header comp= ression" (not a real header compression as I known that term from impli= citly being defined by all existing HC schemes) that does not work tran= sparently and not always decompress the headers to become the same as before compression. The proponents have n= ot been clear on whether they think non-transparency can be allowed als= o for some fields in the transport and network layer protocols, but it = seems like their main target is the RTP protocol. What has been claimed is that the RTP timestamp and sequence = number do not always have to be correctly decompressed, and a typical c= ase when there for sure will incorrectness is for the packets following= after a non-regular change in the timestamp (or after a loss resulting in a missing sequence number). The= reason for these arguments is that they want to treat header informati= on as "signaling" and allow that to be delayed between compressor and d= ecompressor. The purpose is to justify a certain "header compression" scheme. Even if the argumentation has only= been around RTP sequence numbers and timestamps, a solution like that = would obviously affect all header fields in RTP/UDP/IP that some time c= hange in a non-regular way. With this mail, I would like to share with you some of the statements t= hat have been made on the ROHC list regarding RTP header field semantic= s and ask for comments. The first three quotations are regarding RTP header field semantic: 1) From: http://www.cdt.luth.se/rohc/msg01885.html | "...semantics differ from protocol to protocol. In the case | of RTP, the semantics are sequencing and timing. Furthermore, | the sequencing and timing do not have to be absolutely perfect | in the same way that they do for TCP sequence numbers. The | notion of "correct" and "incorrect" is softer in RTP. This is | why nobody is proposing "good enough" compression for TCP... | ...there is no notion of good enough in TCP---either it is | right or it is wrong." 2) From: http://www.cdt.luth.se/rohc/msg01888.html | "What does matter is what shared state exists between | compressor and decompressor and what shared state doesn't | exist. There is shared state for the IP addresses and UDP | ports that are being transmitted e2e. So it does make sense | to talk about e2e transparency there. There is not shared | state for the RTP sequence numbers and time-stamps, but these | are semantically softer values than the IPaddresses and UDP | ports. That is, they can tolerate some error." 3) From: http://www.cdt.luth.se/rohc/msg01901.html | "The authors of gehco have been very sensitive to the | end-to-end argument. They took a careful look at what the | semantics of the RTP header fields are, and made a reasoned | decision that the bits can be changed without losing those | semantics." These statements says "they" have decided (after careful considerations= ) that RTP semantics are kept even if the sequence number or timestamp = bits are changed on the wire between compressor and decompressor (i.e. = between the RTP sender and the RTP receiver). The fourth, and final, quotation is regarding SRTP. SRTP was brought up= as an example showing that you can not "decide" that tampering with he= ader fields is allowed, based on some very restrictive assumptions abou= t the usage of RTP. 4) From: http://www.cdt.luth.se/rohc/msg01901.html | "> SRTP is RTP. | | SRTP is not quite RTP. SRTP expands the semantics of the | sequence number. Whereas before the semantics of the sequence | number field was to give the ordering of packets and some hint | as to how many are being dropped, SRTP expands the semantics | to be a signed cookie for use against replay attacks. | | Gehco preserves the semantics of (pure) RTP. It does not | preserve the semantics of SRTP. Why? Because SRTP is a | (slightly) different protocol." These are the quotations that are tightly related to the RTP semantics.= For those who wants to take part of the whole story, please se the ROH= C WG mailing list. It would be interesting to hear comments about this from the group defi= ning RTP and applications using RTP. Cheers, /Lars-Erik ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research and Experiments Ericsson Research, Corporate Unit Ericsson Erisoft AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as th= e opinions of my company, if not explicitly stated. = From rem-conf Fri Apr 27 07:16:30 2001 From rem-conf-request@es.net Fri Apr 27 07:16:29 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14t92o-000637-00; Fri, 27 Apr 2001 07:16:26 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14t92m-00062x-00; Fri, 27 Apr 2001 07:16:24 -0700 Received: from postfix.informatik.uni-bonn.de ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 07:16:23 -0700 Received: by postfix.informatik.uni-bonn.de (Postfix) id F220070C56; Fri, 27 Apr 2001 16:14:06 +0200 (MEST) Delivered-To: lcn2001_info-out@alias.informatik.uni-bonn.de Received: by postfix.informatik.uni-bonn.de (Postfix, from userid 317) id C8E5670CC3; Fri, 27 Apr 2001 16:14:06 +0200 (MEST) Received: from maildrop.informatik.uni-bonn.de (triton.informatik.uni-bonn.de [131.220.4.18]) by postfix.informatik.uni-bonn.de (Postfix) with ESMTP id CB81970C56 for ; Fri, 27 Apr 2001 16:14:05 +0200 (MEST) (envelope-from lcn2001@cs.bonn.edu) (envelope-to LCN2001_Info@uran.informatik.uni-bonn.de) (internal use: ta=0, tu=1, te=0, am=-, au=NULL) Received: by maildrop.informatik.uni-bonn.de (Postfix) id 6E2D554111; Fri, 27 Apr 2001 16:14:05 +0200 (MEST) Received: from mailhost.informatik.uni-bonn.de (olymp.informatik.uni-bonn.de [131.220.4.1]) by maildrop.informatik.uni-bonn.de (Postfix) with ESMTP id B1E72540E3; Fri, 27 Apr 2001 16:14:04 +0200 (MEST) Received: from cs.bonn.edu (reykjavik.informatik.uni-bonn.de [131.220.6.141]) by mailhost.informatik.uni-bonn.de (Postfix) with ESMTP id 2C05662CD; Fri, 27 Apr 2001 16:14:05 +0200 (MET DST) Message-ID: <3AE97F75.9B84F91B@cs.bonn.edu> Date: Fri, 27 Apr 2001 16:17:25 +0200 From: LCN2001 Conference Account Organization: University of Bonn, Institute of Computer Science IV X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: lcn2001_info@cs.bonn.edu Subject: 3 weeks to IEEE LCN 2001 deadline Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-lcn2001_info@uran.informatik.uni-bonn.de X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (Apologies if you receive this note more than once, it was not intentional) Dear colleague, May 18, 2001 is the deadline for paper submissions for LCN 2001, the conference to be held at Tampa, Florida, from Nov. 14 to Nov. 16, 2001. Please note: Last year there was no deadline extension ... Enclosed please find the CFP. The LCN website is at http://www.ieeelcn.org Or go directly to http://www.cs.bonn.edu/LCN2001 for electronic submission. Hoping to see your presentation in Tampa in November 2001 ! Peter Martini (Program Chair for LCN 2001) ================================================================ CALL FOR PAPERS LCN 2001 The 26th Annual IEEE Conference on Local Computer Networks November 14 - 16, 2001 Embassy Suites USF, Tampa, Florida http://www.ieeelcn.org Sponsored by the IEEE Computer Society with support from Verizon, Nokia and the University of South Florida College of Engineering. Important dates: ---------------- Paper submission: May 18, 2001 Notification of acceptance: July 20, 2001 Camera-ready copy due: August 17, 2001 General Information: -------------------- The IEEE LCN conference is the premier conference on leading edge and practical computer networking. Our unique approach stimulates a workshop environment and enables an effective interchange among researchers, users, and product developers. During 25 years of this conference, we moved from the local network to the global Internet and World Wide Web. Now we move into the realm of Personal Area Networks, wearable networks and ubiquitous computing. Papers that cover these areas are explicitly sought and will be given preference. We encourage you to submit original papers describing research results or practical solutions. Paper topics include, but are not limited to: - Wireless Networks - Personal Area Networks - Wearable Networks - Always On / Always Connected - Mobility Management - Location-dependant services - Local Area Networks - Home Networks - Small Office Networks - Storage Area Networks - Optical Networks - High Speed Networks - Network Management - Network Security - Network Reliability - Network to the Home - Quality of Service / Congestion Control - Adaptive Applications - Anything-over-IP - IP-over-Anything - Performance Evaluation / Measurements - Protocol Design and Validation Authors are invited to submit full or short papers for presentation at the conference. Full papers should present novel perspectives within the general scope of the conference and may be up to 10 camera-ready pages in length. Short papers are an opportunity to present preliminary or interim results and are limited to 2 camera-ready pages in length. A best paper award will be presented. Several student travel scholarships may be available courtesy of the LCN corporate supporters. All papers must include title, complete contact information for all authors, abstract, and keywords on the cover page. The correspondence author must be clearly identified. Paper submission Instructions: ------------------------------ Papers must be submitted electronically. Manuscript submission instructions can be found at http://www.cs.bonn.edu/lcn2001. Authors for whom electronic submission presents a severe problem should contact the program chair: Prof. Dr. Peter Martini University of Bonn, Institute of Computer Science IV Roemerstr. 164 D-53117 Bonn, Germany E-mail: lcn2001@cs.bonn.edu LCN 2001 Committee: ------------------- General Chair: F. Huebner, Concert Technologies Program Chair: P. Martini, University of Bonn Program Co-Chair: B. Bakshi, BioNetrix Finance Chair: J. Bumblis, Veritas Software Corporate Relations Co-Chairs: K. Christensen, USF L. Jack, Market Solutions Tutorial Co-Chairs, Panel Co-Chairs : J.W. Atwood, Concordia University B. Stiller, ETH Zürich Arrangements Chair: K. Christensen, USF Ad-Hoc Chair: T. Strayer, BBN Webmaster: G. Kessler, Champlain College Overseas Advisors: S. Jha, University of New South Wales P. Martini, University of Bonn Standing Committee: M. McKee, Bowling Green G. Kessler, Champlain College E. Nolley, Strategic Growth H. Salwen, Audeon Networks K. Prasad, UMass-Lowell From rem-conf Fri Apr 27 07:20:57 2001 From rem-conf-request@es.net Fri Apr 27 07:20:56 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14t977-0006Jq-00; Fri, 27 Apr 2001 07:20:53 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14t976-0006Jg-00; Fri, 27 Apr 2001 07:20:52 -0700 Received: from sj-msg-core-4.cisco.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 07:20:51 -0700 Received: from oranlt ([171.69.210.12]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA23088; Fri, 27 Apr 2001 07:20:53 -0700 (PDT) From: "David R. Oran" To: "'Lars-Erik Jonsson \(EPL\)'" , Subject: RE: Tampering with RTP header fields in header compression Date: Fri, 27 Apr 2001 10:20:45 -0400 Organization: Cisco Systems Message-ID: <017d01c0cf25$401e48c0$0cd245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2511 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The minute you add SRTP packet authentication, this breaks totally. Don't do it. Dave. > -----Original Message----- > From: Lars-Erik Jonsson (EPL) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Friday, April 27, 2001 7:39 AM > To: 'rem-conf@es.net' > Subject: Tampering with RTP header fields in header compression >=20 > On the ROHC WG mailing list, there have been proposals for "header > compression" (not a real header compression as I known that term from > implicitly being defined by all existing HC schemes) that does not work > transparently and not always decompress the headers to become the same as > before compression. The proponents have not been clear on whether they > think non-transparency can be allowed also for some fields in the > transport and network layer protocols, but it seems like their main target > is the RTP protocol. What has been claimed is that the RTP timestamp and > sequence number do not always have to be correctly decompressed, and a > typical case when there for sure will incorrectness is for the packets > following after a non-regular change in the timestamp (or after a loss > resulting in a missing sequence number). The reason for these arguments is > that they want to treat header information as "signaling" and allow that > to be delayed between compressor and decompressor. The purpose is to > justify a certain "header compression" scheme. Even if the argumentation > has only been around RTP sequence numbers and timestamps, a solution like > that would obviously affect all header fields in RTP/UDP/IP that some time > change in a non-regular way. >=20 > With this mail, I would like to share with you some of the statements that > have been made on the ROHC list regarding RTP header field semantics and > ask for comments. >=20 > The first three quotations are regarding RTP header field semantic: >=20 > 1) From: http://www.cdt.luth.se/rohc/msg01885.html > | "...semantics differ from protocol to protocol. In the case > | of RTP, the semantics are sequencing and timing. Furthermore, > | the sequencing and timing do not have to be absolutely perfect > | in the same way that they do for TCP sequence numbers. The > | notion of "correct" and "incorrect" is softer in RTP. This is > | why nobody is proposing "good enough" compression for TCP... > | ...there is no notion of good enough in TCP---either it is > | right or it is wrong." >=20 > 2) From: http://www.cdt.luth.se/rohc/msg01888.html > | "What does matter is what shared state exists between > | compressor and decompressor and what shared state doesn't > | exist. There is shared state for the IP addresses and UDP > | ports that are being transmitted e2e. So it does make sense > | to talk about e2e transparency there. There is not shared > | state for the RTP sequence numbers and time-stamps, but these > | are semantically softer values than the IPaddresses and UDP > | ports. That is, they can tolerate some error." >=20 > 3) From: http://www.cdt.luth.se/rohc/msg01901.html > | "The authors of gehco have been very sensitive to the > | end-to-end argument. They took a careful look at what the > | semantics of the RTP header fields are, and made a reasoned > | decision that the bits can be changed without losing those > | semantics." >=20 > These statements says "they" have decided (after careful considerations) > that RTP semantics are kept even if the sequence number or timestamp bits > are changed on the wire between compressor and decompressor (i.e. between > the RTP sender and the RTP receiver). >=20 > The fourth, and final, quotation is regarding SRTP. SRTP was brought up as > an example showing that you can not "decide" that tampering with header > fields is allowed, based on some very restrictive assumptions about the > usage of RTP. >=20 > 4) From: http://www.cdt.luth.se/rohc/msg01901.html > | "> SRTP is RTP. > | > | SRTP is not quite RTP. SRTP expands the semantics of the > | sequence number. Whereas before the semantics of the sequence > | number field was to give the ordering of packets and some hint > | as to how many are being dropped, SRTP expands the semantics > | to be a signed cookie for use against replay attacks. > | > | Gehco preserves the semantics of (pure) RTP. It does not > | preserve the semantics of SRTP. Why? Because SRTP is a > | (slightly) different protocol." >=20 >=20 > These are the quotations that are tightly related to the RTP semantics. > For those who wants to take part of the whole story, please se the ROHC WG > mailing list. >=20 > It would be interesting to hear comments about this from the group > defining RTP and applications using RTP. >=20 >=20 > Cheers, > /Lars-Erik >=20 >=20 > ----------------------------------- > Lars-Erik Jonsson, M.Sc > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research and Experiments > Ericsson Research, Corporate Unit > Ericsson Erisoft AB > Box 920, S-971 28 Lule=E5, Sweden > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Fax: +46 920 20 20 99 > Home: +46 920 999 57 >=20 > My opinions are my personal opinions and should not be considered as the > opinions of my company, if not explicitly stated. From rem-conf Fri Apr 27 10:54:04 2001 From rem-conf-request@es.net Fri Apr 27 10:54:03 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14tCRM-00004g-00; Fri, 27 Apr 2001 10:54:00 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14tCRK-00004V-00; Fri, 27 Apr 2001 10:53:58 -0700 Received: from mail-out2.apple.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 10:53:58 -0700 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA15782 for ; Fri, 27 Apr 2001 10:53:57 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 27 Apr 2001 10:53:56 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA04723; Fri, 27 Apr 2001 10:53:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 27 Apr 2001 10:49:14 -0700 To: "Lars-Erik Jonsson (EPL)" From: Dave Singer Subject: Re: Tampering with RTP header fields in header compression Cc: "'rem-conf@es.net'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Whoa. If the decoder is presented fragments of two frames that previously had discontiguous sequence numbers, which are wrongly made contiguous, the results are, in DEC parlance 'unpredictable'. Decoders may crash. Audio packets typically have time-stamp set to the time-stamp + duration of the preceding packet. If the timestamp is wrong (a) by too much, you will get a drop-out (b) by too little, the results are again 'unpredictable' (two packets overlap). If a packet is wrongly re-numbered and time-stamped into a sequence, and then the correct packet arrives (it was re-ordered before the compression step), will it also be 'moved' into another position in the sequence? This is getting worse and worse. If a video frame is wrongly placed in sequence, then inter-frame coding will be scrod (a technical term). If a video frame in I/P/B coding (e.g. MPEG) is wrongly placed in sequence, then the results might be even more scrod. Isn't it true that RTSP presents some sequence numbers and/or timestamps at times? My analysis: there is a rock-bottom assumption that IP packets that arrive without checksum errors from the link or UDP layers are in fact unmodified. This breaks that assumption. I think this is bad. -- David Singer Apple Computer/QuickTime From rem-conf Fri Apr 27 11:50:29 2001 From rem-conf-request@es.net Fri Apr 27 11:50:28 2001 Received: from list by listserv2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 14tDJw-00015I-00; Fri, 27 Apr 2001 11:50:24 -0700 Received: from postal3.es.net ([198.128.3.207]) by listserv2.es.net with esmtp (Exim 1.92 #1) for rem-conf@listserv.es.net id 14tDJu-000158-00; Fri, 27 Apr 2001 11:50:22 -0700 Received: from east.isi.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 11:50:21 -0700 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA11088 for ; Fri, 27 Apr 2001 14:50:12 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f3RIoKi21966 for ; Fri, 27 Apr 2001 14:50:20 -0400 Message-Id: <200104271850.f3RIoKi21966@chiron.east.isi.edu> To: rem-conf@es.net Subject: Working group last call: AMR payload format Date: Fri, 27 Apr 2001 14:50:20 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two week working group last call on the RTP payload format and file storage format for AMR and AMR-WB audio. http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-07.txt Any final comments, corrections or suggestions should be made by Friday, 11th May 2001. If no substantive comments are received by this time, the payload format will be submitted to the IESG for consideration as a proposed standard RFC. Comments should be sent to the mailing list, or directly to the authors and working group chairs. Colin From rem-conf Fri Apr 27 17:29:57 2001 From rem-conf-request@es.net Fri Apr 27 17:29:56 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14tITp-0005rt-00; Fri, 27 Apr 2001 17:20:57 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14tITo-0005rj-00; Fri, 27 Apr 2001 17:20:56 -0700 Received: from mail-out2.apple.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Fri, 27 Apr 2001 17:20:55 -0700 Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id RAA09455 for ; Fri, 27 Apr 2001 17:20:55 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 27 Apr 2001 17:20:52 -0700 Received: from [17.202.37.158] (il0203a-dhcp30.apple.com [17.202.37.158]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id f3S0Klj14144; Fri, 27 Apr 2001 17:20:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <0056900017651196000002L062*@MHS> References: <0056900017651196000002L062*@MHS> Date: Fri, 27 Apr 2001 17:16:18 -0700 To: philippe.gentric@philips.com, Lars-Erik.Jonsson@epl.ericsson.se From: Kevin Marks Subject: Re: Tampering with RTP header fields in header compression Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 3:40 pm +0200 27/4/01, philippe.gentric@philips.com wrote: >It is probably true that a loss of precision in media timestamps >is sometimes tolerable (for example a video timestamp >expressed in milliseconds can stand errors of a few milliseconds) Not necessarily - if the frame was fragmented into several packets, some decoders will expect the timestamps to be identical for each of them to signify that they are the same frame. From rem-conf Sat Apr 28 12:48:59 2001 From rem-conf-request@es.net Sat Apr 28 12:48:59 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14taXo-00070F-00; Sat, 28 Apr 2001 12:38:16 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14taXn-000705-00; Sat, 28 Apr 2001 12:38:15 -0700 Received: from cs.columbia.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Sat, 28 Apr 2001 12:38:14 -0700 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA24038; Sat, 28 Apr 2001 15:38:12 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA12939; Sat, 28 Apr 2001 15:37:52 -0400 (EDT) Message-ID: <3AEAB6AE.F9DC4803@cs.columbia.edu> Date: Sat, 28 Apr 2001 05:25:18 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EPL)" CC: "'rem-conf@es.net'" Subject: Re: Tampering with RTP header fields in header compression References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id PAA24038 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Have "they" considered that RTP timestamps are used for media synchronization and thus can't just be modified, without causing rather peculiar synchronization problems? (It is not clear what modification they have in mind.) Before arguing this, can you summarize what errors are introduced and whether they are persistent or transient errors? "Lars-Erik Jonsson (EPL)" wrote: >=20 > On the ROHC WG mailing list, there have been proposals for "header comp= ression" (not a real header compression as I known that term from implici= tly being defined by all existing HC schemes) that does not work transpar= ently and not always decompress the headers to become the same as before = compression. The proponents have not been clear on whether they think non= -transparency can be allowed also for some fields in the transport and ne= twork layer protocols, but it seems like their main target is the RTP pro= tocol. What has been claimed is that the RTP timestamp and sequence numbe= r do not always have to be correctly decompressed, and a typical case whe= n there for sure will incorrectness is for the packets following after a = non-regular change in the timestamp (or after a loss resulting in a missi= ng sequence number). The reason for these arguments is that they want to = treat header information as "signaling" and allow that to be delayed betw= een compressor and decompressor. The purpose is to > justify a certain "header compression" scheme. Even if the argumentatio= n has only been around RTP sequence numbers and timestamps, a solution li= ke that would obviously affect all header fields in RTP/UDP/IP that some = time change in a non-regular way. >=20 > With this mail, I would like to share with you some of the statements t= hat have been made on the ROHC list regarding RTP header field semantics = and ask for comments. >=20 > The first three quotations are regarding RTP header field semantic: >=20 > 1) From: http://www.cdt.luth.se/rohc/msg01885.html > | "...semantics differ from protocol to protocol. In the case > | of RTP, the semantics are sequencing and timing. Furthermore, > | the sequencing and timing do not have to be absolutely perfect > | in the same way that they do for TCP sequence numbers. The > | notion of "correct" and "incorrect" is softer in RTP. This is > | why nobody is proposing "good enough" compression for TCP... > | ...there is no notion of good enough in TCP---either it is > | right or it is wrong." >=20 > 2) From: http://www.cdt.luth.se/rohc/msg01888.html > | "What does matter is what shared state exists between > | compressor and decompressor and what shared state doesn't > | exist. There is shared state for the IP addresses and UDP > | ports that are being transmitted e2e. So it does make sense > | to talk about e2e transparency there. There is not shared > | state for the RTP sequence numbers and time-stamps, but these > | are semantically softer values than the IPaddresses and UDP > | ports. That is, they can tolerate some error." >=20 > 3) From: http://www.cdt.luth.se/rohc/msg01901.html > | "The authors of gehco have been very sensitive to the > | end-to-end argument. They took a careful look at what the > | semantics of the RTP header fields are, and made a reasoned > | decision that the bits can be changed without losing those > | semantics." >=20 > These statements says "they" have decided (after careful considerations= ) that RTP semantics are kept even if the sequence number or timestamp bi= ts are changed on the wire between compressor and decompressor (i.e. betw= een the RTP sender and the RTP receiver). >=20 > The fourth, and final, quotation is regarding SRTP. SRTP was brought up= as an example showing that you can not "decide" that tampering with head= er fields is allowed, based on some very restrictive assumptions about th= e usage of RTP. >=20 > 4) From: http://www.cdt.luth.se/rohc/msg01901.html > | "> SRTP is RTP. > | > | SRTP is not quite RTP. SRTP expands the semantics of the > | sequence number. Whereas before the semantics of the sequence > | number field was to give the ordering of packets and some hint > | as to how many are being dropped, SRTP expands the semantics > | to be a signed cookie for use against replay attacks. > | > | Gehco preserves the semantics of (pure) RTP. It does not > | preserve the semantics of SRTP. Why? Because SRTP is a > | (slightly) different protocol." >=20 > These are the quotations that are tightly related to the RTP semantics.= For those who wants to take part of the whole story, please se the ROHC = WG mailing list. >=20 > It would be interesting to hear comments about this from the group defi= ning RTP and applications using RTP. >=20 > Cheers, > /Lars-Erik >=20 > ----------------------------------- > Lars-Erik Jonsson, M.Sc > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research and Experiments > Ericsson Research, Corporate Unit > Ericsson Erisoft AB > Box 920, S-971 28 Lule=E5, Sweden > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Fax: +46 920 20 20 99 > Home: +46 920 999 57 >=20 > My opinions are my personal opinions and should not be considered as th= e opinions of my company, if not explicitly stated. From rem-conf Sun Apr 29 03:09:25 2001 From rem-conf-request@es.net Sun Apr 29 03:09:24 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14to3d-0006IC-00; Sun, 29 Apr 2001 03:04:01 -0700 Received: from postal1.es.net [198.128.3.205] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14to3c-0006I2-00; Sun, 29 Apr 2001 03:04:00 -0700 Received: from bamboo-tech.bamboo-tech.com ([]) by postal1.es.net (ES.NET MTA 1) with ESMTP id IBA36876 for ; Sun, 29 Apr 2001 03:03:59 -0700 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id <2Y0ZBKTG>; Sun, 29 Apr 2001 13:11:28 +0200 Message-ID: <41290154A5B4D411B3A3000629B37979087EF2@EXCHANGE> From: Meir Fuchs To: rem-conf@es.net Subject: RE: RTCP optional ? Date: Sun, 29 Apr 2001 13:11:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Mandating RTCP for receivers, might have some implications as far as streaming over cellular networks is concerned. In cellular networks streaming media, flows from the network to the mobile terminal over a downlink (network to mobile) channel. Requiring RTCP transmission, will require receiving mobile terminals to acquire an uplink (mobile to network) channel. Acquiring an uplink is done by exchanging several messages between the mobile and the serving cell. The need to transmit does not do well for conserving battery power. Serving a great number of mobiles for streaming might cause undesirable load on the serving cell. This is just an example. The point I'm trying to make is that in certain network environments mandating RTCP on the receiver side might have a real "cost". By mandating it, you may force application providers for such networks to make difficult choices. The SHOULD has been there up until now so I believe the protocol is valid without the change. This also means that senders, at least some of them might be able to live without RTCP transmissions from receivers. While receiver RTCP seems basic, closing this option and at this point in time doesn't seem to be necessary. Regards, Meir. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, April 26, 2001 10:52 AM > To: coldrenr@agcs.com > Cc: Dr. Carsten Bormann; Flemming Andreasen; rem-conf > Subject: Re: RTCP optional ? > > > Can somebody explain the harm to me of making an old conditionally > compliant implementation non-compliant on paper? > > Particularly for this one, where compliance is about 30 lines of code > for unicast if you send a constant RTCP message with minimal > information > (since you don't need to worry about timer scaling). > > Rex Coldren wrote: > > > > This will be my last volley... > > > > What we are talking about here is changing a 5-year-old > SHOULD to a MUST. > > It is that simple. Blame it on sloppy specification, bad > editing, not having rules to > > live by or whatever, but tightening down requirements after > time seems backwards > > from the way things typically work in standards. > > > > This is not a commentary on my love for or hatred of RTCP. > That's not the issue. > > RTCP clearly provides valuable capabilities, as pointed out > by several mails on this > > thread. > > > > Cheers, > > Rex > > > > "Dr. Carsten Bormann" wrote: > > > > > > One argument against requiring RTCP at this point might > come from the > > > > folks with existing implementations that took advantage of it's > > > > optionality. > > > > > > Rex, you are supplying the most convincing argument why > this MUST be a MUST. > > > > > > There are too many people out there that read SHOULD as > "I don't have to do > > > it before 2.0 and even then only if the customers are > banging at my door". > > > That is absolutely no good for interoperability. > > > > > Gruesse, Carsten > From rem-conf Sun Apr 29 12:33:09 2001 From rem-conf-request@es.net Sun Apr 29 12:33:08 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14twrb-0003By-00; Sun, 29 Apr 2001 12:28:11 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14twra-0003Bo-00; Sun, 29 Apr 2001 12:28:10 -0700 Received: from cs.columbia.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Sun, 29 Apr 2001 12:28:09 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA21514; Sun, 29 Apr 2001 15:27:59 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3AEC6B3F.64D835D6@cs.columbia.edu> Date: Sun, 29 Apr 2001 15:27:59 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Meir Fuchs CC: rem-conf@es.net Subject: Re: RTCP optional ? References: <41290154A5B4D411B3A3000629B37979087EF2@EXCHANGE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please re-read my earlier post. Currently, we're talking about *implementing* RTCP, not necessarily *running* it. I pointed this out earlier in the context of satellite channels (also one-directional), but this seems to have gotten lost. We now have SDP options to adjust the rate of RTCP, including 0%. Operators and users should be given the choice; apparently, the current wording is used by some to weasle out of this. Meir Fuchs wrote: > > Hi, > > Mandating RTCP for receivers, might have some implications as far as > streaming over cellular networks is concerned. In cellular networks > streaming media, flows from the network to the mobile terminal over a > downlink (network to mobile) channel. Requiring RTCP transmission, will > require receiving mobile terminals to acquire an uplink (mobile to network) > channel. Acquiring an uplink is done by exchanging several messages between > the mobile and the serving cell. The need to transmit does not do well for > conserving battery power. Serving a great number of mobiles for streaming > might cause undesirable load on the serving cell. > This is just an example. The point I'm trying to make is that in certain > network environments mandating RTCP on the receiver side might have a real > "cost". By mandating it, you may force application providers for such > networks to make difficult choices. The SHOULD has been there up until now > so I believe the protocol is valid without the change. This also means that > senders, at least some of them might be able to live without RTCP > transmissions from receivers. While receiver RTCP seems basic, closing this > option and at this point in time doesn't seem to be necessary. > > Regards, > Meir. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Apr 30 01:51:17 2001 From rem-conf-request@es.net Mon Apr 30 01:51:17 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14u9DN-00015q-00; Mon, 30 Apr 2001 01:39:29 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14u9DL-00015g-00; Mon, 30 Apr 2001 01:39:27 -0700 Received: from bamboo-tech.bamboo-tech.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 01:39:26 -0700 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id <2Y0ZBKZD>; Mon, 30 Apr 2001 11:46:43 +0200 Message-ID: <41290154A5B4D411B3A3000629B37979087EFA@EXCHANGE> From: Meir Fuchs To: rem-conf@es.net Cc: "Henning G. Schulzrinne" Subject: RE: RTCP optional ? Date: Mon, 30 Apr 2001 11:46:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Sorry. That one flew right by me. Thanks for the clarification. Is there a document describing the semantics of this option? I looked through the MMUSIC page and could not find anything relevant. Best Regards, Meir. > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, April 29, 2001 9:28 PM > To: Meir Fuchs > Cc: rem-conf@es.net > Subject: Re: RTCP optional ? > > > Please re-read my earlier post. Currently, we're talking about > *implementing* RTCP, not necessarily *running* it. I pointed this out > earlier in the context of satellite channels (also > one-directional), but > this seems to have gotten lost. We now have SDP options to adjust the > rate of RTCP, including 0%. Operators and users should be given the > choice; apparently, the current wording is used by some to > weasle out of > this. > > Meir Fuchs wrote: > > > > Hi, > > > > Mandating RTCP for receivers, might have some > implications as far as > > streaming over cellular networks is concerned. In cellular networks > > streaming media, flows from the network to the mobile > terminal over a > > downlink (network to mobile) channel. Requiring RTCP > transmission, will > > require receiving mobile terminals to acquire an uplink > (mobile to network) > > channel. Acquiring an uplink is done by exchanging several > messages between > > the mobile and the serving cell. The need to transmit does > not do well for > > conserving battery power. Serving a great number of mobiles > for streaming > > might cause undesirable load on the serving cell. > > This is just an example. The point I'm trying to make is > that in certain > > network environments mandating RTCP on the receiver side > might have a real > > "cost". By mandating it, you may force application > providers for such > > networks to make difficult choices. The SHOULD has been > there up until now > > so I believe the protocol is valid without the change. This > also means that > > senders, at least some of them might be able to live without RTCP > > transmissions from receivers. While receiver RTCP seems > basic, closing this > > option and at this point in time doesn't seem to be necessary. > > > > Regards, > > Meir. > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From rem-conf Mon Apr 30 04:07:28 2001 From rem-conf-request@es.net Mon Apr 30 04:07:27 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uBUB-0002pD-00; Mon, 30 Apr 2001 04:04:59 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uBUA-0002p3-00; Mon, 30 Apr 2001 04:04:58 -0700 Received: from ietf.org ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 04:04:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04330; Mon, 30 Apr 2001 07:04:55 -0400 (EDT) Message-Id: <200104301104.HAA04330@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtptest-05.txt Date: Mon, 30 Apr 2001 07:04:55 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Testing Strategies Author(s) : C. Perkins, J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtptest-05.txt Pages : 20 Date : 27-Apr-01 This memo describes a possible testing strategy for RTP implementations. It is intended as an aid to implementors and does not specify a standard of any kind. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtptest-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtptest-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010427152421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtptest-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtptest-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152421.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Apr 30 04:07:28 2001 From rem-conf-request@es.net Mon Apr 30 04:07:27 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uBU0-0002op-00; Mon, 30 Apr 2001 04:04:48 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uBTz-0002of-00; Mon, 30 Apr 2001 04:04:47 -0700 Received: from ietf.org ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 04:04:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04298; Mon, 30 Apr 2001 07:04:44 -0400 (EDT) Message-Id: <200104301104.HAA04298@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-ulp-01.txt Date: Mon, 30 Apr 2001 07:04:44 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An RTP Payload Format for Generic FEC with Uneven Level Protection Author(s) : A. Li et al. Filename : draft-ietf-avt-ulp-01.txt Pages : Date : 27-Apr-01 This document specifies a payload format for generic forward error correction to achieve uneven level protection (ULP) of media encapsulated in RTP. It is an extension to the forward error correction scheme specified in RFC 2733 [1], and it is also based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary protection length and levels, in additional to using arbitrary block lengths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-ulp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-ulp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010427152354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ulp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ulp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152354.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Apr 30 04:07:28 2001 From rem-conf-request@es.net Mon Apr 30 04:07:27 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uBU5-0002p1-00; Mon, 30 Apr 2001 04:04:53 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uBU4-0002or-00; Mon, 30 Apr 2001 04:04:52 -0700 Received: from ietf.org ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 04:04:51 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04314; Mon, 30 Apr 2001 07:04:50 -0400 (EDT) Message-Id: <200104301104.HAA04314@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-interop-08.txt Date: Mon, 30 Apr 2001 07:04:50 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-rtp-interop-08.txt Pages : 8 Date : 27-Apr-01 It is required to demonstrate interoperability of RTP implementations in order to move the RTP specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-interop-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-interop-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-interop-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010427152412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152412.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Apr 30 05:27:02 2001 From rem-conf-request@es.net Mon Apr 30 05:27:01 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uCiD-0005Gy-00; Mon, 30 Apr 2001 05:23:33 -0700 Received: from postal2.es.net [198.128.3.206] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uCiB-0005Go-00; Mon, 30 Apr 2001 05:23:31 -0700 Received: from idolo.uv.es ([]) by postal2.es.net (ES.NET MTA 2) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 05:23:30 -0700 Received: from idolo.ci.uv.es (idolo.ci.uv.es [147.156.1.38]) by idolo.uv.es (8.9.3/8.9.3) with SMTP id OAA11157 for rem-conf@es.net; Mon, 30 Apr 2001 14:15:04 +0200 (METDST) From: Francisco Garcia Cortes To: rem-conf@es.net Subject: Videoconferencing using gateway between Netmeeting and Venue 2000 Date: Mon Apr 30 14:15:04 2001 X-Mailer: postman 1.4 Message-ID: <6748238491frangar3@alumni.uv.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! I'm trying to make a videoconferencing call using Netmeeting as a H.323 ter= minal with a Picturetel Venue 2000 as a H.320 terminal (that has three ISDN= lines) through a Cisco IP/VC 3520 gateway. How can i configure Netmeeting = to call the Venue 2000? Everyone know if i have to use the embedded gatekee= per to place calls between Netmeeting and Picturetel Venue 2000?=20 Thank you very much for your answers.=0A From rem-conf Mon Apr 30 07:43:35 2001 From rem-conf-request@es.net Mon Apr 30 07:43:35 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uErF-0006vP-00; Mon, 30 Apr 2001 07:41:01 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uErE-0006vF-00; Mon, 30 Apr 2001 07:41:00 -0700 Received: from exchange.Ic4ic.com ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 07:41:00 -0700 Received: through eSafe SMTP Relay 987951068; Mon Apr 30 17:42:20 2001 content-class: urn:content-classes:message Subject: RE: TCRTP x ML/MC-PPP Date: Mon, 30 Apr 2001 17:40:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D02DDD3@exchange.Ic4ic.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: TCRTP x ML/MC-PPP Thread-Index: AcDN7jznvwWBs6GsQx2Qe0VfTPey9ADnJDpw From: "Daniel Feldman" To: "Tmima Koren" Cc: , "Doron Greenbaum" , "Alex Trigub" , "Eyal Gutman" , "Giora Ariel" , "Dov Alon" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As I understood from the L2TPHC document: "- There will be only one tunnel between the LAC and the LNS". Does this mean that it is impossible to have both Header Compression and doing what was proposed in the L2TP document: "L2TP may also solve the multilink hunt-group splitting problem. Multilink PPP [RFC1990] requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Due to its ability to project a PPP session to a location other than the point at which it was physically received, L2TP can be used to make all channels terminate at a single NAS. This allows multilink operation even when the calls are spread across distinct physical NASs." Thanks a lot, Daniel. -----Original Message----- From: Tmima Koren [mailto:tmima@cisco.com] Sent: Thursday, April 26, 2001 2:15 AM To: Daniel Feldman Cc: rem-conf@es.net; Doron Greenbaum; Alex Trigub; Eyal Gutman; Giora Ariel Subject: Re: TCRTP x ML/MC-PPP Hi Daniel Just negotiate MLPPP during PPP negotiation over the L2TP tunnel An MLPPP packet is a PPP packet so it can be tunneled via L2TP If you can use L2TPHC, your packet will be shorter - you don't include the=20 UDP and L2TP headers when tunneling with L2TPHC. The stack ends with: PPPMux MLPPP IP (L2TPHC protocol) Here is a link to the L2TPHC draft: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tphc-03.txt Tmima At 10:10 AM 4/24/2001 +0200, Daniel Feldman wrote: > Hi Tmima, >how are you doing? Do you know if there is any standard way to use TCRTP >with ML/MC-PPP, i.e., segment the PPP packet (which can be a PPPmux >packet as well) into ML-PPP fragments and then with L2TP put them in >the same link and get some header compression done? The protocol stack >would be something like: >Data >UDP (xN) >IP (xN) >(PPPmux) >PPP >ML-PPP >L2TP >UDP >IP > > Thanks in advance, > looking forward to see you at the Pusan 3GPP meeting, > Daniel. > >~~~~~~~~~~~~~~~~~~~~~~~~ >Daniel Feldman >System Engineer, IC4IC ltd. >office: +972(4)959-4644 ext. 121 >mobile: +972(53)980-442 >fax: +972(4)959-4944 >~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf Mon Apr 30 08:33:05 2001 From rem-conf-request@es.net Mon Apr 30 08:33:04 2001 Received: from list by listserv1.es.net with local (Exim 1.81 #2) id 14uFeK-00007U-00; Mon, 30 Apr 2001 08:31:44 -0700 Received: from postal3.es.net [198.128.3.207] by listserv1.es.net with esmtp (Exim 1.81 #2) id 14uFeJ-00007K-00; Mon, 30 Apr 2001 08:31:43 -0700 Received: from east.isi.edu ([]) by postal3.es.net (ES.NET MTA 3) with ESMTP id IBA36876 for ; Mon, 30 Apr 2001 08:31:43 -0700 Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA07503 for ; Mon, 30 Apr 2001 11:31:32 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f3UFVfm31534 for ; Mon, 30 Apr 2001 11:31:41 -0400 Message-Id: <200104301531.f3UFVfm31534@chiron.east.isi.edu> To: rem-conf@es.net Subject: Working group last call: RTP testing strategies Date: Mon, 30 Apr 2001 11:31:41 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two week working group last call on the RTP Testing Strategies draft: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-05.txt Any final comments, corrections or suggestions should be made by Monday, 14th May 2001. If no substantive comments are received by this time, the draft will be submitted to the IESG for consideration as an informational RFC. Comments should be sent to the mailing list, or directly to the authors and working group chairs. Colin