From rem-conf Tue Aug 01 18:13:17 2000 From rem-conf-request@es.net Tue Aug 01 18:13:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13JmpI-0005WM-00; Tue, 1 Aug 2000 17:56:04 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13JmpF-0005WC-00; Tue, 1 Aug 2000 17:56:02 -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 WAA01130; Tue, 1 Aug 2000 22:56:48 +0100 Message-Id: <200008012156.WAA01130@purple.east.isi.edu> To: CURET Dominique FTRD/DMI/REN cc: casner@acm.org, rem-conf@es.net Subject: Re: contributions to MPEG on 4onIP In-Reply-To: Message from CURET Dominique FTRD/DMI/REN of "Wed, 12 Jul 2000 22:01:49 +0200." Date: Tue, 01 Aug 2000 17:56:47 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Coming back to this rather late, apologies.... --> CURET Dominique FTRD/DMI/REN writes: >dear Colin, dear all, > >As Colin suggested to me, as most of the IETF folks dnot belong to MPEG >and as only a good collaboration between us will bring palatable >standards, > >Here are two zipped MPEG contributions to which I participated, on the way >to declare MPEG signals carriage over RTP in the SDP syntax. > >One contribution (m6169) is an update of the work initialised by MPEG at >the last Geneva meeting (MPEG document N3381): " a framework for the >delivery of MPEG-4 over IP based protocols". That N3381 document is also >describing quickly a possible SDP solution. > >The second contribution (m6162), is not at all a framework, it is only >focussed on a modification of the SDP syntax. This syntax being more >widely studied. A couple of comments: - typical use of SDP is for media specific parameters to be signalled in an a=fmtp attribute, rather than as parameters to a=rtpmap. This affects section 3.1.3 of your document. - in section 3.2.2 you have to be a little careful, since a=rtpmap references a name in the MIME namespace. So any definition here will need a MIME registration. e.g. you have defined the MIME type audio/x-mpeg4-es here, perhaps. (same for x-mpeg-4-flexmux, etc) - for flexmux, again it may be better to use a=fmtp to specify the flexmux specific parameters (to avoid defining a new attribute type) Cheers, Colin From rem-conf Tue Aug 01 20:07:39 2000 From rem-conf-request@es.net Tue Aug 01 20:07:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13JoqL-00075i-00; Tue, 1 Aug 2000 20:05:17 -0700 Received: from ibsweb.ibsinc.co.jp [210.154.1.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 13JoqJ-00075Y-00; Tue, 1 Aug 2000 20:05:15 -0700 Received: from RP8 by ibsweb.ibsinc.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id PKQ6H7XD; Wed, 2 Aug 2000 12:09:52 +0900 Date: Wed, 02 Aug 2000 12:06:32 +0900 To: rem-conf@es.net From: xml@ibsinc.co.jp Subject: =?ISO-2022-JP?B?WE1MGyRCJEs0WD80JE4kIiRrMydNTSRYGyhC?= MIME-Version: 1.0 X-Mail-Agent: BSMTP DLL Nov 20 1999 by Tatsuo Baba Content-Type: text/plain; charset=ISO-2022-JP Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list XML$B$K4X?4$N$"$k3'MM$X(B $BEve5-$N%G%b$O2<5-(BURL$B$N(BXML_Demo$B$r%/%j%C%/$7$F$4Mw$K$J$l$^$9!#(B $B:y0f7C;0(B $BH,2&;R;T;R0BD.#1!]#2#4!]#5(B TEL$B!J(B0426$B!K(B46-8801$B!!(BFAX(0426)60-7002 $B!J3t!K%"%$!&%S! From rem-conf Wed Aug 02 06:16:12 2000 From rem-conf-request@es.net Wed Aug 02 06:16:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13JyJ0-0004LR-00; Wed, 2 Aug 2000 06:11:30 -0700 Received: from lumumba.luc.ac.be [193.190.9.252] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 13JyIy-0004LH-00; Wed, 2 Aug 2000 06:11:28 -0700 Received: (qmail 16247 invoked by uid 527); 2 Aug 2000 12:12:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Aug 2000 12:12:25 -0000 Date: Wed, 2 Aug 2000 14:12:25 +0200 (CEST) From: Jori To: rem-conf@es.net Subject: jrtplib v2.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everybody ! I just wanted to let you know that there is a new version of jrtplib, a RTP library which I wrote. It is an object-oriented library, written in C++. You can find out more about it at this url: http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html (note that this is a different url than the one I specified for the previous versions) Changes from version 2.3 include: - some bugfixes - support for both sending and receiving RTCP APP packets - support for RTP Header extensions Bye, Jori BTW: I've also put my thesis (for my university degree) online, in case anybody is interested. The subject is 'Voice over IP in networked virtual environments'. Just go to http://lumumba.luc.ac.be/jori/ and you'll find it... From rem-conf Wed Aug 02 12:30:11 2000 From rem-conf-request@es.net Wed Aug 02 12:30:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13K48A-0000So-00; Wed, 2 Aug 2000 12:24:42 -0700 Received: from wireless-132-194.ietf.marconi.com (purple.east.isi.edu) [147.73.132.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13K487-0000Se-00; Wed, 2 Aug 2000 12:24:39 -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 UAA01370; Wed, 2 Aug 2000 20:25:15 +0100 Message-Id: <200008021925.UAA01370@purple.east.isi.edu> To: rem-conf@es.net Subject: RTP interop discussion cc: orit@radvision.com Date: Wed, 02 Aug 2000 15:25:15 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, As discussed this morning, the RTP interop discussion will take place over dinner this evening. Meet at 5:30pm by the IETF message board. The interop drafts seem to have gone missing from the charter site, you can get copies >from http://www.east.isi.edu/~csp/misc/draft-ietf-avt-rtp-interop-03.txt and http://www.east.isi.edu/~csp/misc/draft-ietf-avt-profile-interop-01.txt and the matrix of what has been done so far is at http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/RTPinterop/ I'll bring print-outs of the latter. Colin From rem-conf Wed Aug 02 13:20:31 2000 From rem-conf-request@es.net Wed Aug 02 13:20:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13K4yl-0001tT-00; Wed, 2 Aug 2000 13:19:03 -0700 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13K4yj-0001tJ-00; Wed, 2 Aug 2000 13:19:02 -0700 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e72KIrs13208; Wed, 2 Aug 2000 23:18:55 +0300 (EET DST) Received: from esebh11nok.ntc.nokia.com (esebh11nok.ntc.nokia.com [131.228.10.108]) by mgw-i1.ntc.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e72DmsV21636; Wed, 2 Aug 2000 16:48:54 +0300 (EET DST) Received: by esebh11nok.ntc.nokia.com with Internet Mail Service (5.5.2650.10) id ; Wed, 2 Aug 2000 16:48:54 +0300 Message-ID: <25B79E9476BAD211811B0008C7894CDC033839EF@treis04nok> From: roberto.castagno@nokia.com To: jgoel@e-vue.com Cc: rem-conf@es.net Subject: RE: MPEG-4: DMIF signal mapping onto RTSP... Date: Wed, 2 Aug 2000 16:48:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jiten, > -----Original Message----- > From: EXT Goel, Jiten [mailto:jgoel@e-vue.com] > Sent: 12 July, 2000 18:20 > To: IETF AVT > Subject: MPEG-4: DMIF signal mapping onto RTSP... > > > Is there any discussion going on how to > map DMIF signals onto RTSP? > sorry for the late reply. By now you will probably have noticed the I-D by Dave Singer that summarizes the work done so far and addresses a number of key issues related to the transport of MPEG-4 over IP. (available at: http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-00.txt). If you want to read something more specific about the DMIF/RTSP mapping, you might have a look at the contribution that Nokia and the Tampere University of Technology presented on this topic at the MPEG meeting in Maui (input document ISO/IEC JTC1/SC29/WG11 MPEG99/m5554, Dec 99). The proposed solution was also included in the Verification Model 9.0 of MPEG-4 systems (output document ISO/IEC JTC1/SC29/WG11 MPEG99/N3198, subpart 4, December 1999). I hope this helps. Best regards Roberto > -Jiten > From rem-conf Thu Aug 03 04:29:16 2000 From rem-conf-request@es.net Thu Aug 03 04:29:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13KJ08-0001Ur-00; Thu, 3 Aug 2000 04:17:24 -0700 Received: from smtp1.wipro.net.in [202.177.128.47] by mail1.es.net with esmtp (Exim 1.81 #2) id 13KJ02-0001UW-00; Thu, 3 Aug 2000 04:17:23 -0700 Received: from bangalore.WIPRO.NET ([172.16.50.15]) by smtp1.wipro.net.in (Netscape Messaging Server 4.15) with ESMTP id FYPRHN00.02M for ; Thu, 3 Aug 2000 16:50:11 +0530 Received: by BANGALORE with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Aug 2000 16:48:05 +0530 Message-ID: From: Vivek Bhagwatkar To: rem-conf@es.net Subject: Video conferencing Date: Thu, 3 Aug 2000 16:48:05 +0530 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 I want to discuss about Videoconferencing, is this the right group to address ? Regards, Vivek From rem-conf Thu Aug 03 11:38:41 2000 From rem-conf-request@es.net Thu Aug 03 11:38:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13KPpW-0005xs-00; Thu, 3 Aug 2000 11:34:54 -0700 Received: from wireless-135-151.ietf.marconi.com (purple.east.isi.edu) [147.73.135.151] by mail1.es.net with esmtp (Exim 1.81 #2) id 13KPpU-0005xg-00; Thu, 3 Aug 2000 11:34:53 -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 TAA01474 for ; Thu, 3 Aug 2000 19:35:06 +0100 Message-Id: <200008031835.TAA01474@purple.east.isi.edu> To: rem-conf@es.net Subject: AVT slides Date: Thu, 03 Aug 2000 14:35:05 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, A reminder that those who presented in the AVT sessions this week should send me copies of your slides, for inclusion in the minutes. Thanks, Colin From rem-conf Fri Aug 04 15:48:19 2000 From rem-conf-request@es.net Fri Aug 04 15:48:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Kq27-0002Fm-00; Fri, 4 Aug 2000 15:33:39 -0700 Received: from c017-h021.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.235] by mail1.es.net with smtp (Exim 1.81 #2) id 13Kq25-0002FI-00; Fri, 4 Aug 2000 15:33:37 -0700 Received: (cpmta 12524 invoked from network); 4 Aug 2000 15:32:36 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 4 Aug 2000 15:32:36 -0700 X-Sent: 4 Aug 2000 22:32:36 GMT Received: from localhost ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id PAA30535; Fri, 4 Aug 2000 15:32:32 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 4 Aug 2000 15:36:06 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net cc: Allison Mankin , Scott Bradner Subject: Considering LIPE proposal in AVT working group Message-ID: Sender: casner@packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group, and the Transport Area Directors: At this IETF meeting we had a presentation on "A LightWeight IP Encapsulation (LIPE) Scheme" by Mooi Chuah. This draft proposes to multiplex multiple streams of low bit rate audio (or multimedia) packets into a single UDP/IP session or IP session. This would be used, for example, over the T1/E1 links in wireless access networks between base stations and mobile switching centers. We have discussed multiplexing in AVT over several past meetings, and we have selected a scheme that combines RTP header compression + PPP multiplexing + compressed L2TP. The LIPE draft contends that this scheme is too complex and that the services provided by RTP are not needed for this application. See the draft for details. Therefore, this proposal does not fit within the scope of the current AVT charter which is to advance RTP to draft standard and to complete a set of payload formats using RTP. We could decide to expand our charter to include development of additional protocols for audio/video transport as alternatives to RTP. It would also be possible to charter a new working group to develop a new protocol with a different set of requirements. I am sending this message to the working group and to the Area Directors to seek comment on whether either of these actions would be justified for this proposal and which would be more appropriate. Note that this draft essentially proposes the development of a new transport protocol. As I said during the recent AVT meeting, getting an IP protocol number, as would be needed for a new transport protocol running over IP, is intentionally somewhat difficult. There is a threshold for standardizing a new transport protocol because having multiple choices for similar operations impairs interoperability, increases network maintenance and management complexity, etc. That is, a new proposal should provide a significant improvment in functionality, efficiency or some other dimension to justify its standardization. In the LIPE draft there is a comparison of the efficiencies of several schemes, and a graph was shown during the presentation (which should be posted soon along with slides from the other presentations). Does this draft meet the threshold of significant improvement? -- Steve From rem-conf Fri Aug 04 16:55:41 2000 From rem-conf-request@es.net Fri Aug 04 16:55:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13KrBA-0003nM-00; Fri, 4 Aug 2000 16:47:04 -0700 Received: from sjc3-1.relay.mail.uu.net [199.171.54.122] by mail1.es.net with esmtp (Exim 1.81 #2) id 13KrB8-0003nC-00; Fri, 4 Aug 2000 16:47:02 -0700 Received: from 21rst-century.com by sjc3sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjavv00437; Fri, 4 Aug 2000 23:46:58 GMT Message-ID: <398B559E.EBC1762B@21rst-century.com> Date: Fri, 04 Aug 2000 19:45:33 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: 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 Stephen; Stephen Casner wrote: > To the AVT working group: > > I'd like to call your attention, for both those who are here at IETF > and those who are not, to the new sections on congestion control that > were added to the recent revisions of the RTP spec and profile drafts > as a result of the discussion at the last IETF: > > draft-ietf-avt-rtp-new-08.txt / .ps > draft-ietf-avt-profile-new-09.txt / .ps > I cannot find the .ps version of the profile, either on the working group charter or at the ftp site. > > In the RTP spec, the congestion control discussion is in a new Section > 10, with references in Sections 6 and 13. It simply establishes the > requirement for congestion control in RTP, and defers definition of > any specific behaviors to profiles because they are context-specific. > > In the profile, a new "Congestion" item was added in Section 2 using > the text that Mark Handley provided in response to my request at the > last IETF meeting. Again, the requirements are described only in > general terms because specific algorithms have not been devised yet > for multicast congestion control. > > ---> Is this text in both documents appropriate and sufficient? > > -- Steve The profile draft states : If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput that is not less the RTP flow is achieving. I think that this is over-simplistic, and, if really followed, would cause UDP traffic to tend to zero in the presence of TCP traffic. We have been running UDP tests from DC to LA across several AS's. In our UDP streaming tests, network "congestion" is generally actually UDP versus TCP "contention". In cross country transmission tests, I rarely see as much as 2% packet loss when the end user is ONLY running a UDP session, and generally the loss is << 1%. However, if you are receiving a audio UDP stream over a narrow pipe, such as a DSL or ISDN line, and start up a TCP connection, such as a ftp file download, you will experience packet loss as the TCP slow start and the UDP fight it out. This is true even though the MEAN TCP and UDP throughput is fairly reasonable. The jitter will also increase, as the following example makes clear : Suppose you are sending 90 kbps MP3 as UDP over a 128 kbps ISDN line. Each MP3 packet takes about 19 msec to transmit, and they are sent every 26 msec or so, leaving a 7 msec "hole" for other data. Suppose that you start an ftp session with 1500 byte packets (the most common size on the network, due to Ethernet restrictions). This will take about 100 msec to put through the pipe. So, even if no packets are lost, sending one TCP packet will delay about 3 or 4 UDP MP3 packets, causing considerable jitter. Under slow start, the TCP session will send one such packet, then two, etc., until there is packet loss. Given the size of these packets, when this happens (in this example) several MP3 packets will be lost in a row. I would fear that any simple minded congestion monitoring would then conclude that there was congestion, and ramp down the UDP. If the TCP was on-going, this process would repeat until the UDP gave up. Two TCP connections with the same parameters would, both in theory and in our tests, perform much better, as both would tend to average usage of a little less than 1/2 the pipe bandwidth. In addition, how would you determine what a TCP flow "would achieve" in a real-world multicast situation, where you cannot run such a flow, is very unclear, at least to me. (RED probably helps a lot for true network congestion in the backbone, but our tests indicate that there is very little buffer available for a typical ISDN last hop router, of order 1 or 2 TCP packets, so it may not be so good for last-hop contention problems. This is still unclear to me.) I would therefore change the profile to read : "If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable for a receiver if the RTP flow to that receiver achieves an average throughput that is not less than 90% of the nominal bandwidth for that RTP flow." 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Fri Aug 04 19:50:37 2000 From rem-conf-request@es.net Fri Aug 04 19:50:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13KtzH-0005p2-00; Fri, 4 Aug 2000 19:46:59 -0700 Received: from (smtp.azlan.nl) [193.173.101.198] by mail1.es.net with esmtp (Exim 1.81 #2) id 13KtzF-0005ob-00; Fri, 4 Aug 2000 19:46:58 -0700 Received: from 208.31.238.63 (unverified) by smtp.azlan.nl (Content Technologies SMTPRS 4.0.1) with SMTP id ; Fri, 4 Aug 2000 23:45:45 +0200 Message-ID: <000056dd7c8d$00001db0$00001371@> To: From: harrisonfd@europe.com Subject: Are You Tired of Your Bulk Site Going Down? Date: Fri, 04 Aug 2000 15:29:55 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

The Ultimate Bulk Web Hosting Service


Are You Tired of:
- bulk hosting companies not deliveri= ng
- kissing your money good-bye
- your site always going down

Consistency and <= FONT COLOR=3D"#000000" SIZE=3D5 PTSIZE=3D14>Integrity are the key points our business is built upon.<= FONT COLOR=3D"#008080" SIZE=3D5 PTSIZE=3D14>

- We have been in the= industry for over 3 years
- We host everything = on our own systems.
Prices

$3500 a month
-one-time setup fee of $500 not include= d (No Pornography, I have morals against such junk)

Your site will be fully operation within 24 hours of funds being received.=
- unlimited traffic and bulk mailing allowed

Bulk advertising is the most profitable home based business on the planet!=
Keeping your site up 24/7 to take orders is a must, and it's our business!= !

The old saying has never been more true.
"You get what you = pay for."

S= erious inquiries only=

Please Call 407-510-2657
and a representative will return your call.






Admin
Internet Services
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.
If you are a Washington resident or otherwise wish to be
removed from this list, further transmissions to you by the sender
of this email may be stopped at no cost to you by clicking here


Replying to this email won't remove you please click here to be removed.



From rem-conf Sun Aug 06 00:11:30 2000 From rem-conf-request@es.net Sun Aug 06 00:11:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LKMV-0001fg-00; Sat, 5 Aug 2000 23:56:43 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LKMT-0001fW-00; Sat, 5 Aug 2000 23:56:41 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e766uNE17236; Sun, 6 Aug 2000 08:56:23 +0200 (MET DST) From: "Dr. Carsten Bormann" To: , "Stephen Casner" Cc: Subject: RE: New congestion control text in RTP spec Date: Sun, 6 Aug 2000 08:56:12 +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) In-Reply-To: <398B559E.EBC1762B@21rst-century.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > The profile draft states : > > If best-effort service is being used, RTP receivers SHOULD > monitor packet loss to ensure that the packet loss rate is > within acceptable parameters. Packet loss is considered > acceptable if a TCP flow across the same network path and > experiencing the same network conditions would achieve an > average throughput that is not less the RTP flow is > achieving. > > [...] several MP3 packets will be lost in a row. I would fear that any > simple minded > congestion monitoring would then conclude that there was congestion, and > ramp down the UDP. Then don't use a simple minded congestion monitoring scheme! Schemes like TFRC have been designed to compete fairly with TCP. (However, in your example, where you send 90 kbit/s RTP over a 128 kbit/s link, TFRC would still try to regulate that down to around 64 kbit/s if you have a bulk data TCP connection going at the same time.) > "If best-effort service is being used, RTP receivers SHOULD > monitor packet loss to ensure that the packet loss rate is > within acceptable parameters. Packet loss is considered > acceptable for a receiver if the RTP flow to that receiver achieves an > average throughput that is not less than 90% of the nominal > bandwidth for that RTP flow." Now that would be a "simple minded congestion monitoring" scheme, indeed! Gruesse, Carsten From rem-conf Sun Aug 06 00:28:27 2000 From rem-conf-request@es.net Sun Aug 06 00:28:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LKlh-0002XK-00; Sun, 6 Aug 2000 00:22:45 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LKlf-0002Wm-00; Sun, 6 Aug 2000 00:22:44 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e767McE17843; Sun, 6 Aug 2000 09:22:39 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "Stephen Casner" , Cc: "Allison Mankin" , "Scott Bradner" Subject: Which RTP features are needed? (RE: Considering LIPE proposal in AVT working group) Date: Sun, 6 Aug 2000 09:22:20 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > The LIPE draft contends that this > scheme is too complex and that the services provided by RTP are not > needed for this application. See the draft for details. As another data point in this area, see draft-hiller-rohc-gehco-00.txt which argues that an RTP header compression scheme that preserves timestamps (possibly not bit-for-bit exact), but not necessarily sequence numbers, is "good enough". (For the present discussion about a/v transport protocols, it is probably not relevant that it also does not preserve UDP checksums and IP IDs. Also, I'm not interested in arguments about how it is bad when the network does something to your packets behind your back -- you may want to assume "consensual applications", here.) I would like to see some discussion starting on how important the RTP services are for "real-world applications". Timestamp and sequence number, CSRC list, RTCP reports, SDES info etc. While the members of this list may not be interested in the specific details of header compression schemes (if you are, please see www.dmn.tzi.org/ietf/rohc), they may very well be interested that specific RTP features make it through the network intact, even if bandwidth efficiency is of utmost importance. Please speak up... Gruesse, Carsten From rem-conf Sun Aug 06 05:39:04 2000 From rem-conf-request@es.net Sun Aug 06 05:39:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LPda-0005fp-00; Sun, 6 Aug 2000 05:34:42 -0700 Received: from newdev.eecs.harvard.edu (newdev.harvard.edu) [140.247.60.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LPdZ-0005ff-00; Sun, 6 Aug 2000 05:34:41 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA22455 for rem-conf@es.net; Sun, 6 Aug 2000 08:34:30 -0400 (EDT) Date: Sun, 6 Aug 2000 08:34:30 -0400 (EDT) From: Scott Bradner Message-Id: <200008061234.IAA22455@newdev.harvard.edu> To: rem-conf@es.net Subject: Re: Which RTP features are needed? (RE: Considering LIPE proposal ... X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > (For the present discussion about a/v transport protocols, it is probably > not relevant that it also does not preserve UDP checksums and IP IDs. note that it would be a bad idea to rely on IP IDs for anything since IPv6 IP packets do not have IDs (they are in the fragment header which is only used if the sender thinks that fragmentation is needed) Scott From rem-conf Sun Aug 06 10:52:19 2000 From rem-conf-request@es.net Sun Aug 06 10:52:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LUT2-0000jK-00; Sun, 6 Aug 2000 10:44:08 -0700 Received: from sj-msg-core-2.cisco.com [171.69.43.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LUT0-0000ii-00; Sun, 6 Aug 2000 10:44:06 -0700 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA16206; Sun, 6 Aug 2000 10:42:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19022; Sun, 6 Aug 2000 10:42:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14733.41873.487053.988683@thomasm-u1.cisco.com> Date: Sun, 6 Aug 2000 10:42:41 -0700 (PDT) To: "Dr. Carsten Bormann" Cc: "Stephen Casner" , , "Allison Mankin" , "Scott Bradner" Subject: Which RTP features are needed? (RE: Considering LIPE proposal in AVT working group) 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 Dr. Carsten Bormann writes: > > The LIPE draft contends that this > > scheme is too complex and that the services provided by RTP are not > > needed for this application. See the draft for details. > > As another data point in this area, see draft-hiller-rohc-gehco-00.txt which > argues that an RTP header compression scheme that preserves timestamps > (possibly not bit-for-bit exact), but not necessarily sequence numbers, is > "good enough". One consideration to be aware of is that there has been work to be able to use stream ciphers for RTP payload encryption. Stream ciphers need accuracy of the timestamp at the very least, and quite probably the sequence number in the general case (the initial work was only done for fixed length voice codecs and is not generalizable to variable rate video codecs in its present form). RTP compression and payload encryption go hand in glove, so a great deal of care needs to be taken to successfully marry the two . Mike From rem-conf Mon Aug 07 07:09:37 2000 From rem-conf-request@es.net Mon Aug 07 07:09:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LnQf-0004EY-00; Mon, 7 Aug 2000 06:58:57 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LnQe-0004EI-00; Mon, 7 Aug 2000 06:58: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 JAA28120; Mon, 7 Aug 2000 09:58:34 -0400 (EDT) Message-Id: <200008071358.JAA28120@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: Real-Time Transport Protocol Management Information Base to Proposed Standard Date: Mon, 07 Aug 2000 09:58:33 -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 'Real-Time Transport Protocol Management Information Base' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document defines MIB objects for managing Real-Time Transport Protocol (RTP) systems. The management includes both host end-systems running application programs that send or receive RTP data packets, and intermediate-systems that forward RTP packets. It also includes transmission and reception of RTP Control Protocol (RTCP). Working Group Summary The document has been revised as a result of input from the working group, in particular the addition of optional index tables for the primary tables to allow fast lookup of entries. There is good working group consensus for publishing the document. Protocol Quality Scott Bradner, Vern Paxson, and Bert Wijnen reviewed the spec for the IESG. From rem-conf Mon Aug 07 10:37:10 2000 From rem-conf-request@es.net Mon Aug 07 10:37:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LqmF-0007E9-00; Mon, 7 Aug 2000 10:33:27 -0700 Received: from adsl-gte-la-216-86-199-2.mminternet.com (alpha.zimage.com) [216.86.199.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LqmD-0007Dz-00; Mon, 7 Aug 2000 10:33:25 -0700 Received: (from root@localhost) by alpha.zimage.com (8.9.3/8.9.3) id KAA18129 for rem-conf@es.net; Mon, 7 Aug 2000 10:33:22 -0700 Date: Mon, 7 Aug 2000 10:33:22 -0700 From: rem-conf@zimage.com Message-Id: <200008071733.KAA18129@alpha.zimage.com> Reply-To: Jeff Gustafson Subject: Tunnel request To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I thought I'd put a request out just in case my upstream provider ignores me. :) Network hops are as follows: mminternet.net webvision.com lax.pnap.net ...Jeff From rem-conf Mon Aug 07 11:12:30 2000 From rem-conf-request@es.net Mon Aug 07 11:12:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LrM8-0000kI-00; Mon, 7 Aug 2000 11:10:32 -0700 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13LrM7-0000k8-00; Mon, 7 Aug 2000 11:10:32 -0700 Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA27847 for ; Mon, 7 Aug 2000 11:08:32 -0700 Message-Id: <3.0.5.32.20000807110834.0146b6b0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Aug 2000 11:08:34 -0700 To: rem-conf@es.net From: Jason Utz Subject: Call for RTP papers - iBAND at ISPCON 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 Greetings! RTP is one of the core technologies covered at the iBAND events. We would like to continue its progress at the upcoming iBAND at ISPCON Conference on November 8-10, 2000, in San Jose, CA. iBAND at ISPCON is a gathering place for key industry people to come together and learn about developments in the new Internet technologies: * Service Provisioning * Traffic Management * Performance Measurement * Your iBAND at ISPCON participation will help expose network engineers and other technology savvy professionals to the latest and greatest in RTP technology. =20 My name is Jason Utz, conference manager for iBAND at ISPCON Conference. Stardust.com's CTO Martin Hall and I would like to invite you to share you progress and ideas with other relevant professionals in one or more ways: =B7 Speaker Proposal * BOF Proposal * Showcase Participation * We value your expertise and look forward to receiving your speaker proposals to reflect the state of the art in RTP technology. Proposals are due no later than Friday, August 18, 2000. To find guidance and more information, please visit=20 http://www.stardust.com/iband5/speakers.htm http://www.stardust.com for network engineers offers additional opportunities to supply information and progress for RTP updates and technologies: - conference sessions available in MP3 format, - live interviews on Stardust.com TalkRadio, - provide white papers and have them maintained in a Stardust.com Web= library. All these options provide you with a large arena to deliver your working group's information and other updates. Please visit http://www.stardust.com to see what our site offers to its visitors. We want to help you drive this technology area forward so please let me know how you'd like to participate. Please contact me via email with any questions. Best regards, Jason Utz Conference Manager Stardust.com Jasonu@stardust.com www.stardust.com ***************** Stardust.com********************* Visit Stardust.com http://www.stardust.com Making sense of new Internet stuff Visit Stardust Talkradio Mondays in MP3 Format! *************************************************** Home of the IP Multicast Initiative (IPMI) the QoS Forum (QOSF) and the Wireless Multimedia Forum (WMF) NEW! *************************************************** UPCOMING EVENTS: *iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA *WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA ***************************************************** Jason Utz =20 Conference Manager 15575 Los Gatos Blvd Suite C Fax 408/402-0567 Los Gatos, CA 95032=20 From rem-conf Mon Aug 07 13:25:04 2000 From rem-conf-request@es.net Mon Aug 07 13:25:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LtNo-0002sy-00; Mon, 7 Aug 2000 13:20:24 -0700 Received: from (minnow.hhnetwk.com) [12.38.119.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LtNn-0002sH-00; Mon, 7 Aug 2000 13:20:24 -0700 Received: from harish.hhnetwk.com ([10.2.254.7]) by minnow.hhnetwk.com (8.8.5/8.8.5) with ESMTP id QAA26547 for ; Mon, 7 Aug 2000 16:19:26 -0400 Message-Id: <4.3.1.2.20000807161116.00ba2460@pop.mv.com> X-Sender: magellan-m1@pop.mv.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 07 Aug 2000 16:22:33 -0700 To: rem-conf@es.net From: Harish Manchaiah Subject: CRTP and QoS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I am new to this area, please pardon me if it is explained in some document I should have read properly. I am having trouble understanding the requirements for CRTP and QoS. CRTP is applied on link-by-link basis. Can multiple RTP/CRTP streams/flows come into a CRTP interface? I am assuming it is a valid scenario. If this is true, do we need to apply QoS to each of these flows? RFC1889 states that rtp doesn't guarantee QoS or in-order delivery. Has this been discussed before? Can someone provide some pointers to this please? thank you, -harish From rem-conf Mon Aug 07 13:55:18 2000 From rem-conf-request@es.net Mon Aug 07 13:55:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13LtpJ-00043O-00; Mon, 7 Aug 2000 13:48:49 -0700 Received: from omega.cisco.com [171.69.63.141] by mail1.es.net with esmtp (Exim 1.81 #2) id 13LtpI-000436-00; Mon, 7 Aug 2000 13:48:48 -0700 Received: from localhost (localhost [127.0.0.1]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA05883; Mon, 7 Aug 2000 13:47:15 -0700 (PDT) Date: Mon, 7 Aug 2000 13:47:15 -0700 (PDT) From: Dan Wing To: Harish Manchaiah cc: rem-conf@es.net Subject: Re: CRTP and QoS In-Reply-To: <4.3.1.2.20000807161116.00ba2460@pop.mv.com> Message-ID: <0008071344580.23999-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote: > Hello, > > I am new to this area, please pardon me if it is explained in some document > I should have read properly. > I am having trouble understanding the requirements for CRTP and QoS. > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP streams/flows > come into a CRTP interface? Yes, that's why CRTP has a context-ID. > I am assuming it is a valid scenario. If this is true, do we need to apply > QoS to each of these flows? Yep. > RFC1889 states that rtp doesn't guarantee QoS or in-order delivery. > Has this been discussed before? Can someone provide some pointers to > this please? IP doesn't guarantee in-order delivery, neither does UDP, neither does RTP. If in-order delivery is important, the application has to rebuild the packets in the correct order. With RTP, this reconstruction is done using the sequence number. -Dan Wing From rem-conf Mon Aug 07 21:12:56 2000 From rem-conf-request@es.net Mon Aug 07 21:12:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13M0gr-0000eN-00; Mon, 7 Aug 2000 21:08:33 -0700 Received: from dns1.transbay.net (transbay.net) [209.133.53.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13M0gp-0000eD-00; Mon, 7 Aug 2000 21:08:31 -0700 Received: from localhost (dwinet@localhost) by transbay.net (8.9.3/8.9.3) with ESMTP id VAA89304 for ; Mon, 7 Aug 2000 21:08:30 -0700 (PDT) Date: Mon, 7 Aug 2000 21:08:30 -0700 (PDT) From: David Winet X-Sender: dwinet@localhost To: rem-conf@es.net Subject: Please provide unsubscribe info -- I can't find it anywhere. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks. David Winet From rem-conf Mon Aug 07 23:31:03 2000 From rem-conf-request@es.net Mon Aug 07 23:31:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13M2tE-0002bI-00; Mon, 7 Aug 2000 23:29:28 -0700 Received: from samar.sasi.com.56.164.164.in-addr.arpa (sasi.com) [164.164.56.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13M2tA-0002b0-00; Mon, 7 Aug 2000 23:29:25 -0700 Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA02698; Tue, 8 Aug 2000 11:59:08 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by sasi.com; Tue, 08 Aug 2000 11:59:07 +0000 (IST) Received: from pcg140 (pcg140.sasi.com [10.0.64.140]) by sung17.sasi.com (8.9.3/8.9.3) with SMTP id LAA15254; Tue, 8 Aug 2000 11:59:03 +0530 (IST) Message-ID: <026f01c00101$6f2589a0$8c40000a@sasi.com> From: "rafi" To: "Dan Wing" , "Harish Manchaiah" Cc: References: <0008071344580.23999-100000@omega.cisco.com> Subject: Re: CRTP and QoS Date: Tue, 8 Aug 2000 11:55:23 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 If in order delivery is so important then we can run RTP over TCP though basic purpose might be defeated, but it all depends on what exactly the requirement is. Thanks Rafi Assadi H.M. ----- Original Message ----- From: Dan Wing To: Harish Manchaiah Cc: Sent: Tuesday, August 08, 2000 2:17 AM Subject: Re: CRTP and QoS > On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote: > > > Hello, > > > > I am new to this area, please pardon me if it is explained in some document > > I should have read properly. > > I am having trouble understanding the requirements for CRTP and QoS. > > > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP streams/flows > > come into a CRTP interface? > > Yes, that's why CRTP has a context-ID. > > > I am assuming it is a valid scenario. If this is true, do we need to apply > > QoS to each of these flows? > > Yep. > > > RFC1889 states that rtp doesn't guarantee QoS or in-order delivery. > > Has this been discussed before? Can someone provide some pointers to > > this please? > > IP doesn't guarantee in-order delivery, neither does UDP, neither does > RTP. If in-order delivery is important, the application has to rebuild > the packets in the correct order. With RTP, this reconstruction is done > using the sequence number. > > -Dan Wing > > From rem-conf Tue Aug 08 02:49:23 2000 From rem-conf-request@es.net Tue Aug 08 02:49:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13M5xg-0005KJ-00; Tue, 8 Aug 2000 02:46:16 -0700 Received: from (ns2.iiikorea.com) [210.113.46.2] by mail1.es.net with smtp (Exim 1.81 #2) id 13M5xc-0005Ji-00; Tue, 8 Aug 2000 02:46:15 -0700 Received: from cTYRPkN8H (unverified [216.214.106.189]) by www.iiikorea.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 08 Aug 2000 06:56:32 +0900 DATE: 07 Aug 00 2:50:55 PM FROM: zzxw@writeme.com Message-ID: <3CxZxx7Ue5CGMAm4> TO: nbgtjuy9877gr@es.net SUBJECT: we will fix your credit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GET YOUR CREDIT REPAIRED LEGALLY FOR $399 EVEN IF THE INFORMATION ON YOUR CREDIT REPORT IS ACCURATE!!!!! MONEY BACK GUARANTEED IF WE DON'T IMPROVE YOUR CREDIT. NATION WIDE CREDIT REPAIR AND DEBT SETTLEMENT is a prominent Beverly Hills company that repairs: repossessions, foreclosures, court judgments, collection accounts, bankruptcies, tax liens, charge offs, late payments, past due debts, loans, defaults, credit cards, credit rejections, credit inquiries, some unpaid bills and more. Our company uses prominent Beverly Hills attorneys that use a legal loophole found in the recent 1997 modification of the Federal Fair Credit Reporting Act designed to monitor the credit reporting agencies and to protect debtors' rights like yours. The Fair Credit Reporting Act allows us to have your credit cleared up even if the information on your credit report is accurate. If the credit reporting agency does not follow the proper procedure that includes approximately 320 legally required steps for reporting each bad credit ding, the law says the credit reporting agency must permanently delete that bad credit ding. Moreover, our company uses an efficient special software program to find out if the credit agency followed the 320 legally required steps for each of the bad credit dings on your report. This software enables us clear your credit report quickly, efficiently, and accurately. For more information and to sign up, call our 24-hour hot line at: 310-205-9211 Nation Wide Credit Repair and Debt Settlement 9663 Santa Monica Blvd. Suite #134 Beverly Hills, CA 90210-4303 From rem-conf Tue Aug 08 07:19:15 2000 From rem-conf-request@es.net Tue Aug 08 07:19:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MA26-0000l4-00; Tue, 8 Aug 2000 07:07:06 -0700 Received: from esebh12nok.ntc.nokia.com [131.228.10.109] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MA24-0000ks-00; Tue, 8 Aug 2000 07:07:04 -0700 Received: by esebh12nok.ntc.nokia.com with Internet Mail Service (5.5.2650.10) id ; Tue, 8 Aug 2000 17:06:57 +0300 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B798@daeis05nok> From: zhigang.liu@nokia.com To: rafi@sasi.com, dwing@cisco.com, harish@hhnetwk.com Cc: rem-conf@es.net Subject: RE: CRTP and QoS Date: Tue, 8 Aug 2000 17:03:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It's not a good idea due to the delay associated with TCP (remember, RTP is Real-time Transport Protocol). As Dan Wing stated, RTP sequence number is good and sufficient for that purpose. Br, Zhigang > -----Original Message----- > From: EXT rafi [mailto:rafi@sasi.com] > Sent: Tuesday, August 08, 2000 1:25 AM > To: Dan Wing; Harish Manchaiah > Cc: rem-conf@es.net > Subject: Re: CRTP and QoS > > > If in order delivery is so important then > we can run RTP over TCP though > basic purpose might be defeated, but > it all depends on what exactly the requirement > is. > > Thanks > Rafi Assadi H.M. > > > ----- Original Message ----- > From: Dan Wing > To: Harish Manchaiah > Cc: > Sent: Tuesday, August 08, 2000 2:17 AM > Subject: Re: CRTP and QoS > > > > On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote: > > > > > Hello, > > > > > > I am new to this area, please pardon me if it is explained in some > document > > > I should have read properly. > > > I am having trouble understanding the requirements for > CRTP and QoS. > > > > > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP > streams/flows > > > come into a CRTP interface? > > > > Yes, that's why CRTP has a context-ID. > > > > > I am assuming it is a valid scenario. If this is true, do > we need to > apply > > > QoS to each of these flows? > > > > Yep. > > > > > RFC1889 states that rtp doesn't guarantee QoS or in-order > delivery. > > > Has this been discussed before? Can someone provide some > pointers to > > > this please? > > > > IP doesn't guarantee in-order delivery, neither does UDP, > neither does > > RTP. If in-order delivery is important, the application > has to rebuild > > the packets in the correct order. With RTP, this > reconstruction is done > > using the sequence number. > > > > -Dan Wing > > > > > > From rem-conf Tue Aug 08 07:21:09 2000 From rem-conf-request@es.net Tue Aug 08 07:21:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MACU-0000so-00; Tue, 8 Aug 2000 07:17:50 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MACS-0000se-00; Tue, 8 Aug 2000 07:17:49 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03121; Tue, 8 Aug 2000 10:17:45 -0400 (EDT) Message-Id: <200008081417.KAA03121@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-mp3-03.txt Date: Tue, 08 Aug 2000 10:17: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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rtp-mp3-03.txt Pages : Date : 07-Aug-00 While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable 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. In this document we define 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-03.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-mp3-03.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-mp3-03.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: <20000807142056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mp3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mp3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000807142056.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Aug 08 07:40:07 2000 From rem-conf-request@es.net Tue Aug 08 07:40:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MAWn-0002fY-00; Tue, 8 Aug 2000 07:38:49 -0700 Received: from (minnow.hhnetwk.com) [12.38.119.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MAWm-0002fE-00; Tue, 8 Aug 2000 07:38:48 -0700 Received: from harish.hhnetwk.com ([10.2.254.7]) by minnow.hhnetwk.com (8.8.5/8.8.5) with ESMTP id KAA21447 for ; Tue, 8 Aug 2000 10:37:51 -0400 Message-Id: <4.3.1.2.20000808102536.00ba3100@pop.mv.com> X-Sender: magellan-m1@pop.mv.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 08 Aug 2000 10:40:56 -0700 To: rem-conf@es.net From: Harish Manchaiah Subject: RE: CRTP and QoS In-Reply-To: <8572CF1E2A95D211A1190008C7EAA2460213B798@daeis05nok> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks for the responses. I agree that RTP is responsible for reconstructing the frame using rtp sequence numbers. But if CRTP streams with different QoS are passing through a bundle (ex: MLPPP), then MLPPP implementation should absolutely make sure of sending the packets out in the order it received. Otherwise, with current error recovery mechanism of crtp, you see more context invalidation message than you wanted which defeats the purpose of real-time transport. Does network operators generally carry crtp streams over a multilink bundle? thanks, -harish At 05:03 PM 8/8/00 +0300, zhigang.liu@nokia.com wrote: >It's not a good idea due to the delay associated >with TCP (remember, RTP is Real-time Transport >Protocol). As Dan Wing stated, RTP sequence number >is good and sufficient for that purpose. > >Br, >Zhigang > > > -----Original Message----- > > From: EXT rafi [mailto:rafi@sasi.com] > > Sent: Tuesday, August 08, 2000 1:25 AM > > To: Dan Wing; Harish Manchaiah > > Cc: rem-conf@es.net > > Subject: Re: CRTP and QoS > > > > > > If in order delivery is so important then > > we can run RTP over TCP though > > basic purpose might be defeated, but > > it all depends on what exactly the requirement > > is. > > > > Thanks > > Rafi Assadi H.M. > > > > > > ----- Original Message ----- > > From: Dan Wing > > To: Harish Manchaiah > > Cc: > > Sent: Tuesday, August 08, 2000 2:17 AM > > Subject: Re: CRTP and QoS > > > > > > > On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote: > > > > > > > Hello, > > > > > > > > I am new to this area, please pardon me if it is explained in some > > document > > > > I should have read properly. > > > > I am having trouble understanding the requirements for > > CRTP and QoS. > > > > > > > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP > > streams/flows > > > > come into a CRTP interface? > > > > > > Yes, that's why CRTP has a context-ID. > > > > > > > I am assuming it is a valid scenario. If this is true, do > > we need to > > apply > > > > QoS to each of these flows? > > > > > > Yep. > > > > > > > RFC1889 states that rtp doesn't guarantee QoS or in-order > > delivery. > > > > Has this been discussed before? Can someone provide some > > pointers to > > > > this please? > > > > > > IP doesn't guarantee in-order delivery, neither does UDP, > > neither does > > > RTP. If in-order delivery is important, the application > > has to rebuild > > > the packets in the correct order. With RTP, this > > reconstruction is done > > > using the sequence number. > > > > > > -Dan Wing > > > > > > > > > > From rem-conf Tue Aug 08 09:23:12 2000 From rem-conf-request@es.net Tue Aug 08 09:23:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MC4a-0004Pd-00; Tue, 8 Aug 2000 09:17:48 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MC4Y-0004PT-00; Tue, 8 Aug 2000 09:17:47 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e78GHeE00676; Tue, 8 Aug 2000 18:17:40 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "Harish Manchaiah" , Subject: RE: CRTP and QoS Date: Tue, 8 Aug 2000 18:17:40 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <4.3.1.2.20000808102536.00ba3100@pop.mv.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > But if CRTP streams with different QoS are passing through a bundle (ex: > MLPPP), then MLPPP implementation should > absolutely make sure of sending the packets out in the order it received. The point of the sequence number in Multi-Link PPP (RFC1990) is to make sure the receiver can reconstitute the order of packets even when the individual links have different delays (and, possibly, queueing characteristics). > Otherwise, with current error recovery mechanism > of crtp, you see more context invalidation message than you wanted which > defeats the purpose of real-time transport. CRTP, like the PPP suite itself, assumes that there is no reordering on the link layer -- as it is part of the IPCP NCP and thus on top of multi-link, this is then a requirement on the way multi-link operates. Schemes such as multi-class multi-link (RFC2686/2687) require that the sender is very careful to not put information into different classes (independent sequence number spaces) that would violate these assumptions. Unfortunately, I'm not aware that anyone has documented in detail what kinds of reordering are "safe" and which ones are not. Gruesse, Carsten From rem-conf Tue Aug 08 12:54:18 2000 From rem-conf-request@es.net Tue Aug 08 12:54:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MFNJ-0006sC-00; Tue, 8 Aug 2000 12:49:21 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MFNE-0006rs-00; Tue, 8 Aug 2000 12:49:19 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA16796 for ; Tue, 8 Aug 2000 15:48:59 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA05740 for ; Wed, 9 Aug 2000 00:48:34 +0500 Message-Id: <200008081948.AAA05740@hafez.east.isi.edu> o: David Winet cc: rem-conf@es.net Subject: Re: Please provide unsubscribe info -- I can't find it anywhere. In-Reply-To: Your message of "Mon, 07 Aug 2000 21:08:30 PDT." Date: Tue, 08 Aug 2000 15:48:34 -0400 From: Colin Perkins To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> David Winet writes: >Thanks. >David Winet Send mail to rem-conf-request@es.net with the word "unsubscribe" in the body. Colin From rem-conf Tue Aug 08 13:24:45 2000 From rem-conf-request@es.net Tue Aug 08 13:24:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MFqo-00005h-00; Tue, 8 Aug 2000 13:19:50 -0700 Received: from adsl-gte-la-216-86-199-2.mminternet.com (alpha.zimage.com) [216.86.199.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MFqn-00005X-00; Tue, 8 Aug 2000 13:19:49 -0700 Received: (from root@localhost) by alpha.zimage.com (8.9.3/8.9.3) id NAA29772 for rem-conf@es.net; Tue, 8 Aug 2000 13:19:46 -0700 Date: Tue, 8 Aug 2000 13:19:46 -0700 From: rem-conf@zimage.com Message-Id: <200008082019.NAA29772@alpha.zimage.com> Reply-To: Jeff Gustafson Subject: Tunnel request update... no luck To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My upstream provider said no for them providing the service. So I'm looking for anyone else out there to graciously provide me with a tunnel. Here again is my traceroute out: mminternet.net webvision.com lax.pnap.net ...Jeff From rem-conf Tue Aug 08 15:00:04 2000 From rem-conf-request@es.net Tue Aug 08 15:00:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MHNf-0001qM-00; Tue, 8 Aug 2000 14:57:51 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MHNd-0001qC-00; Tue, 8 Aug 2000 14:57:50 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA18172 for ; Tue, 8 Aug 2000 17:58:12 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA07070 for ; Wed, 9 Aug 2000 02:57:47 +0500 Message-Id: <200008082157.CAA07070@hafez.east.isi.edu> To: rem-conf@es.net Subject: Slides from Pittsburgh AVT meeting Date: Tue, 08 Aug 2000 17:57:47 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, The majority of the presentation slides from the Pittsburgh AVT meeting are now online at http://www.east.isi.edu/DIV7/IETF/AVT/ Those who haven't yet sent me their slides, please do so. Thanks, Colin From rem-conf Wed Aug 09 15:55:55 2000 From rem-conf-request@es.net Wed Aug 09 15:55:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MeaB-00058b-00; Wed, 9 Aug 2000 15:44:19 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Mea9-00057K-00; Wed, 9 Aug 2000 15:44:17 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id SAA00353; Wed, 9 Aug 2000 18:44:27 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id DAA20837; Thu, 10 Aug 2000 03:43:58 +0500 Message-Id: <200008092243.DAA20837@hafez.east.isi.edu> To: rem-conf@es.net Subject: RTP interoperability statement cc: orit@radvision.com Date: Wed, 09 Aug 2000 18:43:58 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I've just submitted revised versions of the interoperability statements for the RTP spec and profile. The main change since the last version is that the test results are included within the drafts, rather than being on a separate webpage. These also reflect the discussion we had over dinner in Pittsburgh, and I think capture who volunteered to test what :-) The main area where we need input from the group is with the testing of the codecs. In particular, we are seeking implementations of 1016, G.726-32, G.723, PCMA, G.722, QCELP, G.728, G.729, GSM-HF, GSM-EFR, L8, CelB, JPEG, nv, MP2T, H.263, MP1S, MP2P, and BMPEG. If you have such an implementation please contact me or the list. Thanks, Colin From rem-conf Wed Aug 09 18:30:26 2000 From rem-conf-request@es.net Wed Aug 09 18:30:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Mh6V-00073X-00; Wed, 9 Aug 2000 18:25:51 -0700 Received: from (ns.koexhibit.co.kr) [211.39.199.2] by mail1.es.net with smtp (Exim 1.81 #2) id 13Mh6T-00073N-00; Wed, 9 Aug 2000 18:25:49 -0700 Received: from A72i0VkC4 (216.214.106.252) by ns.koexhibit.co.kr (EMWAC SMTPRS 0.81) with SMTP id ; Wed, 09 Aug 2000 17:33:25 +0900 DATE: 09 Aug 00 1:33:04 AM FROM: goodcredit124@email.com Message-ID: <14zth1l7NDEY0bveQrj2Ox54O> TO: kjyhjuoi889079hjihjkhkjhjh@es.net SUBJECT: We will delete your bad credit even if it accurate X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GET YOUR CREDIT REPAIRED LEGALLY FOR $399 EVEN IF THE INFORMATION ON YOUR CREDIT REPORT IS ACCURATE!!!!! MONEY BACK GUARANTEED IF WE DON'T IMPROVE YOUR CREDIT! WE HAVE A 95% SUCCESS RATE! NATION WIDE CREDIT REPAIR AND DEBT SETTLEMENT is a prominent Beverly Hills company that repairs: repossessions, foreclosures, court judgments, collection accounts, bankruptcies, tax liens, charge offs, late payments, past due debts, loans, defaults, credit cards, credit rejections, credit inquiries, some unpaid bills and more. Our company uses prominent Beverly Hills attorneys that use a legal loophole found in the recent 1997 modification of the Federal Fair Credit Reporting Act designed to monitor the credit reporting agencies (Experian / TRW, Transunion, and Equifax) and to protect debtors' rights like yours. The Fair Credit Reporting Act allows us to have your credit cleared up even if the information on your credit report is accurate. If the credit reporting agency does not follow the proper procedure that includes approximately 320 legally required steps for reporting each bad credit ding, the law says the credit reporting agency must permanently delete that bad credit ding. Moreover, our company uses an efficient special software program to find out if the credit agency followed the 320 legally required steps for each of the bad credit dings on your report. This software enables us clear your credit report quickly, efficiently, and accurately. Once we have run our program that finds out where the credit reporting agency has made a mistake, we use our Beverly Hills attorneys to put the legal pressure on the credit reporting agencies to enforce the Federal Fair Credit Reporting Act. For more information and to sign up, call our 24-HOUR HOT LINE AT: 310- 205- 9211 If you have detailed questions we will be happy to put you in touch with one of our attorneys that we use to explain the process to you over the phone or you can write us at: Nation Wide Credit Repair and Debt Settlement 9663 Santa Monica Blvd., Suite #134 Beverly Hills, CA 90210-4303 If you would like to be removed , please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From rem-conf Wed Aug 09 21:32:09 2000 From rem-conf-request@es.net Wed Aug 09 21:32:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Mjy2-0001SR-00; Wed, 9 Aug 2000 21:29:18 -0700 Received: from rly-ip01.mx.aol.com [205.188.156.49] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Mjy0-0001Qi-00; Wed, 9 Aug 2000 21:29:16 -0700 Received: from tot-wc.proxy.aol.com (tot-wc.proxy.aol.com [205.188.193.1]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id AAA14698; Thu, 10 Aug 2000 00:27:58 -0400 (EDT) Received: from sknetworks.com (AC8031D9.ipt.aol.com [172.128.49.217]) by tot-wc.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e7A4RvL09449; Thu, 10 Aug 2000 00:27:57 -0400 (EDT) Message-ID: <39922F11.5372C43B@sknetworks.com> Date: Wed, 09 Aug 2000 21:26:57 -0700 From: Scott Keagy X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Harish Manchaiah CC: rem-conf@es.net Subject: Re: CRTP and QoS References: <4.3.1.2.20000808102536.00ba3100@pop.mv.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Sonikaul@aol.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yes, it is common to use CRTP together with MLPPP on Cisco routers in two applications: 1) Passing CRTP (i.e. VoIP) across load-sharing links with ML-PPP. This is most often used for ISDN circuits (such as bonded B-channels in an ISDN BRI or PRI circuit, or even among multiple BRI or PRI circuits) or dial-up async modem circuits. It is also sometimes used to inverse multiplex T-1/E-1 connections. 2) Using ML-PPP to support "link fragmentation and interleaving" on a low speed serial link (to minimize serialization delay). Note that this application is Cisco's twist on ML-PPP, but it is very important and useful to improve QoS across low speed serial links that use PPP. -Scott Harish Manchaiah wrote: > Thanks for the responses. I agree that RTP is responsible for > reconstructing the frame using rtp sequence numbers. > But if CRTP streams with different QoS are passing through a bundle (ex: > MLPPP), then MLPPP implementation should > absolutely make sure of sending the packets out in the order it received. > Otherwise, with current error recovery mechanism > of crtp, you see more context invalidation message than you wanted which > defeats the purpose of real-time transport. > > Does network operators generally carry crtp streams over a multilink bundle? > > thanks, > -harish > > At 05:03 PM 8/8/00 +0300, zhigang.liu@nokia.com wrote: > >It's not a good idea due to the delay associated > >with TCP (remember, RTP is Real-time Transport > >Protocol). As Dan Wing stated, RTP sequence number > >is good and sufficient for that purpose. > > > >Br, > >Zhigang > > > > > -----Original Message----- > > > From: EXT rafi [mailto:rafi@sasi.com] > > > Sent: Tuesday, August 08, 2000 1:25 AM > > > To: Dan Wing; Harish Manchaiah > > > Cc: rem-conf@es.net > > > Subject: Re: CRTP and QoS > > > > > > > > > If in order delivery is so important then > > > we can run RTP over TCP though > > > basic purpose might be defeated, but > > > it all depends on what exactly the requirement > > > is. > > > > > > Thanks > > > Rafi Assadi H.M. > > > > > > > > > ----- Original Message ----- > > > From: Dan Wing > > > To: Harish Manchaiah > > > Cc: > > > Sent: Tuesday, August 08, 2000 2:17 AM > > > Subject: Re: CRTP and QoS > > > > > > > > > > On Mon, 7 Aug 2000 16:22 -0700, Harish Manchaiah wrote: > > > > > > > > > Hello, > > > > > > > > > > I am new to this area, please pardon me if it is explained in some > > > document > > > > > I should have read properly. > > > > > I am having trouble understanding the requirements for > > > CRTP and QoS. > > > > > > > > > > CRTP is applied on link-by-link basis. Can multiple RTP/CRTP > > > streams/flows > > > > > come into a CRTP interface? > > > > > > > > Yes, that's why CRTP has a context-ID. > > > > > > > > > I am assuming it is a valid scenario. If this is true, do > > > we need to > > > apply > > > > > QoS to each of these flows? > > > > > > > > Yep. > > > > > > > > > RFC1889 states that rtp doesn't guarantee QoS or in-order > > > delivery. > > > > > Has this been discussed before? Can someone provide some > > > pointers to > > > > > this please? > > > > > > > > IP doesn't guarantee in-order delivery, neither does UDP, > > > neither does > > > > RTP. If in-order delivery is important, the application > > > has to rebuild > > > > the packets in the correct order. With RTP, this > > > reconstruction is done > > > > using the sequence number. > > > > > > > > -Dan Wing > > > > > > > > > > > > > > -- Scott Keagy, CCIE# 3985 Senior Networking Consultant SK Networks, Inc. tel: +1 408 439 8541 mailto:scott@sknetworks.com http://www.sknetworks.com From rem-conf Thu Aug 10 00:20:42 2000 From rem-conf-request@es.net Thu Aug 10 00:20:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MmYt-0003ZR-00; Thu, 10 Aug 2000 00:15:31 -0700 Received: from gorilla.mchh.siemens.de [194.138.158.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MmYq-0003ZH-00; Thu, 10 Aug 2000 00:15:28 -0700 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA17416 for ; Thu, 10 Aug 2000 09:14:58 +0200 (MET DST) From: Frank.Burkert@mch.siemens.de Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.204.219]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA26878 for ; Thu, 10 Aug 2000 09:12:12 +0200 (MET DST) Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 09:15:59 +0200 Message-ID: <8C8712EF8143D311A67B00508B0FD51901053535@mchg9eda.mchh.siemens.de> To: rem-conf@es.net Subject: draft-lnt-avt-uxp-00.txt Date: Thu, 10 Aug 2000 09:16:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0029A.D9303C10" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0029A.D9303C10 Content-Type: text/plain Dear experts, please find attched to this email our proposal for "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams" (draft-lnt-avt-uxp-00.txt) that has been presented at the 48th IETF Meeting last week. Any comments are highly appreciated, Frank <> > -------------------------------------------------------------------------- > -- > Frank Burkert SIEMENS AG > ICM CD MP RD MC 81 Information and > Communication Mobile > > > phone: +49-89-722-54344 Haidenau Platz 1 > mobile: +49-175-262-1175 81675 Muenchen > fax: +49-89-722-46489 Germany > E-Mail: Frank.Burkert@Mch.Siemens.DE > http://www.siemens.de/ic/mobile > -------------------------------------------------------------------------- > -- > > ------_=_NextPart_000_01C0029A.D9303C10 Content-Type: text/plain; name="draft-lnt-avt-uxp-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-lnt-avt-uxp-00.txt" Internet Engineering Task Force M. Nguyen, G. Liebl Internet Draft LNT, Munich Univ. of Technology Document: draft-lnt-avt-uxp-00.txt July 2000 B. Wimmer, F. Burkert, J.Pandel Expires: January 2001 Siemens AG, Munich An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon codes. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By defining a comparably simple payload format, the proposed scheme can be easily integrated into the existing framework for RTP. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page1] =0C Internet Draft Unequal Erasure Protection July 2000 2. Conventions used in this document The following terms are used throughout this document: 1.) Message block: a higher layer transport unit (e.g. an IP packet), that enters/leaves the segmentation/reassembly stage at the interface to wireless data link layers. 2.) Segment: denotes a link layer transport unit. 3.) CRC: Cyclic Redundancy Check, usually added to transport units at the sender to detect the existence of erroneous bits in a transport unit at the receiver. 4.) Segmentation/Reassembly Process: If the size of the transport units at the link layer is smaller than that at the upper layers, message blocks have to be split up into several parts, i.e. segments, which are then transmitted subsequently over the link. If nothing is lost, the original message block can be restored at the receiving entity (reassembly). 5.) Quality-of-service: application-dependent criterion to define a certain desired operation point. 6.) Codec: denotes a functional pair consisting of a source encoding unit at the sender and a corresponding source decoding unit at the receiver; usually standardized for different multimedia applications like audio or video. 7.) Progressive source coding: results in a stream of coded data whose distinct elements are of different importance to the reconstruction process at the decoder. Elements are commonly ordered from highest to least importance, where the latter elements depend on the previous. 8.) Reed-Solomon (RS) code: belongs to the class of linear nonbinary block codes, and is uniquely specified by the block length n, the number of parity symbols t, and the symbol alphabet. 9.) n: is a variable, which denotes both the block length of a RS codeword, and the number of columns in a TB (see 15). 10.) k: is a variable, which denotes the number of information symbols in a RS codeword. 11.) t: is a variable, which denotes the number of parity symbols in a RS codeword. 12.) Erasure: When a packet is lost during transmission, an erasure is said to have happened. Since the position of the erased packet in a sequence is usually known, a corresponding erasure marker can be set at the receiving entity. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 2] =0C Internet Draft Unequal Erasure Protection July 2000 13.) Base layer: comprises the first and most important elements in a progressively encoded bitstream, without which all subsequent information is useless. 14.) Enhancement layer: comprises one or more sets of the less important subsequent elements in a progressively encoded bitstream. A specific enhancement layer can be decoded, if and only if the base layer and all previous enhancement layer data (of higher importance) is available. 15.) Transmission block (TB): denotes a memory array of L rows and n columns. Each row of a TB represents a RS codeword, whereas each column represents the payload of an RTP packet. 16.) L: is a variable, which denotes both the number of rows in a TB and the payload length of an RTP packet in bytes. 17.) Unequal erasure protection (UXP): denotes a specific strategy which varies the level of erasure protection across a TB according to a given redundancy profile. 18.) Equal erasure protection (EXP): is a subset of UXP, for which the level of erasure protection is kept constant across a TB. 19.) Redundancy profile: describes the size of the different erasure protection classes in a TB, i.e. the number of rows (codewords) per class. 20.) Erasure protection class: contains a set of rows (codewords) of the TB with same erasure correction capability. 21.) i: is a variable, which denotes the number of parity bytes for each row in erasure protection class i. 22.) CA_i: is a variable, which denotes the set of rows contained in erasure protection class i. 23.) A_i: is a variable, which denotes the total number of rows contained in erasure protection class i, i.e. the cardinality of CA_i. 24.) T: is a variable, which denotes the number of parity bytes for each row in the highest erasure protection class (with respect to application data) in a TB. 25.) AV: denotes the erasure protection vector of length (T+1) used to describe a certain redundancy profile. 26.) Stuffing: insertion of predefined symbol patterns. Stuffing is performed, if the information part of an erasure protection class cannot be filled completely with (application) payload data. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 3] =0C Internet Draft Unequal Erasure Protection July 2000 27.) Interleaver: performs the spreading of a codeword, i.e. a row in the TB, over n successive packets, such that the probability of an erasure burst in a codeword is kept small. 28.) UXP header: is the additional header information contained in each RTP packet after UXP has been applied. 29.) X: denotes a currently not used extension field of 1 bit in the UXP header. 30.) P: is a variable which denotes the number of parity symbols per row used to protect the inband signaling of the redundancy profile. 31.) ceil(.): denotes the ceiling function, i.e. rounding up to the next integer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction Due to the increasing popularity of high-quality multimedia applications over the Internet and the high level of public acceptance of existing mobile communication systems, there is a strong demand for a future combination of these two techniques: One possible scenario consists of an integrated communication environment, where users can set up multimedia connections anytime and anywhere via radio access links to the Internet. For this reason, several packet-oriented transmission modes have been proposed for next generation wireless standards like EGPRS (Enhanced General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System), which are mostly based on the same principle: Long message blocks, i.e. IP packets, that enter the wireless part of the network are split up into segments of desired length, which can be multiplexed onto link layer packets of fixed size. The latter are then transmitted sequentially over the wireless link, reassembled, and passed on to the next network element. However, compared to the rather benign channel characteristics on today's fixed networks, wireless links suffer from severe fading, noise, and interference conditions in general, thus resulting in a comparably high residual bit error rate after detection and decoding. By use of efficient CRC-mechanisms, these bit errors are usually detected with very high probability, and every corrupted segment, i.e. which contains at least one erroneous bit, is discarded to prevent error propagation through the network. But if only one single segment is missing at the reassembly stage, the upper layer IP packet cannot be reconstructed anymore. The result is a significant increase in packet loss rate at IP level. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 4] =0C Internet Draft Unequal Erasure Protection July 2000 Since most multimedia applications can only recover from a very limited number of lost message blocks, it is vitally necessary to keep packet loss at IP level within a certain acceptable range depending on the individual quality-of-service requirements. However, due to the delay constraints typically imposed by most audio or video codecs, the use of ARQ-schemes is often prohibited both at link level and at transport level. In addition, retransmission strategies cannot be applied to any broadcast or multicast scenarios. Thus, forward erasure correction strategies have to be considered, which provide a simple means to reconstruct the content of lost packets at the receiver from the redundancy that has been spread out over a certain number of subsequent packets. There already exist some previous studies and proposals regarding erasure-resilient packet transmission, of whom the most important one with respect to RTP is described in [1]. Since most of them are based on the assumption that all parts in a message block are equally important to the receiver, i.e. the respective application cannot operate on partly complete blocks, they were optimized with respect to assigning equal erasure protection over the whole message block. However, recent developments both in audio and video coding have introduced the notion of progressively encoded source streams, for which unequal erasure protection strategies seem to be more promising, as it will be explained in more detail below. Although the scheme defined in [1] is in principle capable of supporting some kind of unequal erasure protection, possible implementations seem to be quite complex with respect to the gain in performance. Finally, in [1] it is assumed that subsequent RTP packets can have variable length, which would cause significant segmentation overhead at the link layer of almost all wireless systems. This document defines a payload format for RTP, such that different elements in a progressively encoded multimedia stream can be protected against packet erasures according to their respective quality-of-service requirement. The general principle, including the use of Reed-Solomon codes together with an appropriate interleaving scheme for adding redundancy, follows the ideas already presented in [2], but allows for finer granularity in the structure of the progressive source stream. The proposed scheme is generic in the way that it (1) is independent of the type of multimedia stream, be it audio or video, and (2) can be adapted to varying transmission quality very quickly by use of inband-signaling. 4. Reed-Solomon Codes Reed-Solomon (RS) codes are a special class of linear nonbinary block codes, which are known to offer maximum erasure correction capability with minimum amount of redundancy. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 5] =0C Internet Draft Unequal Erasure Protection July 2000 An arbitrary t-erasure-correcting (n,k) RS code defined over Galois field GF(q) has the following parameters [3]: - Block length: n=3Dq-1 - No. of information symbols in a codeword: k - No. of parity-check symbols in a codeword: n-k=3Dt - Minimum distance: d=3Dt+1 In what follows, only systematic RS codes over GF(2^8) shall be considered, i.e. the symbols of interest can be directly related to a tuple of eight bits, which is commonly called a byte in packet transmission. The principle structure of a codeword is shown in Fig. 1. By shortening the initial (n=3D255,n-t) RS code, any desired = (n',n'-t) RS code for a given erasure correction capability t may be obtained. block of n bytes <-----------------> +-+-+-+-+-+-+-+-+-+ |&|&|&|&|&|&|&|*|*| +-+-+-+-+-+-+-+-+-+ <------------><---> k=3Dn-t t (&:info) (*:parity) Fig. 1: Structure of a systematic RS codeword 5. Progressive Source Coding If the output of a multimedia codec, be it audio or video, is said to be progressive, the encoded bitstream must consist of several distinct elements, often organized in separate layers. The latter shall be defined via their relative importance with respect to the quality of the reconstruction process at the receiver. Hence, there exists at least one layer, often called base layer, without which reconstruction fails at all, whereas all the other layers, often called enhancement layers, just help to continually improve the quality. Consequently, the different layers shall be mapped on the bitstream in decreasing order of importance, i.e. the base layer data is followed by the various enhancement layers. An example can be found in the fine granular scalability modes which have been proposed to various standardization bodies like MPEG-4 [4] or ITU (H.26L) [5], where the resolution of the scaling process in the progressive source encoder is as low as one symbol in the enhancement layer. From the above definition, it is quite obvious that the most important base layer data must be protected as strongly as possible against packet loss during transmission. However, the protection of the enhancement layers could be continually lowered, since a loss at this stage has only minor consequences for the reconstruction Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 6] =0C Internet Draft Unequal Erasure Protection July 2000 process. Thus, by using a suitable unequal erasure protection strategy across the message block, which contains the progressively encoded source stream, the overhead due to redundancy spent per block is reduced. Furthermore, if channel conditions get worse during transmission, only more and more enhancement layers are lost, i.e. a graceful degradation in application quality at the receiver is achieved [6]. 6. General Structure of UXP schemes Fig. 1 already illustrated the structure of a systematic codeword, which shall be represented by a single row and n successive columns that contain the information and the parity bytes. This structure shall now be extended by forming a transmission block (TB) consisting of L codewords of length n bytes each, which amounts to a total of L rows and n columns [7]: Each column shall represent the payload of an RTP packet, i.e. the whole data of a TB is transmitted via a sequence of n RTP packets all carrying a payload of length L bytes. The value of L should be chosen in such a way that the whole length of the resulting IP packet (i.e. RTP payload plus sum of UXP, RTP, UDP, and IP header) equals a multiple of the segment size on the wireless link to avoid stuffing at the data link layer. As depicted in Fig. 2, the rows of the block shall be partitioned into T+1 different classes CA_i, where i=3D0...T, such that each = class contains exactly A_i=3D|CA_i| consecutive rows of the matrix, where the A_i have to satisfy the following relationship: A_0+A_1+...+A_T=3DL Transmission Block (TB) T <-------> /\ +-+-+-+-+-+-+-+-+-+ /\ | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | A_T=3D3 | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | L bytes | |&|&|&|&|&|*|*|*|*| \/ payload | +-+-+-+-+-+-+-+-+-+ /\ per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |$|$|$|$|$|$|$|*|*| . | +-+-+-+-+-+-+-+-+-+ . | |=A7|=A7|=A7|=A7|=A7|=A7|=A7|=A7|*| . | +-+-+-+-+-+-+-+-+-+ /\ | |#|#|#|#|#|#|#|#|#| | A_0=3D1 \/ +-+-+-+-+-+-+-+-+-+ \/ <-----------------> n packets Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 7] =0C Internet Draft Unequal Erasure Protection July 2000 &,%,$,=A7,# : info bytes belonging to a certain source coding layer = in decreasing order of importance * : parity bytes gained from Reed-Solomon coding Fig. 2: General structure for coding with unequal erasure protection Furthermore, all rows in a particular class CA_i shall contain exactly the same number of parity bytes, which is equal to the index i of the class. For each row in a certain class CA_i, the same (n,n- i) RS code shall be applied. As can be observed from Fig. 2, class CA_T contains the largest number of parity bytes per row, i.e. offers the highest erasure protection capability in the block. Consequently, all base layer data must be assigned to class CA_T, where the value of T should be chosen according to the desired outage threshold of the base layer given a certain packet erasure rate on the link. All other classes CA_(T-1)...CA_0 shall be sequentially filled with enhancement layer data in decreasing order of importance, where the optimal choice for the size of each class (0 or more rows), i.e. the structure of the redundancy profile, should depend on the quality- of-service requirements for the various layers. The following set of rules contains a compact description of all the operations that must be performed for each transmission block: 1.) The total number of columns n of the TB shall be chosen according to the actual delay constraints of the application. 2.) The maximum erasure correction capability T should be chosen according to the desired outage threshold of the base layer given the actual packet erasure rate on the link. 3.) The redundancy profile for the rest of the TB should depend on the size and number of the various layers in the progressive source stream, as well as the desired probability of successful decoding for each of them (quality-of-service requirement). 4.) Beginning with the base layer, each layer in the progressive source stream shall be assigned to exactly one class CA_T...CA_0 in decreasing order of importance. 5.) For each nonempty class CA_i, i=3DT...0, the following steps = have to be performed: a) All rows of this specific class shall be filled from left to right and top to bottom with data bytes of the corresponding layer. If the size of the layer is less than the available space for this class, the empty positions may be filled with the first bytes of the next layer (in decreasing order of importance), such that there is no overhead due to stuffing. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 8] =0C Internet Draft Unequal Erasure Protection July 2000 b) For each row in the class, the required i parity-check bytes are computed from the same set of codewords of an (n,n-i) RS code, and filled in the empty positions at the end of each row. Thus, every row in the class constitutes a valid codeword of the chosen RS code. 6.) If the total length of the progressively encoded source stream exceeds the number of available info byte positions in the TB for the chosen redundancy profile, the final bytes of the least important enhancement layer shall be cut off until the remaining parts fit completely into the TB. 7.) If the total length of the progressively encoded source stream is less than the number of available info byte positions in the TB for the chosen redundancy profile, byte-stuffing shall be applied to the empty positions in the last class such that the stuffing value does not influence the performance of the multimedia decoder at the receiver. 8.) After having filled the whole TB with information and parity bytes, each column is read out byte-wise from top to bottom and mapped onto the payload part of one and only one RTP packet. 9.) The n resulting RTP packets shall be transmitted subsequently to the remote host, starting with the leftmost one. 10.) At the corresponding protocol entity at the remote host, the payload of all successfully received RTP packets belonging to the same sending TB shall be filled into a similar receiving TB column- wise from top to bottom and left to right. 11.) For every erased packet of a received TB, the respective column in the TB shall be filled with a suitable erasure marker. 12.) Given the redundancy profile assigned by the sender, for each row a decoding operation shall be performed by applying any suitable algorithm for erasure decoding. 13.) For all rows for which the decoding operation has been successful, the reconstructed data bytes are read out from left to right and top to bottom, and appended to the reconstructed version of the progressive data stream. 14.) For all rows for which the decoding operation has not been successful, a sufficient number of suitable dummy symbols may be added to the reconstructed data stream to inform the source decoder about the missing symbols. One can easily realize that the above rules describe an interleaver, i.e. at the sender a single codeword of a TB is spread out over n successive packets. Thus, each codeword of a transmitted TB experiences the same number of erasures at exactly the same positions. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 9] =0C Internet Draft Unequal Erasure Protection July 2000 Two important conclusions can be drawn from this: a) Since the same RS code is applied to all rows contained in a specific class, either all of them can be correctly decoded or not. Hence, there exist no partly decodable classes at the receiver. b) If decoding is successful for a certain class CA_i, all the classes CA_(i+1)...CA_T can also be decoded, since they are protected by at least one more parity byte per row. Together with rule 4, it is therefore always ensured, that in case a decodable enhancement layer exists, the base layer it depends on can also be reconstructed! Given the maximum erasure protection value T, the redundancy profile for a TB of size (L x n) shall be denoted by a so-called erasure protection vector AV of length (T+1), where AV:=3D(A_0,A_1,...,A_(T-1),A_T) From the above definition, it is easy to realize that the trivial cases of no erasure protection and EXP are a subset of UXP: a) no erasure protection at all: all application data is mapped onto class CA_0, i.e. AV=3D(L,0,0,...,0). b) EXP: all application data is mapped onto class CA_T, i.e. AV=3D(0,0,...,0,A_T=3DL). Hence, backward compatibility to currently standardized non- progressive multimedia codecs is definitely achieved. 7. RTP payload structure For every packet whose payload results from reading out a column of the TB, the RTP header must be followed by an UXP header. 7.1. Specific settings in the RTP header The timestamp of each RTP packet resulting from reading out a TB is set to the time instant when the first byte of the progressive source data stream has been written into the TB. This results in the TS value being the same for all RTP packets belonging to a specific TB. The payload type is of dynamic type, and obtained through out-of- band signaling similar to [1]. The signaling protocol must establish a payload length to be associated with the payload type value. End systems, which cannot recognize a payload type, must discard it. All other fields in the RTP header are set to those values proposed for regular multimedia transmission using the same source codecs, but no erasure protection scheme enabled. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 10] =0C Internet Draft Unequal Erasure Protection July 2000 7.2. Structure of the UXP header The UXP header shall consist of 2 octets, and is shown in Fig. 3: 0 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| block PT | block length n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3: Proposed UXP header The fields in the header shall be defined as follows: - X (bit 0): extension bit, reserved for future enhancements, currently not in use -> default value: 0 - block PT (bits 1-7): regular RTP payload type to indicate the primary source encoding of the media - block length n (bits 8-15): indicates total number of RTP packets resulting from one TB (which equals the number of columns of the TB) Based on the RTP sequence number and the repetition of the block length n in each UXP header, the receiving entity is able to recognize both TB boundaries and the actual position of lost packets in the TB. Furthermore, the specific choice of equal TS values for all RTP packets belonging to a TB allows for overcoming possible sequence number overflow. 7.3. Inband signaling of the structure of the redundancy profile To enable a dynamic adaptation to varying link conditions, the actual redundancy profile used for a specific TB must be signaled to the receiving entity. Since out-of-band signaling either results in excessive additional control traffic, or prevents quick changes of the profile between successive TBs, an inband signaling procedure is desired. At this stage, only a very simple, and thus not very efficient, strategy is shown. There definitely exist better solutions, which will be included in a future version of this draft. As without knowledge of the correct redundancy profile, the decoding process cannot be applied to any of the erasure protection classes, it has to be protected as least as strongly as the base layer data against packet loss. Therefore, a new class CA_P is added to the beginning of the TB, where the number of parity symbols is by default set to the following value: P=3Dceil(n/2) Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 11] =0C Internet Draft Unequal Erasure Protection July 2000 Hence, up to 50% of the RTP packets can be lost, before the redundancy profile cannot be recovered anymore. This seems to be a reasonable value for the lowest point of operation over a lossy link. Consequently, since all other classes must have equal or less erasure protection capability, the maximum allowable value for class CA_T is now limited to T<=3DP. The data to be filled into class CA_P shall consist of a sequence of L bytes, where each byte shall contain the number of parity bytes used for each row in the TB, starting from top to bottom. The total number of rows A_P included in class CA_P is now implicitly known to the receiving entity (since it knows the value of n from interpreting the UXP header): A_P=3D ceil(L/(n-p)) The complete structure of the TB is now depicted in Fig. 4. To avoid stuffing overhead, empty positions in class CA_P may be filled up with the first bytes of the base layer. Transmission Block (TB) P <---------> /\ +-+-+-+-+-+-+-+-+-+ /\ | |?|?|?|?|*|*|*|*|*| | A_P=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |&|&|&|&|&|*|*|*|*| /\ | +-+-+-+-+-+-+-+-+-+ | A_T=3D3 | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | L bytes | |&|&|&|&|&|*|*|*|*| \/ payload | +-+-+-+-+-+-+-+-+-+ /\ per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |$|$|$|$|$|$|$|*|*| . | +-+-+-+-+-+-+-+-+-+ . | |=A7|=A7|=A7|=A7|=A7|=A7|=A7|=A7|*| . | +-+-+-+-+-+-+-+-+-+ /\ | |#|#|#|#|#|#|#|#|#| | A_0=3D1 \/ +-+-+-+-+-+-+-+-+-+ \/ <-----------------> n packets ? : inband signaling of redundancy profile &,%,$,=A7,# : info bytes belonging to a certain source coding layer in decreasing order of importance * : parity bytes gained from Reed-Solomon coding Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 12] =0C Internet Draft Unequal Erasure Protection July 2000 Fig. 4: General structure for UXP with inband signaling of redundancy profile 8. Security Considerations The issues addressed in this IETF draft are not subject to any security considerations. 9. References [1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", Request for Comments 2733, Internet Engineering Task Force, Dec. 1999. [2] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, "Priority encoding transmission", IEEE Trans. Inform. Theory, vol. 42, no. 6, pp. 1737-1744, Nov. 1996. [3] Shu Lin and Daniel J. Costello, Error Control Coding: Fundamentals and Applications, Prentice-Hall, Inc., Englewood Cliffs, N.J., 1983. [4] W. Li: "Fine Granularity Scalability Using Bit-Plane Coding of DCT Coefficients", ISO/IEC JTC1/SC29/WG11, Doc. MPEG98/M4204, Dec. 1998. [5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May 2000. [6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V coding for lossy packet networks - a principle approach", Tech. Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999. [7] Guenther Liebl, "Modeling, theoretical analysis, and coding for wireless packet erasure channels", Diploma Thesis, Inst. for Communications Engineering, Munich University of Technology, 1999. 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 10. Acknowledgments Many thanks to Thomas Stockhammer, who initially came up with the idea of unequal erasure protection to improve progressive video transmission over lossy networks. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 13] =0C Internet Draft Unequal Erasure Protection July 2000 11. Author's Addresses Minh-Ha Nguyen, Guenther Liebl Institute for Communications Engineering (LNT) Munich University of Technology D-80290 Munich Germany Email: {nguyen,liebl}@lnt.ei.tum.de Bernhard Wimmer, Frank Burkert Siemens AG - ICM CD MP D-81675 Munich Germany Email: {bernhard.wimmer,frank.burkert}@mch.siemens.de Juergen Pandel Siemens AG - Corporate Technology ZT IK2 D-81730 Munich Germany Email: juergen.pandel@mchp.siemens.de Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 14] =0C Internet Draft Unequal Erasure Protection July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 15] =0C ------_=_NextPart_000_01C0029A.D9303C10-- From rem-conf Thu Aug 10 07:35:47 2000 From rem-conf-request@es.net Thu Aug 10 07:35:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13MtLi-00005Q-00; Thu, 10 Aug 2000 07:30:22 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13MtLb-00005A-00; Thu, 10 Aug 2000 07:30:20 -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 OAA02764; Thu, 10 Aug 2000 14:52:43 +0100 Message-Id: <200008101352.OAA02764@purple.east.isi.edu> To: Frank.Burkert@mch.siemens.de cc: rem-conf@es.net Subject: Re: draft-lnt-avt-uxp-00.txt In-Reply-To: Message from Frank.Burkert@mch.siemens.de of "Thu, 10 Aug 2000 09:16:05 +0200." <8C8712EF8143D311A67B00508B0FD51901053535@mchg9eda.mchh.siemens.de> Date: Thu, 10 Aug 2000 09:52:42 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Please note that this version has changes in the "status of this memo section", and is now in full compliance with section 10 of RFC2026. Cheers, Colin --> Frank.Burkert@mch.siemens.de writes: >Dear experts, > >please find attched to this email our proposal for "An RTP Payload Format >for Erasure-Resilient Transmission of Progressive Multimedia Streams" >(draft-lnt-avt-uxp-00.txt) that has been presented at the 48th IETF Meeting >last week. > >Any comments are highly appreciated, > Frank > > >Internet Engineering Task Force M. Nguyen, G. Liebl >Internet Draft LNT, Munich Univ. of > Technology >Document: draft-lnt-avt-uxp-00.txt >July 2000 B. Wimmer, F. > Burkert, J.Pandel >Expires: January 2001 Siemens AG, Munich > > >An RTP Payload Format for Erasure-Resilient Transmission of Progressive > Multimedia Streams > > >Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 [1]. ... From rem-conf Thu Aug 10 16:17:03 2000 From rem-conf-request@es.net Thu Aug 10 16:17:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13N1Lb-0005Ay-00; Thu, 10 Aug 2000 16:02:47 -0700 Received: from tnt1a-48.newyork.corecomm.net (mx.boston.juno.com) [216.214.109.48] by mail1.es.net with smtp (Exim 1.81 #2) id 13N1LV-00059p-00; Thu, 10 Aug 2000 16:02:42 -0700 From: Subject: re:from Lorraine - Philippines $0.23, Japan $.09,china $.31,malaysia$.18 and more,cant bet these Date: Thu, 10 Aug 2000 15:34:19 Message-Id: <15.481510.640137@mx.boston.juno.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ONLY IF YOU WANT YOUR PHONE BILL CUT IN 1/2 !!!!!!!!!!!!$$$$$$$$$$$$$$ -------CLICK HERE--- http://www.hometown.aol.com/cheaprates123/advertisment/index.html _________________________________________________________________ ___________________________ As I promise ,I WILL PAY CUT YOU PHONE BILL IN 1/2 IF YOU JUST GIVE ME A CHANCE!! AT&T,SPRINT, MCI long distance carriers are getting rich off of You and ME Please take a look at My rates, we are sure I will beat their price. There are no monthly or minimum fees or any other hidden costs. You just pay for the time you are on the phone. If your paying less,I will beat what your paying no matter what!!!!!! For a complete rate chart and sign-up info http://www.hometown.aol.com/cheaprates123/advertisment/index.html Example: Germany .05+ USA .05 =.10 per minute Country Code Per Minute Algeria-----------------213 0.26 American Samoa----------684 0.16 Andorra-----------------336 0.17 Angola------------------244 0.36 Anguilla----------------264 0.34 Antigu------------------268 0.40 Aruba-------------------297 0.26 Bahamas-----------------242 0.16 Bangladesh--------------880 0.64 Barbados----------------246 0.42 Belize------------------501 0.51 Bermuda-----------------441 0.16 Canada------------------ 0.07 Cape Verde-------------238 0.43 Caymans-----------------345 0.26 Dominica----------------767 0.44 Dominican Rep.----------809 0.14 Egypt-------------------20 0.51 France------------------33 0.06 Germany-----------------49 0.05 Grand Turk--------------649 0.44 Grenada-----------------473 0.42 Jordan------------------962 0.51 Lebanon*----------------961 0.40 Papua New Guinea-------675 0.31 Saudi Arabia-----------966 0.59 St Helena---------------290 0.59 St Kitts----------------869 0.35 St Lucia----------------758 0.42 St Pierre---------------508 0.22 St Vincent--------------784 0.42 Trinidad----------------868 0.47 U S Virgin--------------340 0.07 United Arab Emirates---971 0.31 United Kingdom----------44 0.05 USA---------------------1 0.05 Add the country you're calling from to the country you're calling, to get the rate per minute Rates apply 24 hrs/day, 7 days per week NO sign-up fees, NO monthly fees, and NO surcharges You DO NOT have to SWITCH your current provider Ideal for Home and Business use Callback service is available to/from anywhere in the world. Contact ME for more information and complete rate table at: mailto:cheaprates1234@earthlink.net http://hometown.aol.com/cheaprates123 Just Tell me what you want to pay !!!!!! If you would like to be removed from our list, please reply to: mailto:cheaprates1234@earthlink.net with the word "remove" in the subject line. **************************************************** From rem-conf Fri Aug 11 09:49:37 2000 From rem-conf-request@es.net Fri Aug 11 09:49:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NHt2-0005Rm-00; Fri, 11 Aug 2000 09:42:24 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NHt0-0005Rc-00; Fri, 11 Aug 2000 09:42:22 -0700 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id BEE764CE0B; Fri, 11 Aug 2000 12:42:21 -0400 (EDT) Received: from minerve (fpdhcp030.research.att.com [135.207.28.30]) by bigmail.research.att.com (8.8.8/8.8.8) with SMTP id MAA04263; Fri, 11 Aug 2000 12:42:21 -0400 (EDT) From: "Timur Friedman" To: "rem-conf" Cc: "Dorgham Sisalem" , "Adam Wolisz" , "Kevin Almeroth" , "Kamil Sarac" , "Ramon Caceres" Subject: receiver-based RTTs Date: Fri, 11 Aug 2000 12:42:21 -0400 Message-ID: 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 Are special reports needed to allow receivers to caculate RTTs? Or can the existing RTCP mechanism be adapted? This issue came up in Pittsburgh while discussing the RTCP Reporting Extensions draft. I will argue for the special reports that are in the draft. RTCP allows senders to calculate RTTs. Receivers echo back a sender's timestamp along with an indication of how long they waited before the echo (the RR DLSR field). However, only a sender knows when it receives the echo, and so only senders know RTTs. This is fine for sender-based congestion control, but does not help receiver-based congestion control. Dorgham Sisalem and Adam Wolisz have designed MLDA, a receiver-based congestion control mechanism for RTP. The receivers need to know RTTs between themselves and the senders. We have suggested special reporting blocks to support this -- essentially a receiver timestamp, and an echo with delay information from the sender -- as part of the RTCP Reporting Extensions draft. In Pittsburgh, it was suggested that a simpler way of achieving the same effect would be to have all receivers make themselves into senders, by each sending a small occasional packet. This would save us from adding additional mechanism. It seemed to me at the time as a possible alternative. But I have discussed this idea with Dorgham, and he has convinced me that the additional mechanism is needed. As I understand his arguments: (1) If all receivers become senders, then all receivers will by default send reports on all other receivers. This is considerable unneeded overhead. They only need to send reports on the actual data senders. (2) If all receivers become senders, then this by default does away with the recommended 1/4 of RTCP bandwidth reserved to data senders. (3) The data packets sent by the receivers, even if small and occasional, do consume bandwidth. Based on this, I see real value in keeping the special reports in the draft as it moves towards Experimental RFC. - Timur Friedman References: RTCP Reporting Extensions draft MLDA D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Eighth International Workshop on Quality of Service (IWQoS 2000), 5-7 June 2000, Pittsburgh. From rem-conf Fri Aug 11 09:50:52 2000 From rem-conf-request@es.net Fri Aug 11 09:50:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NHyv-0005UC-00; Fri, 11 Aug 2000 09:48:29 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NHyu-0005U2-00; Fri, 11 Aug 2000 09:48:28 -0700 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA04085; Fri, 11 Aug 2000 18:48:12 +0200 (MET DST) Message-Id: <200008111648.SAA04085@mailhub.fokus.gmd.de> To: cabo@tzi.org, tme@21rst-century.com cc: rem-conf@es.net Subject: RE: New congestion control text in RTP spec Date: Fri, 11 Aug 2000 18:48:10 +0200 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> The profile draft states : >> >> If best-effort service is being used, RTP receivers SHOULD >> monitor packet loss to ensure that the packet loss rate is >> within acceptable parameters. Packet loss is considered >> acceptable if a TCP flow across the same network path and >> experiencing the same network conditions would achieve an >> average throughput that is not less the RTP flow is >> achieving. >> >> [...] several MP3 packets will be lost in a row. I would fear that any >> simple minded >> congestion monitoring would then conclude that there was congestion, and >> ramp down the UDP. >Then don't use a simple minded congestion monitoring scheme! >Schemes like TFRC have been designed to compete fairly with TCP. >(However, in your example, where you send 90 kbit/s RTP over a 128 kbit/s >link, TFRC would still try to regulate that down to around 64 kbit/s if you >have a bulk data TCP connection going at the same time.) well not really, TCP-friendly adaptation schemes assume not only that the TCP and UDP flows suffer from similar losses and delays but also have the same packet size. Thereby, an equation based scheme would not result in equal distribution in this case >> "If best-effort service is being used, RTP receivers SHOULD >> monitor packet loss to ensure that the packet loss rate is >> within acceptable parameters. Packet loss is considered >> acceptable for a receiver if the RTP flow to that receiver achieves an >> average throughput that is not less than 90% of the nominal >> bandwidth for that RTP flow." >Now that would be a "simple minded congestion monitoring" scheme, indeed! agreed, I would reformulate the sentence to: "If best-effort service is being used, RTP receivers SHOULD monitor packet loss, delay and jitter values and use some congestion control scheme that on the one hand aims at achieving a fair bandwidth distribution among competing flows and an acceptable perceived QoS. As an example for a definition of a fair bandwidth distribution would be to require that a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput that is not less the RTP flow is achieving. The definition of an acceptable perceived QoS might be defined in terms of loss and delay ranges as measured at the application level and indicated in the RTP profile." Regards Dorgham From rem-conf Fri Aug 11 10:58:55 2000 From rem-conf-request@es.net Fri Aug 11 10:58:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NJ1w-0001WD-00; Fri, 11 Aug 2000 10:55:40 -0700 Received: from ids2.idsonline.com [205.177.236.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NJ1u-0001W3-00; Fri, 11 Aug 2000 10:55:38 -0700 Received: from 21rst-century.com (laurel-md-114.idsonline.com [209.8.42.114]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id NAA23712; Fri, 11 Aug 2000 13:55:05 -0400 Message-ID: <39943E11.F2FF5311@21rst-century.com> Date: Fri, 11 Aug 2000 13:55:31 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dorgham Sisalem CC: cabo@tzi.org, rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <200008111648.SAA04085@mailhub.fokus.gmd.de> 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 Dorgham Sisalem wrote: > >> The profile draft states : > >> > >> If best-effort service is being used, RTP receivers SHOULD > >> monitor packet loss to ensure that the packet loss rate is > >> within acceptable parameters. Packet loss is considered > >> acceptable if a TCP flow across the same network path and > >> experiencing the same network conditions would achieve an > >> average throughput that is not less the RTP flow is > >> achieving. > >> > >> [...] several MP3 packets will be lost in a row. I would fear that any > >> simple minded > >> congestion monitoring would then conclude that there was congestion, and > >> ramp down the UDP. > > >Then don't use a simple minded congestion monitoring scheme! > >Schemes like TFRC have been designed to compete fairly with TCP. > >(However, in your example, where you send 90 kbit/s RTP over a 128 kbit/s > >link, TFRC would still try to regulate that down to around 64 kbit/s if you > >have a bulk data TCP connection going at the same time.) > > well not really, TCP-friendly adaptation schemes assume not only > that the TCP and UDP flows suffer from similar losses and delays > but also have the same packet size. Thereby, an equation based > scheme would not result in equal distribution in this case > > >> "If best-effort service is being used, RTP receivers SHOULD > >> monitor packet loss to ensure that the packet loss rate is > >> within acceptable parameters. Packet loss is considered > >> acceptable for a receiver if the RTP flow to that receiver achieves an > >> average throughput that is not less than 90% of the nominal > >> bandwidth for that RTP flow." > > >Now that would be a "simple minded congestion monitoring" scheme, indeed! > agreed, I would reformulate the sentence to: > > "If best-effort service is being used, RTP receivers SHOULD > monitor packet loss, delay and jitter values and use some congestion > control scheme that on the one hand aims at achieving a fair bandwidth > distribution among competing flows and an acceptable perceived QoS. > As an example for a definition of a fair bandwidth distribution would > be to require that a TCP flow across the same network path and > experiencing the same network conditions would achieve an > average throughput that is not less the RTP flow is achieving. > The definition of an acceptable perceived QoS might be defined in terms > of loss and delay ranges as measured at the application level and > indicated in the RTP profile." > > > Regards > Dorgham Hello; There are two kinds of congestion control, which could be loosely called on the backbone, and at the receiver. TCP needs to worry about both, as it will seize ALL of the bandwidth it can. I would strongly argue that multicast RTP/UDP mostly needs to worry about the receiver congestion problem. I would strongly argue that if I'm watching a video (say) and start an FTP session or click on a web site button, that I do NOT in general want my TV picture to degrade or disappear. I have chosen a given level of reception; please do not I assume that I want less unless I ask for it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the same way. Also consider the zeroconf home network case, which I think in the long run will dominate the use of these services. is at home listening to an Internet radio using multicast RTP over a home LAN. The TV remote control (say) starts its daily automatic download of the latest channel guide using TCP. The radio reception gets progressively worse over a 5 minute period. My mother concludes the radio is defective, and throws it out. Is that really what we want ? I would thus argue that 1.) - An equal sharing between TCP and multicast RTP/UDP is NOT what should be done, even if the RTP session could figure out what TCP sessions were up to, and 2.) - multicast RTP should preserver even given occasional episodes of congestion, as these are likely due to TCP slow start/congestion control and 3.) As Dorgham says, multicast RTP should worry most about reception at the receiver, and only give up or degrade service if conditions are truly unacceptable. What, you may ask, if I ask for 1.5 mbit / sec video over a 56k phone line ? Well, I won't get reception, and will then turn it off or seek some other service. I do not think that this is the type of congestion we are fighting here! -- 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@21rst-century.com tme@multicasttech.com http://www.buzzwaves.com http://www.on-the-i.com From rem-conf Sat Aug 12 08:33:23 2000 From rem-conf-request@es.net Sat Aug 12 08:33:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Nd2D-0003yi-00; Sat, 12 Aug 2000 08:17:17 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Nd2B-0003yY-00; Sat, 12 Aug 2000 08:17:15 -0700 Received: from track.fokus.gmd.de (track [193.175.133.61]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA04267; Sat, 12 Aug 2000 17:17:13 +0200 (MET DST) Received: from localhost (dor@localhost) by track.fokus.gmd.de (SMI-8.6/8.6.12) with ESMTP id RAA08449; Sat, 12 Aug 2000 17:17:11 +0200 X-Authentication-Warning: track.fokus.gmd.de: dor owned process doing -bs Date: Sat, 12 Aug 2000 17:17:11 +0200 (MET DST) From: Dorgham Sisalem To: Thomas Marshall Eubanks cc: rem-conf@es.net Subject: Re: New congestion control text in RTP spec In-Reply-To: <39943E11.F2FF5311@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; > > There are two kinds of congestion control, which could be loosely called on the backbone, and > at the receiver. TCP needs to worry about both, as it will seize ALL of the bandwidth it can. > I would strongly argue that multicast RTP/UDP mostly needs to worry about the receiver congestion > problem. I would strongly argue that if I'm watching a video (say) and start an FTP session or > click on a web site button, that I do NOT in general want my TV picture to degrade or disappear. > I have chosen a given level of reception; please do not I assume that I want less unless I ask for > it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the > same way. > this is a little bit too user centric. The main goal of congestion control is to avoid congestion in the network. What I wanted to stress here is that congestion control schemes for multimedia communication should combine the user perceived QoS aspects with network congestion avoidance (i.e., the congestion control schemes should not only base their control behavior on network parameters such as loss and delay but also take application and user constraints into account as well. While this might cause a congestion control scheme to be temprarily unfair towards other streams but on the whole one it could be made to act fair over longer time periods. Dorgham > Also consider the zeroconf home network case, which I think in the long run will dominate the use of these > services. is at home listening to an Internet radio using multicast > RTP over a home LAN. The TV remote control (say) starts its daily automatic download > of the latest channel guide using TCP. The radio reception gets progressively worse over a 5 minute > period. My mother concludes the radio is defective, and throws it > out. Is that really what we want ? > > I would thus argue that > > 1.) - An equal sharing between TCP and multicast RTP/UDP is NOT what should be done, even > if the RTP session could figure out what TCP sessions were up to, and > > 2.) - multicast RTP should preserver even given occasional episodes of congestion, as these are > likely due to TCP slow start/congestion control and > > 3.) As Dorgham says, multicast RTP should worry most about reception at the receiver, and only give > up or degrade service if conditions are truly unacceptable. > > What, you may ask, if I ask for 1.5 mbit / sec video over a 56k phone line ? Well, I won't get > reception, and will then turn it off or seek some other service. I do not think that this is the type > of congestion we are fighting here! > > -- > 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@21rst-century.com tme@multicasttech.com > > http://www.buzzwaves.com http://www.on-the-i.com > > > From rem-conf Sat Aug 12 08:55:03 2000 From rem-conf-request@es.net Sat Aug 12 08:55:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NdXj-0004np-00; Sat, 12 Aug 2000 08:49:51 -0700 Received: from mumble.cs.rpi.edu (cs.rpi.edu) [128.213.8.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NdXi-0004na-00; Sat, 12 Aug 2000 08:49:50 -0700 Received: from ephraim.cs.rpi.edu (glinert@ephraim.cs.rpi.edu [128.213.8.39]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id LAA76726; Sat, 12 Aug 2000 11:49:36 -0400 (EDT) From: "Ephraim P. Glinert" Received: (from glinert@localhost) by ephraim.cs.rpi.edu (8.9.1/8.9.1) id LAA28485; Sat, 12 Aug 2000 11:49:34 -0400 (EDT) Date: Sat, 12 Aug 2000 11:49:34 -0400 (EDT) Message-Id: <200008121549.LAA28485@ephraim.cs.rpi.edu> To: end2end-interest@isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: Join Us At ASSETS'2000! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My apologies if you receive multiple copies of this mailing. -EPG ------------------------------------------------------------------- The ASSETS 2000 Advance Program is now available. For a preview of the excellent set of papers being presented, go to http://www.acm.org/sigs/conferences/assets00/ and take the link to the Technical Program. The online registration forms will shortly be available so plan now to attend both ASSETS 2000 and the Conference on Universal Usability that will be held back-to-back this November 13-17 in Washington, DC From rem-conf Sun Aug 13 05:08:52 2000 From rem-conf-request@es.net Sun Aug 13 05:08:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NwXf-0006Fc-00; Sun, 13 Aug 2000 05:07:03 -0700 Received: from ids2.idsonline.com [205.177.236.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NwXc-0006FR-00; Sun, 13 Aug 2000 05:07:00 -0700 Received: from 21rst-century.com (dc-csesp140.idsonline.com [207.176.21.140]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id IAA22887; Sun, 13 Aug 2000 08:06:18 -0400 Message-ID: <39968F5F.7951CA54@21rst-century.com> Date: Sun, 13 Aug 2000 08:06:55 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dorgham Sisalem CC: rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: 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 Hello; Dorgham Sisalem wrote: > > Hello; > > > > There are two kinds of congestion control, which could be loosely called on the backbone, and > > at the receiver. TCP needs to worry about both, as it will seize ALL of the bandwidth it can. > > I would strongly argue that multicast RTP/UDP mostly needs to worry about the receiver congestion > > problem. I would strongly argue that if I'm watching a video (say) and start an FTP session or > > click on a web site button, that I do NOT in general want my TV picture to degrade or disappear. > > I have chosen a given level of reception; please do not I assume that I want less unless I ask for > > it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the > > same way. > > > this is a little bit too user centric. The main goal of congestion control > is to avoid congestion in the network. What I wanted to stress here is It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ? A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ? Consider the case of the recent Napster flaps, when some colleges found that 80% of their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically shut it down : 1.) Many TCP sessions are not benign on a local LAN. 2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any backbone. 3.) The congestion control implemented was manual intervention. As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should be aggressive versus local TCP, as it is doing what the user has requested. Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then this might be a problem, but NO pre-planned congestion control is likely to fix it, and it will fix itself, as the reception quality will be bad and people will turn it off. In the worse case, the network operators will have to intervene manually basically no matter what RTP is doing, no different from TCP. I have had backbone people tell me that, with all of the dark fiber out there, even dozens of "little" 200 kbps or 1 mbps multicast streams will be "in the noise" in terms of usage on their backbones. I would take them at their word :) And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there will not be any RTP. It is different from TCP in that regard - no matter what sort of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an acceptable user experience is pretty small. By contrast, the TCP dynamic range is enormous. > > that congestion control schemes for multimedia communication should > combine the user perceived QoS aspects with network congestion avoidance > (i.e., > the congestion control schemes should not only base their control behavior > on network parameters such as loss and delay but also take application and > user constraints into account as well. While this might cause a congestion > control scheme to be temprarily unfair towards other streams but on the > whole one it could be made to act fair over longer time periods. > > Dorgham > 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@21rst-century.com tme@multicasttech.com http://www.buzzwaves.com http://www.on-the-i.com From rem-conf Sun Aug 13 05:08:52 2000 From rem-conf-request@es.net Sun Aug 13 05:08:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NwSx-0006EF-00; Sun, 13 Aug 2000 05:02:11 -0700 Received: from ids2.idsonline.com [205.177.236.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NwSv-0006E5-00; Sun, 13 Aug 2000 05:02:09 -0700 Received: from 21rst-century.com (dc-csesp140.idsonline.com [207.176.21.140]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id IAA22824; Sun, 13 Aug 2000 08:01:25 -0400 Message-ID: <39968E3A.50B49F31@21rst-century.com> Date: Sun, 13 Aug 2000 08:02:02 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dorgham Sisalem CC: rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: 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 Hello; Dorgham Sisalem wrote: > > Hello; > > > > There are two kinds of congestion control, which could be loosely called on the backbone, and > > at the receiver. TCP needs to worry about both, as it will seize ALL of the bandwidth it can. > > I would strongly argue that multicast RTP/UDP mostly needs to worry about the receiver congestion > > problem. I would strongly argue that if I'm watching a video (say) and start an FTP session or > > click on a web site button, that I do NOT in general want my TV picture to degrade or disappear. > > I have chosen a given level of reception; please do not I assume that I want less unless I ask for > > it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the > > same way. > > > this is a little bit too user centric. The main goal of congestion control > is to avoid congestion in the network. What I wanted to stress here is It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ? A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ? Consider the case of the recent Napster flaps, when some colleges found that 80% of their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically shut it down : 1.) Many TCP sessions are not benign on a local LAN. 2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any backbone. 3.) The congestion control implemented was manual intervention. As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should be aggressive, as it is doing what the user has requested. Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then this might be a problem, but NO pre-planned congestion control is likely to fix it, and the network operators will have to intervene manually basically no matter what RTP is doing. I have had backbone people tell me that, with all of the dark fiber out there, even dozens of "little" 200 kbps or 1 mbps muticast streams will be "in the noise" in terms of usage on their backbones. I would take them at their word :) And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there will not be any RTP. It is different from TCP in that regard - no matter what sort of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an acceptable user experience is pretty small. > > that congestion control schemes for multimedia communication should > combine the user perceived QoS aspects with network congestion avoidance > (i.e., > the congestion control schemes should not only base their control behavior > on network parameters such as loss and delay but also take application and > user constraints into account as well. While this might cause a congestion > control scheme to be temprarily unfair towards other streams but on the > whole one it could be made to act fair over longer time periods. > > Dorgham > 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@21rst-century.com tme@multicasttech.com http://www.buzzwaves.com http://www.on-the-i.com From rem-conf Sun Aug 13 07:39:09 2000 From rem-conf-request@es.net Sun Aug 13 07:39:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13NyrY-0001Aa-00; Sun, 13 Aug 2000 07:35:44 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13NyrW-0001AQ-00; Sun, 13 Aug 2000 07:35:42 -0700 Received: from track.fokus.gmd.de (track [193.175.133.61]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA02334; Sun, 13 Aug 2000 16:35:40 +0200 (MET DST) Received: from localhost (dor@localhost) by track.fokus.gmd.de (SMI-8.6/8.6.12) with ESMTP id QAA09071; Sun, 13 Aug 2000 16:35:38 +0200 X-Authentication-Warning: track.fokus.gmd.de: dor owned process doing -bs Date: Sun, 13 Aug 2000 16:35:38 +0200 (MET DST) From: Dorgham Sisalem To: Thomas Marshall Eubanks cc: Dorgham Sisalem , rem-conf@es.net Subject: Re: New congestion control text in RTP spec In-Reply-To: <39968E3A.50B49F31@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 > > It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ? a network is any part between the sender and receiver that might get congested > A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ? TCP might not be the PERFECT system, but I guess this is irrelevant and there is really no reason in starting a flame war again about if TCP is good or bad, it is here and it will stay so I do not see the reason behind this question > Consider the case of the recent Napster flaps, when some colleges found that 80% of > their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically > shut it down : > so what? > 1.) Many TCP sessions are not benign on a local LAN. > 2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any > backbone. UDP based multimedia traffic might not be more than noise comaped to the TCP part but this is supposed to change > 3.) The congestion control implemented was manual intervention. > ??? how are we supposed to understand this now? Disabling some kind of traffic might solve the most serious problems but is not a solution in itself (web traffic seems to be taking a large share of the bandwidth on most networks, shoud we just shut it out to save ftp and mail flows??) > As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should > be aggressive, as it is doing what the user has requested. > This might be OK if the sum of flows that do that is small relative to the overall number,as soon as this changes you will get into trouble -or maybe we can start having different protocol stacks for the LAN and WAN cases and the user would need to specify what mode to use (:-) > Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously > congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then > this might be a problem, but NO pre-planned congestion control is likely to fix it, and the network operators > will have to intervene manually basically no matter what RTP is doing. > TCP has done a good job in fixing congestion for ages now so what is the argument against doing similar things with UDP. This napster example is not a very convincing one. so there were too many TCP flows which the administrators decided to be not very usefull and and that slow down more important ones (such as web traffic???), however even under this situation, all users get some bandwidth. > I have had backbone people tell me that, with all of the dark fiber out there, even dozens of "little" 200 kbps or > 1 mbps muticast streams will be "in the noise" in terms of usage on their backbones. > I would take them at their word :) > > And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there > will not be any RTP. It is different from TCP in that regard - no matter what sort > of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an > acceptable user experience is pretty small. > lots of video compression styles provide for a wide range of adaptation, and there is lots what one can do with audio as well. This discussion is getting too relegious (adapt or not adapt) and I am not sure the rem-conf list is the right place for that, so unless lots of other people would like to join the discussion we should do it directly? Regards From rem-conf Sun Aug 13 23:42:31 2000 From rem-conf-request@es.net Sun Aug 13 23:42:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ODix-0001Vd-00; Sun, 13 Aug 2000 23:27:51 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ODiu-0001VI-00; Sun, 13 Aug 2000 23:27:49 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id JAA08777; Mon, 14 Aug 2000 09:23:52 +0300 (IDT) Message-ID: <39979509.63C389ED@bitband.com> Date: Mon, 14 Aug 2000 08:43:22 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: tme@21rst-century.com CC: Dorgham Sisalem , rem-conf@es.net Subject: Re: RTP Security (Was: New congestion control text in RTP spec) References: <39968F5F.7951CA54@21rst-century.com> <399699D7.6F38CA5E@bitband.com> <39970DD3.F73B1AB9@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 Thomas Marshall Eubanks wrote: > [snip] > > As a guess, I would say > > - Multicast RTP's potential for DOS type attacks is small (it's one to many, not many to one). > If this "one to many" mechanism is coupled with a "reflector" mechanism, where all reflected traffic is directed at a "target" site, then DDOS is possible. Other one-to-many mechanisms (e.g. directed broadcast) have caused havoc in the past. > > - at present, there is strong potential to hack INTO rtp streams - inserting bogus > content, or denying users the RTP. I.e., RTP itself is sensitive to DOS at present. > Maybe SSM and other uses of IGMP v3 can prevent this to some degree. > I would suggest not to take this lightly - suppose a hacker can insert his own "words of truth" into a very popular radio channel on the Internet, and easily get the attention of millions of people ? Spam e-mail seems quite benign when compared to an effect of this. > > - multicasting one to many plus a virus/worm/trojan horse etc. inserted into the stream could be devastating. > Spread times could be measured in milliseconds, not hours or days. > This is a real problem if browsers are going to be playing streams or displaying > "pushed" text. Neither SSM nor RTP can prevent this, as it is really a client-side problem. > Indeed it seems that Multicast could prove an exremely powerful exploit due to its rapid spread time, and if it becomes deployed on a large scale, this could lead to disasters. I do not agree that RTP can not prevent this, there is sufficient knowledge out there which can be used to enhance these protocols for better robustness, and a set of implementation guidelines which will result in interoperable applications which are also resistent to at least the sorts of attacks which are already known to occur. Leonid From rem-conf Mon Aug 14 04:07:26 2000 From rem-conf-request@es.net Mon Aug 14 04:07:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OHzL-0004I2-00; Mon, 14 Aug 2000 04:01:03 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OHzJ-0004Hs-00; Mon, 14 Aug 2000 04:01:01 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03094; Mon, 14 Aug 2000 07:00:59 -0400 (EDT) Message-Id: <200008141100.HAA03094@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-profile-interop-02.txt Date: Mon, 14 Aug 2000 07:00:59 -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 Audio/Video Profile Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-profile-interop-02.txt Pages : 5 Date : 11-Aug-00 It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile 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-profile-interop-02.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-profile-interop-02.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-profile-interop-02.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: <20000811092235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-interop-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-interop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811092235.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Aug 14 04:07:26 2000 From rem-conf-request@es.net Mon Aug 14 04:07:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OHzP-0004IE-00; Mon, 14 Aug 2000 04:01:07 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OHzO-0004I4-00; Mon, 14 Aug 2000 04:01:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03161; Mon, 14 Aug 2000 07:01:04 -0400 (EDT) Message-Id: <200008141101.HAA03161@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-04.txt Date: Mon, 14 Aug 2000 07:01:04 -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-04.txt Pages : 6 Date : 11-Aug-00 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-04.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-04.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-04.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: <20000811092330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811092330.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Aug 14 04:07:26 2000 From rem-conf-request@es.net Mon Aug 14 04:07:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OHzT-0004IR-00; Mon, 14 Aug 2000 04:01:11 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OHzR-0004IG-00; Mon, 14 Aug 2000 04:01:10 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03177; Mon, 14 Aug 2000 07:01:08 -0400 (EDT) Message-Id: <200008141101.HAA03177@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-g7221-01.txt Date: Mon, 14 Aug 2000 07:01:08 -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 for ITU-T Recommendation G.722.1 Author(s) : P. Luthi Filename : draft-ietf-avt-rtp-g7221-01.txt Pages : 7 Date : 11-Aug-00 ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet [3]. Also included here are the necessary details for the use of G.722.1 with MIME [4] and SDP [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-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-rtp-g7221-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-rtp-g7221-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: <20000811092342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-g7221-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-g7221-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000811092342.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Aug 14 05:40:40 2000 From rem-conf-request@es.net Mon Aug 14 05:40:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OJQ5-0007eV-00; Mon, 14 Aug 2000 05:32:45 -0700 Received: from mailman.cisco.com [171.68.225.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OJQ4-0007eA-00; Mon, 14 Aug 2000 05:32:44 -0700 Received: from cisco.com (atlantis-dial-1-113.cisco.com [171.68.181.114]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24211 for ; Mon, 14 Aug 2000 05:31:35 -0700 (PDT) Message-ID: <39975A36.5BFBB0FD@cisco.com> Date: Sun, 13 Aug 2000 22:32:23 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Timestamp/sequence# following SSRC collision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Greetings The initial value of the RTP timestamp and sequence number SHOULD be random, and if a source discovers an SSRC collision with itself, it MUST send an RTCP BYE packet. When the source re-joins the session with a new SSRC, should the initial RTP timestamp and sequence number be random again, or can we continue using the old "sequence" ? Does it matter ? Thanks Flemming -- Flemming Andreasen Cisco Systems From rem-conf Mon Aug 14 09:02:32 2000 From rem-conf-request@es.net Mon Aug 14 09:02:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OMYm-00033n-00; Mon, 14 Aug 2000 08:53:56 -0700 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OMYl-00030r-00; Mon, 14 Aug 2000 08:53:55 -0700 Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com; Mon, 14 Aug 2000 08:53:13 -0700 Received: from localhost ([127.0.0.1] helo=entera.com ident=ronf) by savage.entera.com with esmtp (Exim 3.12 #1 (Debian)) id 13OMXR-0007pg-00; Mon, 14 Aug 2000 08:52:33 -0700 To: Flemming Andreasen cc: rem-conf@es.net Subject: Re: Timestamp/sequence# following SSRC collision In-Reply-To: Your message of "Sun, 13 Aug 2000 22:32:23 -0400." <39975A36.5BFBB0FD@cisco.com> References: <39975A36.5BFBB0FD@cisco.com> Date: Mon, 14 Aug 2000 08:52:33 -0700 From: ronf@entera.com (Ron Frederick) Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <39975A36.5BFBB0FD@cisco.com> you write: > Greetings > > The initial value of the RTP timestamp and sequence number SHOULD be > random, and if a source discovers an SSRC collision with itself, it MUST > send an RTCP BYE packet. When the source re-joins the session with a new > SSRC, should the initial RTP timestamp and sequence number be random > again, or can we continue using the old "sequence" ? Does it matter ? > >From the point of view of some other receiver in the session, the new SSRC is going to make this participant seem like a brand new sender, at least until some time later when the first RTCP arrives with their CNAME. So, I don't really see any value in preserving the sequence numbers and timestamps. I would treat this case the same as when you first start up and suggest picking a new random offset for each. I'm not sure it strongly matters, though. -- Ron Frederick ronf@entera.com From rem-conf Mon Aug 14 12:53:17 2000 From rem-conf-request@es.net Mon Aug 14 12:53:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OQ8G-00069A-00; Mon, 14 Aug 2000 12:42:48 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OQ8E-00068m-00; Mon, 14 Aug 2000 12:42:46 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA15580 for ; Mon, 14 Aug 2000 12:42:46 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id MAA10432 for rem-conf@es.net; Mon, 14 Aug 2000 12:42:45 -0700 (PDT) Date: Mon, 14 Aug 2000 12:42:45 -0700 (PDT) Message-Id: <200008141942.MAA10432@rum.isi.edu> To: rem-conf@es.net Subject: SIGCOMM 2000 - Final Call for Participation X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list THIS IS THE FINAL REMINDER: Registration is still open, but we are quickly approaching our limit of 500 participants. Please register as soon as possible to reserve a spot. Please see the website below for further information. --------------------------------------------------------------- Final Call for Participation ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. All papers are currently available at the conference at the conference website. The SIGCOMM 2000 Award is being given to Prof. Andre Danthine, University of Liege, Belgium, who will also provide the keynote address. Registration The conference and hotel registration is handled by the Stockholm Convention Bureau (for instructions, see the website). ********************************************************* ** Note that the number of delegates is limited to 500 ** ** and that registration requests will be handled on a ** ** "first-come-first-served" basis. ** ********************************************************* On-line, secure registration is available at the SIGCOMM website. Please refer to the web or paper forms for various rates and options. Stockholm, Opening Reception and Dinner events Stockholm - the Royal capital of Sweden - is one of the most beautiful cities in the world. It is built on fourteen islands and surrounded by waters so clean that you can fish and swim in the middle of the city. The reception is generously hosted by Stockholm City, and includes a sightseeing cruise on the water ways of Stockholm, through the Old Town to the City Hall, famous for the Nobel Prize festivities. The banquet dinner is hosted at the Vasa Museum, site of the Sweden's largest and most prestigious warship. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) From rem-conf Mon Aug 14 13:04:07 2000 From rem-conf-request@es.net Mon Aug 14 13:04:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OQP0-00070l-00; Mon, 14 Aug 2000 13:00:06 -0700 Received: from thunderer.concentric.net (thunderer.cnchost.com) [207.155.252.72] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OQOt-00070N-00; Mon, 14 Aug 2000 13:00:00 -0700 Received: from gamze ([170.1.221.62]) by thunderer.cnchost.com id PAA22733; Mon, 14 Aug 2000 15:59:39 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Message-ID: <04ae01c0062a$964e97a0$8b00a8c0@luxxon.com> From: "Gamze Seckin" To: "Dorgham Sisalem" , "Thomas Marshall Eubanks" Cc: References: Subject: Re: New congestion control text in RTP spec Date: Mon, 14 Aug 2000 13:02:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 I don't think this discussion is to talk about disadvantages of TCP..and surely TCP will be around for some time.. Since a congestion ctrl section is to be added to the RTP draft I guees it is a good point to clarify RTP's assertiveness... I also think that RTP congestion control should be more aggressive and not bound by TCP performance. I am sure many people are interested in this discussion. but in case you decide to continue off-line please do include my email.. Thanks, gamze ================= Gamze Seckin, Ph.D. Research Engineer, Luxxon Corporation (408) 573 8400x218 www.luxxon.com ----- Original Message ----- From: Dorgham Sisalem To: Thomas Marshall Eubanks Cc: Dorgham Sisalem ; Sent: Sunday, August 13, 2000 7:35 AM Subject: Re: New congestion control text in RTP spec > > > > It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ? > > a network is any part between the sender and receiver that might get > congested > > > A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ? > > TCP might not be the PERFECT system, but I guess this is irrelevant and > there is really no reason in starting a flame war again about if TCP is > good or > bad, it is here and it will stay so I do not see the reason behind this > question > > > Consider the case of the recent Napster flaps, when some colleges found that 80% of > > their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically > > shut it down : > > > so what? > > > 1.) Many TCP sessions are not benign on a local LAN. > > 2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any > > backbone. > UDP based multimedia traffic might not be more than noise comaped to the > TCP part but this is supposed to change > > > 3.) The congestion control implemented was manual intervention. > > > ??? how are we supposed to understand this now? Disabling some kind of > traffic might solve the most serious problems but is not a solution in > itself (web traffic seems to be taking a large share of the bandwidth on > most networks, shoud we just shut it out to save ftp and mail flows??) > > > As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should > > be aggressive, as it is doing what the user has requested. > > > This might be OK if the sum of flows that do that is small relative to the > overall number,as soon as this changes you will get into trouble -or maybe > we can start having different protocol stacks for the LAN and WAN cases > and the user would need to specify what mode to use (:-) > > > Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously > > congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then > > this might be a problem, but NO pre-planned congestion control is likely to fix it, and the network operators > > will have to intervene manually basically no matter what RTP is doing. > > > TCP has done a good job in fixing congestion for ages now so what is the > argument against doing similar things with UDP. This napster example is > not > a very convincing one. so there were too many TCP flows which the > administrators decided to be not very usefull and and that slow down more > important > ones (such as web traffic???), however even under this situation, all > users get some bandwidth. > > > I have had backbone people tell me that, with all of the dark fiber out there, even dozens of "little" 200 kbps or > > 1 mbps muticast streams will be "in the noise" in terms of usage on their backbones. > > I would take them at their word :) > > > > > And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there > > will not be any RTP. It is different from TCP in that regard - no matter what sort > > of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an > > acceptable user experience is pretty small. > > > lots of video compression styles provide for a wide range of adaptation, > and there is lots what one can do with audio as well. > > This discussion is getting too relegious (adapt or not adapt) and I am not > sure the rem-conf list is the right place for that, so unless lots of > other > people would like to join the discussion we should do it directly? > > Regards > > > > From rem-conf Mon Aug 14 13:24:09 2000 From rem-conf-request@es.net Mon Aug 14 13:24:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OQiR-0000bk-00; Mon, 14 Aug 2000 13:20:11 -0700 Received: from dfw7-1.relay.mail.uu.net [199.171.54.106] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OQiQ-0000ba-00; Mon, 14 Aug 2000 13:20:10 -0700 Received: from 21rst-century.com by dfw7sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjcgf06226; Mon, 14 Aug 2000 20:19:56 GMT Message-ID: <39985411.ADDDB63A@21rst-century.com> Date: Mon, 14 Aug 2000 16:18:26 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Gamze Seckin CC: Dorgham Sisalem , rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <04ae01c0062a$964e97a0$8b00a8c0@luxxon.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 Gamze Seckin wrote: > I don't think this discussion is to talk about disadvantages of TCP..and > surely TCP will be around for some time.. > Since a congestion ctrl section is to be added to the RTP draft I guees it > is a good point to clarify RTP's assertiveness... > I also think that RTP congestion control should be more aggressive and not > bound by TCP performance. > I am sure many people are interested in this discussion. but in case you > decide to continue off-line please do include my email.. > > Thanks, > gamze > > ================= > Gamze Seckin, Ph.D. > Research Engineer, Luxxon Corporation > (408) 573 8400x218 > www.luxxon.com > I have nothing against TCP - it developed over many years and is probably THE best congestion control algorithm in massive use today. I just don't think that it is too appropriate a paradigm for large scale multicasting with receiver based congestion control, and the draft as it stands worries me. I think that the draft should be inclusive in its approach to congestion control. I believe that TCP was around for about 8 years before there was any congestion control, and then it was a near crisis that mandated it. I do not think the RTP will solve all of its congestion control problems just out of the box :) 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Mon Aug 14 13:44:48 2000 From rem-conf-request@es.net Mon Aug 14 13:44:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OR2a-0001bC-00; Mon, 14 Aug 2000 13:41:00 -0700 Received: from wodc7-1.corprelay.mail.uu.net [192.48.96.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OR2Y-0001b2-00; Mon, 14 Aug 2000 13:40:59 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQjcgg28394 for ; Mon, 14 Aug 2000 20:40:58 GMT Received: by neserve0.corp.us.uu.net id QQjcgg04784 for rem-conf@es.net; Mon, 14 Aug 2000 16:40:56 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: need IEEE/1394 to USB conversion To: rem-conf@es.net Date: Mon, 14 Aug 2000 16:40:56 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I am purchasing a video camera that has a IEEE/1394 port on it, however, my machines all have USB on them, including my laptop. What solutions do I have? _J From rem-conf Mon Aug 14 14:25:59 2000 From rem-conf-request@es.net Mon Aug 14 14:25:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ORfk-00030G-00; Mon, 14 Aug 2000 14:21:28 -0700 Received: from (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ORfj-0002zO-00; Mon, 14 Aug 2000 14:21:27 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Aug 2000 14:20:27 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B141766C@HAPPY> From: Bill Nowicki To: "'jhall@UU.NET'" , rem-conf@es.net Subject: RE: need IEEE/1394 to USB conversion Date: Mon, 14 Aug 2000 14:20:26 -0700 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 > I am purchasing a video camera that has a IEEE/1394 port on it, however, > my machines all have USB on them, including my laptop. My guess would be that your 1394 camera uses the "DV" video format, IEC standard 61883, which needs about 30 Mbits per second of bandwidth. So getting it through a USB port that is only 12 Mbits per second will not work. Yes, I know a faster USB 2.0 has been announced, but probably not what you have. I would suggest: use USB for still cameras, and 1394 for video. So if you want to use a still camera, return it for a USB one. If you want video, buy a $50 1394 adapter (more of course for laptops) or get a computer that has 1394 on it. Sony calls it "i.Link", Apple, "FireWire". From rem-conf Mon Aug 14 14:30:19 2000 From rem-conf-request@es.net Mon Aug 14 14:30:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ORkk-0003DC-00; Mon, 14 Aug 2000 14:26:38 -0700 Received: from wodc7-1.relay.mail.uu.net [199.171.54.114] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ORkj-0003CY-00; Mon, 14 Aug 2000 14:26:37 -0700 Received: from 21rst-century.com by wodc7mr0.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjcgj24575; Mon, 14 Aug 2000 21:26:36 GMT Message-ID: <399863B2.E7B0B62D@21rst-century.com> Date: Mon, 14 Aug 2000 17:25:06 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeremy Hall CC: rem-conf@es.net Subject: Re: need IEEE/1394 to USB conversion References: 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 Jeremy Hall wrote: > Hello, > > I am purchasing a video camera that has a IEEE/1394 port on it, however, > my machines all have USB on them, including my laptop. > > What solutions do I have? > > _J Hi Jeremy; IEEE 1394 is Firewire. So, you could buy a Mac. The new iMacs are cheap and good looking, and I believe even the cheapest support Firewire - I know all our G4's do. (Sorry, I couldn't resist :) 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Mon Aug 14 14:33:18 2000 From rem-conf-request@es.net Mon Aug 14 14:33:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ORo1-0003ZR-00; Mon, 14 Aug 2000 14:30:01 -0700 Received: from wodc7-1.relay.mail.uu.net [199.171.54.114] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ORnz-0003Yr-00; Mon, 14 Aug 2000 14:29:59 -0700 Received: from 21rst-century.com by wodc7mr0.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjcgj27289; Mon, 14 Aug 2000 21:29:58 GMT Message-ID: <3998647C.D724EA46@21rst-century.com> Date: Mon, 14 Aug 2000 17:28:28 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeremy Hall CC: rem-conf@es.net Subject: Re: need IEEE/1394 to USB conversion References: 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 Jeremy Hall wrote: > Hello, > > I am purchasing a video camera that has a IEEE/1394 port on it, however, > my machines all have USB on them, including my laptop. > > What solutions do I have? > > _J Or you could buy a 1394 firewire PCI card for most PC's... -- 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Mon Aug 14 14:44:56 2000 From rem-conf-request@es.net Mon Aug 14 14:44:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ORz5-0005mW-00; Mon, 14 Aug 2000 14:41:27 -0700 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ORz3-0005mM-00; Mon, 14 Aug 2000 14:41:25 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQjcgk00020; Mon, 14 Aug 2000 21:41:25 GMT Received: by neserve0.corp.us.uu.net id QQjcgk11915; Mon, 14 Aug 2000 17:41:24 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: need IEEE/1394 to USB conversion In-Reply-To: <3998647C.D724EA46@21rst-century.com> from Thomas Marshall Eubanks at "Aug 14, 2000 05:28:28 pm" To: tme@21rst-century.com Date: Mon, 14 Aug 2000 17:41:24 -0400 (EDT) CC: Jeremy Hall , rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list but that doesn't help me on the road. :) _J In the new year, Thomas Marshall Eubanks wrote: > Jeremy Hall wrote: > > > Hello, > > > > I am purchasing a video camera that has a IEEE/1394 port on it, however, > > my machines all have USB on them, including my laptop. > > > > What solutions do I have? > > > > _J > > Or you could buy a 1394 firewire PCI card for most PC's... > > > -- > 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@on-the-i.com tme@multicasttech.com > > http://www.on-the-i.com http://www.buzzwaves.com > > From rem-conf Mon Aug 14 14:46:53 2000 From rem-conf-request@es.net Mon Aug 14 14:46:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OS1J-0005nS-00; Mon, 14 Aug 2000 14:43:45 -0700 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OS1I-0005nD-00; Mon, 14 Aug 2000 14:43:44 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQjcgk04457; Mon, 14 Aug 2000 21:43:43 GMT Received: by neserve0.corp.us.uu.net id QQjcgk12795; Mon, 14 Aug 2000 17:43:31 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: need IEEE/1394 to USB conversion In-Reply-To: <399863B2.E7B0B62D@21rst-century.com> from Thomas Marshall Eubanks at "Aug 14, 2000 05:25:06 pm" To: tme@21rst-century.com Date: Mon, 14 Aug 2000 17:43:31 -0400 (EDT) CC: Jeremy Hall , rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list uh huh, but they don't talk and probably don't run linux well. _J In the new year, Thomas Marshall Eubanks wrote: > Jeremy Hall wrote: > > > Hello, > > > > I am purchasing a video camera that has a IEEE/1394 port on it, however, > > my machines all have USB on them, including my laptop. > > > > What solutions do I have? > > > > _J > > Hi Jeremy; > > IEEE 1394 is Firewire. So, you could buy a Mac. The new > iMacs are cheap and good looking, and I believe even the cheapest support > Firewire - I know all our G4's do. > > (Sorry, I couldn't resist :) > > 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@on-the-i.com tme@multicasttech.com > > http://www.on-the-i.com http://www.buzzwaves.com > > > From rem-conf Mon Aug 14 15:10:14 2000 From rem-conf-request@es.net Mon Aug 14 15:10:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OSNF-0007kF-00; Mon, 14 Aug 2000 15:06:25 -0700 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OSND-0007k5-00; Mon, 14 Aug 2000 15:06:24 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQjcgm16637; Mon, 14 Aug 2000 22:06:22 GMT Received: by neserve0.corp.us.uu.net id QQjcgm21680; Mon, 14 Aug 2000 18:06:18 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: need IEEE/1394 to USB conversion In-Reply-To: <03AB3CB11CBED3118A4F009027B0C2B141766C@HAPPY> from Bill Nowicki at "Aug 14, 2000 02:20:26 pm" To: Bill Nowicki Date: Mon, 14 Aug 2000 18:06:17 -0400 (EDT) CC: "'jhall@UU.NET'" , rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hmm I don't know how to interpret the output of this. 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:02.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:02.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:02.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:02.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) looks like the controller is USB version1. _J In the new year, Bill Nowicki wrote: > > I am purchasing a video camera that has a IEEE/1394 port on it, however, > > my machines all have USB on them, including my laptop. > > My guess would be that your 1394 camera uses the "DV" video format, IEC > standard 61883, which needs about 30 Mbits per second of bandwidth. So > getting it through a USB port that is only 12 Mbits per second will not > work. Yes, I know a faster USB 2.0 has been announced, but probably not what > you have. I would suggest: use USB for still cameras, and 1394 for video. So > if you want to use a still camera, return it for a USB one. If you want > video, buy a $50 1394 adapter (more of course for laptops) or get a computer > that has 1394 on it. Sony calls it "i.Link", Apple, "FireWire". > From rem-conf Mon Aug 14 15:41:09 2000 From rem-conf-request@es.net Mon Aug 14 15:41:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OSqg-0001BE-00; Mon, 14 Aug 2000 15:36:50 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OSqf-0001B3-00; Mon, 14 Aug 2000 15:36:49 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA06329 for ; Mon, 14 Aug 2000 15:36:47 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 14 Aug 2000 15:36:47 -0700 Received: from marks4 (marks4.apple.com [17.202.33.223]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id PAA07543; Mon, 14 Aug 2000 15:36:47 -0700 (PDT) Message-Id: <200008142236.PAA07543@scv2.apple.com> Date: Mon, 14 Aug 2000 15:36:45 -0700 From: Kevin Marks Content-Type: text/plain; charset=us-ascii X-Mailer: Apple Mail (2.328.2) Cc: tme@21rst-century.com, rem-conf@es.net To: jhall@UU.NET (Jeremy Hall) Mime-Version: 1.0 (Apple Message framework v328.2) Content-Transfer-Encoding: quoted-printable Subject: Re: need IEEE/1394 to USB conversion X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Monday, August 14, 2000, at 02:43 PM, Jeremy Hall wrote: > uh huh, but they don't talk and probably don't run linux well.=20 What do you mean they don't talk? The Mac has had text-to-speech for 16 = years... There are several Linux distributions for the Mac, but whether anyone = has written firewire drivers and DV decompressors I don't know.=20 try http://www.linuxppc.com/ The iMacs ship with iMovie and QT on, so you can capture video and = transcode it to RTP-compliant media with ease. >but that doesn't help me on the road. :) So buy a PowerBook instead. FireWire built in. There are PCMCIA FireWire = cards available for Macs; I assume there are some for Wintel too. Some = of the newer Sony Vaio's have FireWire built-in too. > In the new year, Thomas Marshall Eubanks wrote:=20 > > iMacs are cheap and good looking, and I believe even the cheapest = support=20 > > Firewire - I know all our G4's do.=20 All the currently available ones do - the $799 one available from = September doesn't.= From rem-conf Mon Aug 14 15:43:13 2000 From rem-conf-request@es.net Mon Aug 14 15:43:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OStQ-0001Cm-00; Mon, 14 Aug 2000 15:39:40 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OStP-0001Cc-00; Mon, 14 Aug 2000 15:39:39 -0700 Received: from mailgate2.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 PAA25710 for ; Mon, 14 Aug 2000 15:39:37 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Mon, 14 Aug 2000 15:39:37 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id PAA00695; Mon, 14 Aug 2000 15:39:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 14 Aug 2000 15:39:27 -0700 To: jhall@UU.NET (Jeremy Hall) From: Dave Singer Subject: Re: need IEEE/1394 to USB conversion 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 5:43 PM -0400 8/14/00, Jeremy Hall wrote: >uh huh, but they don't talk and probably don't run linux well. > >_J LinuxPPC isn't too bad... but you don't say what you want to do beyond electrical connectivity. Your laptop can probably take a cardbus firewire card (I have one >from Newertech, VST has one also, I'm sure there are more). But do they integrate with your OS, your video editing system, your live broadcaster, or whatever? Gotta climb those 7 layers and make sure you get connectivity up to the layer you care about. > >In the new year, Thomas Marshall Eubanks wrote: >> Jeremy Hall wrote: >> >> > Hello, >> > >> > I am purchasing a video camera that has a IEEE/1394 port on it, however, >> > my machines all have USB on them, including my laptop. >> > >> > What solutions do I have? >> > >> > _J >> >> Hi Jeremy; >> >> IEEE 1394 is Firewire. So, you could buy a Mac. The new >> iMacs are cheap and good looking, and I believe even the cheapest support >> Firewire - I know all our G4's do. >> >> (Sorry, I couldn't resist :) >> >> 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@on-the-i.com tme@multicasttech.com > > > > http://www.on-the-i.com http://www.buzzwaves.com > > > > > > -- David Singer Apple Computer/QuickTime From rem-conf Mon Aug 14 16:04:06 2000 From rem-conf-request@es.net Mon Aug 14 16:04:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OTDG-0002xO-00; Mon, 14 Aug 2000 16:00:10 -0700 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OTDF-0002xE-00; Mon, 14 Aug 2000 16:00:09 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQjcgq00747; Mon, 14 Aug 2000 23:00:08 GMT Received: by neserve0.corp.us.uu.net id QQjcgq19009; Mon, 14 Aug 2000 19:00:06 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: need IEEE/1394 to USB conversion In-Reply-To: from Dave Singer at "Aug 14, 2000 03:39:27 pm" To: Dave Singer Date: Mon, 14 Aug 2000 19:00:06 -0400 (EDT) CC: Jeremy Hall , rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list yeah well I'm going for a solution under Linux. That pretty much limits me right there. I haven't fully studied the video4linux materials, but I'm certain that given time, a solution will work if it doesn't already. _J In the new year, Dave Singer wrote: > At 5:43 PM -0400 8/14/00, Jeremy Hall wrote: > >uh huh, but they don't talk and probably don't run linux well. > > > >_J > > LinuxPPC isn't too bad... > > but you don't say what you want to do beyond electrical connectivity. > Your laptop can probably take a cardbus firewire card (I have one > from Newertech, VST has one also, I'm sure there are more). But do > they integrate with your OS, your video editing system, your live > broadcaster, or whatever? Gotta climb those 7 layers and make sure > you get connectivity up to the layer you care about. > > > >In the new year, Thomas Marshall Eubanks wrote: > >> Jeremy Hall wrote: > >> > >> > Hello, > >> > > >> > I am purchasing a video camera that has a IEEE/1394 port on it, however, > >> > my machines all have USB on them, including my laptop. > >> > > >> > What solutions do I have? > >> > > >> > _J > >> > >> Hi Jeremy; > >> > >> IEEE 1394 is Firewire. So, you could buy a Mac. The new > >> iMacs are cheap and good looking, and I believe even the cheapest support > >> Firewire - I know all our G4's do. > >> > >> (Sorry, I couldn't resist :) > >> > >> 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@on-the-i.com tme@multicasttech.com > > > > > > http://www.on-the-i.com http://www.buzzwaves.com > > > > > > > > > > > -- > David Singer > Apple Computer/QuickTime > From rem-conf Tue Aug 15 04:08:57 2000 From rem-conf-request@es.net Tue Aug 15 04:08:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OeK4-000311-00; Tue, 15 Aug 2000 03:51:56 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OeK2-00030r-00; Tue, 15 Aug 2000 03:51:54 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10432; Tue, 15 Aug 2000 06:51:52 -0400 (EDT) Message-Id: <200008151051.GAA10432@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-00.txt Date: Tue, 15 Aug 2000 06:51:52 -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 for AMR Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt Filename : draft-ietf-avt-rtp-amr-00.txt Pages : 17 Date : 14-Aug-00 This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-00.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-00.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-00.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: <20000814114414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000814114414.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Aug 15 08:21:07 2000 From rem-conf-request@es.net Tue Aug 15 08:21:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OiNo-0006eL-00; Tue, 15 Aug 2000 08:12:04 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OiNm-0006eB-00; Tue, 15 Aug 2000 08:12:03 -0700 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA14717; Tue, 15 Aug 2000 17:11:50 +0200 (MET DST) Message-Id: <200008151511.RAA14717@mailhub.fokus.gmd.de> X-Mailer: exmh version 1.6.7 5/3/96 To: "Gamze Seckin" cc: "Thomas Marshall Eubanks" , rem-conf@es.net Subject: Re: New congestion control text in RTP spec In-reply-to: Your message of "Mon, 14 Aug 2000 13:02:33 PDT." <04ae01c0062a$964e97a0$8b00a8c0@luxxon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Aug 2000 17:11:49 +0200 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I don't think this discussion is to talk about disadvantages of TCP..and > surely TCP will be around for some time.. well that is what I wanted to avoid > Since a congestion ctrl section is to be added to the RTP draft I guees it > is a good point to clarify RTP's assertiveness... sure > I also think that RTP congestion control should be more aggressive and not > bound by TCP performance. What I was trying to imply in my text suggestion is that one should try to specify a congestion control behavior that takes the applications needs as well as the networks state in consideration and not merely the network state (loss and delay) as is currently the case for most congestion control schemes (and certainly for TCP) or the applications needs as Thomas was suggesting. Such a control behavior should on the one hand lead to a smooth perceived QoS and should not result in starving competing flows. Regards Dorgham > I am sure many people are interested in this discussion. but in case you > decide to continue off-line please do include my email.. > > Thanks, > gamze > > ================= > Gamze Seckin, Ph.D. > Research Engineer, Luxxon Corporation > (408) 573 8400x218 > www.luxxon.com > > ----- Original Message ----- > From: Dorgham Sisalem > To: Thomas Marshall Eubanks > Cc: Dorgham Sisalem ; > Sent: Sunday, August 13, 2000 7:35 AM > Subject: Re: New congestion control text in RTP spec > > > > > > > > It used to be, Internet eons ago. Is it now ? Is it likely to be in the > near future ? And what do you mean by "the network" ? > > > > a network is any part between the sender and receiver that might get > > congested > > > > > A local LAN, or a backbone ? And is a TCP system really the best on the > local LAN ? > > > > TCP might not be the PERFECT system, but I guess this is irrelevant and > > there is really no reason in starting a flame war again about if TCP is > > good or > > bad, it is here and it will stay so I do not see the reason behind this > > question > > > > > Consider the case of the recent Napster flaps, when some colleges found > that 80% of > > > their in-bound traffic was taken over by many Napster TCP sessions, and > had to specifically > > > shut it down : > > > > > so what? > > > > > 1.) Many TCP sessions are not benign on a local LAN. > > > 2.) I heard of NO (as in ZERO) reports of all of this traffic being a > problem on any > > > backbone. > > UDP based multimedia traffic might not be more than noise comaped to the > > TCP part but this is supposed to change > > > > > 3.) The congestion control implemented was manual intervention. > > > > > ??? how are we supposed to understand this now? Disabling some kind of > > traffic might solve the most serious problems but is not a solution in > > itself (web traffic seems to be taking a large share of the bandwidth on > > most networks, shoud we just shut it out to save ftp and mail flows??) > > > > > As I said before, if the local net is just whatever the user doing this > side of a DSLAM, RTP should > > > be aggressive, as it is doing what the user has requested. > > > > > This might be OK if the sum of flows that do that is small relative to the > > overall number,as soon as this changes you will get into trouble -or maybe > > we can start having different protocol stacks for the LAN and WAN cases > > and the user would need to specify what mode to use (:-) > > > > > Consider a college type situation. A few RTP multicast streams of audio > or low quality video will not seriously > > > congest even a 100 mbps Ethernet. If every student decides to listen to > a different station, then > > > this might be a problem, but NO pre-planned congestion control is likely > to fix it, and the network operators > > > will have to intervene manually basically no matter what RTP is doing. > > > > > TCP has done a good job in fixing congestion for ages now so what is the > > argument against doing similar things with UDP. This napster example is > > not > > a very convincing one. so there were too many TCP flows which the > > administrators decided to be not very usefull and and that slow down more > > important > > ones (such as web traffic???), however even under this situation, all > > users get some bandwidth. > > > > > I have had backbone people tell me that, with all of the dark fiber out > there, even dozens of "little" 200 kbps or > > > 1 mbps muticast streams will be "in the noise" in terms of usage on > their backbones. > > > I would take them at their word :) > > > > > > > > And finally, RTP should be "user-centric" This is not a dirty word. If > there are no users, there > > > will not be any RTP. It is different from TCP in that regard - no matter > what sort > > > of layering you are doing, the dynamic range in bandwidth over which RTP > can still provide an > > > acceptable user experience is pretty small. > > > > > lots of video compression styles provide for a wide range of adaptation, > > and there is lots what one can do with audio as well. > > > > This discussion is getting too relegious (adapt or not adapt) and I am not > > sure the rem-conf list is the right place for that, so unless lots of > > other > > people would like to join the discussion we should do it directly? > > > > Regards > > > > > > > > > > From rem-conf Tue Aug 15 09:18:30 2000 From rem-conf-request@es.net Tue Aug 15 09:18:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OjLT-0000Vq-00; Tue, 15 Aug 2000 09:13:43 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OjLR-0000Vg-00; Tue, 15 Aug 2000 09:13:41 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e7FGDKE03369; Tue, 15 Aug 2000 18:13:20 +0200 (MET DST) From: "Dr. Carsten Bormann" To: , "Dorgham Sisalem" Cc: Subject: RE: New congestion control text in RTP spec Date: Tue, 15 Aug 2000 18:13:19 +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) In-reply-to: <39943E11.F2FF5311@21rst-century.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There are two kinds of congestion control, which could be > loosely called on the backbone, and > at the receiver. TCP needs to worry about both, as it will seize > ALL of the bandwidth it can. Actually, it does not have the foggiest idea which of these two it is worrying about... > I would strongly argue that multicast RTP/UDP mostly needs to > worry about the receiver congestion > problem. You have to consider fairness in the highly statistically multiplexed backbone as well as fairness in the lo-stat-mux links *that aren't entirely yours*! The only links where the kind of control you are hinting at might work are the ones where all competing flows are your own flows. I don't think we have a way to handle these differently (or even know they are there)... > I would strongly argue that if I'm watching a video > (say) and start an FTP session or > click on a web site button, that I do NOT in general want my TV > picture to degrade or disappear. How does the TCP flow emanating from the FTP server know that it should not compete with your RTP stream? (Actually, how does it know *that* its bottleneck is caused by competing with it?) I think something like ECM, but receiver-oriented, could help in the case that you are receiving multiple flows that you want to compete in a specific way. (In the example, the FTP client's TCP stack could control its window updates such that it throttles the FTP server's TCP just right.) I just don't think we know how to do this. Gruesse, Carsten From rem-conf Tue Aug 15 09:37:36 2000 From rem-conf-request@es.net Tue Aug 15 09:37:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OjeO-0001Nr-00; Tue, 15 Aug 2000 09:33:16 -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 13OjeM-0001Nh-00; Tue, 15 Aug 2000 09:33:14 -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 0A06C1E038; Tue, 15 Aug 2000 12:33:10 -0400 (EDT) Received: from VTPC3 (mtjukebox [135.207.130.81]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id MAA04872; Tue, 15 Aug 2000 12:33:06 -0400 (EDT) Message-ID: <006701c006d6$c19e02e0$5182cf87@VTPC3> From: "M. Reha Civanlar" To: "Stephen Casner" , References: Subject: Re: New congestion control text in RTP spec Date: Tue, 15 Aug 2000 12:34:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Steve, "If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput that is not less the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high." I have a few questions about the above quotation from the profile document. First, in practice, how does an RTP end-point determine the "average throughput" of a TCP flow "across the same network path and experiencing the same network conditions"? If you (authors) have a particular reference for this in your mind, shouldn't it be at least specified here? Second, what is the time period over which this "average" is to be computed? Thanks. M. Reha Civanlar ----- Original Message ----- From: "Stephen Casner" To: Sent: Monday, July 31, 2000 10:39 AM Subject: New congestion control text in RTP spec > To the AVT working group: > > I'd like to call your attention, for both those who are here at IETF > and those who are not, to the new sections on congestion control that > were added to the recent revisions of the RTP spec and profile drafts > as a result of the discussion at the last IETF: > > draft-ietf-avt-rtp-new-08.txt / .ps > draft-ietf-avt-profile-new-09.txt / .ps > > In the RTP spec, the congestion control discussion is in a new Section > 10, with references in Sections 6 and 13. It simply establishes the > requirement for congestion control in RTP, and defers definition of > any specific behaviors to profiles because they are context-specific. > > In the profile, a new "Congestion" item was added in Section 2 using > the text that Mark Handley provided in response to my request at the > last IETF meeting. Again, the requirements are described only in > general terms because specific algorithms have not been devised yet > for multicast congestion control. > > ---> Is this text in both documents appropriate and sufficient? > > -- Steve > > > From rem-conf Tue Aug 15 10:02:48 2000 From rem-conf-request@es.net Tue Aug 15 10:02:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ok2h-0002Nf-00; Tue, 15 Aug 2000 09:58:23 -0700 Received: from newdev.eecs.harvard.edu (newdev.harvard.edu) [140.247.60.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ok2f-0002NL-00; Tue, 15 Aug 2000 09:58:21 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id MAA00445 for rem-conf@es.net; Tue, 15 Aug 2000 12:56:29 -0400 (EDT) Date: Tue, 15 Aug 2000 12:56:29 -0400 (EDT) From: Scott Bradner Message-Id: <200008151656.MAA00445@newdev.harvard.edu> To: rem-conf@es.net Subject: Re: New congestion control text in RTP spec X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > What I was trying to imply in my text suggestion is that one should try > to specify a congestion control behavior that takes the applications > needs as well as the networks state in consideration and not merely the > network state (loss and delay) as is currently the case for most > congestion control schemes (and certainly for TCP) or the applications > needs as Thomas was suggesting > > Such a control behavior should on the one hand lead to a smooth > perceived QoS and should not result in starving competing flows. the IESG will look very hard at any proposal that does not protect the network from congestive collapse and do so in a way that does not unfairly harm the other traffic on the network Scott From rem-conf Tue Aug 15 10:30:00 2000 From rem-conf-request@es.net Tue Aug 15 10:29:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OkON-0003KV-00; Tue, 15 Aug 2000 10:20:47 -0700 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net (hazard.aciri.org) [63.196.11.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OkOM-0003KL-00; Tue, 15 Aug 2000 10:20:46 -0700 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id KAA85249; Tue, 15 Aug 2000 10:20:24 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: "M. Reha Civanlar" cc: "Stephen Casner" , rem-conf@es.net Subject: Re: New congestion control text in RTP spec In-reply-to: Your message of "Tue, 15 Aug 2000 12:34:58 EDT." <006701c006d6$c19e02e0$5182cf87@VTPC3> Date: Tue, 15 Aug 2000 10:20:24 -0700 Message-ID: <85247.966360024@hazard.aciri.org> Sender: mjh@hazard.aciri.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > "If best-effort service is being used, RTP receivers SHOULD > monitor packet loss to ensure that the packet loss rate is > within acceptable parameters. Packet loss is considered > acceptable if a TCP flow across the same network path and > experiencing the same network conditions would achieve an > average throughput that is not less the RTP flow is > achieving. This condition can be satisfied by implementing > congestion control mechanisms to adapt the transmission > rate (or the number of layers subscribed for a layered > multicast session), or by arranging for a receiver to leave > the session if the loss rate is unacceptably high." > >I have a few questions about the above quotation from the profile document. >First, in practice, how does an RTP end-point determine the "average >throughput" of a TCP flow "across the same network path and experiencing the >same network conditions"? If you (authors) have a particular reference for >this in your mind, shouldn't it be at least specified here? Second, what is >the time period over which this "average" is to be computed? Given that I think this was a paragraph that I wrote, perhaps I should respond. - The text represented what I thought was the consensus of people in the meeting room in Adelaide. Ie, that it's the job of the RTP spec to say that best-effort applications should do congestion control, but not the job of the RTP spec to give the precise details of how this congestion control should be done. This is the normal IETF way of doing things - decouple functionality as far as possible. - The average should be computed over a sufficiently long time period to be useful to the application and a sufficiently short period to respond to real changes in network congestion and prevent congestion collapse or starvation of competing TCP traffic. Only experience of deploying new congestion control techniques in the real world can tell us what these bounds are (although simulations give us a rough idea). Again this isn't RTP-specific so shouldn't be in the RTP spec. - I was thinking of TFRC (http://www.aciri.org/tfrc) when I wrote the text. But I don't think the IETF wants to *mandate* this particular scheme for RTP congestion control. BTW, we do intend to write up an internet-draft on TFRC sometime soon. Cheers, Mark From rem-conf Tue Aug 15 10:30:00 2000 From rem-conf-request@es.net Tue Aug 15 10:29:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OkOI-0003KJ-00; Tue, 15 Aug 2000 10:20:42 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13OkOG-0003K7-00; Tue, 15 Aug 2000 10:20:40 -0700 Received: from [209.8.42.105] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 520469; Tue, 15 Aug 2000 13:25:11 -0400 Message-ID: <39997CC5.1EE83B12@21rst-century.com> Date: Tue, 15 Aug 2000 13:24:21 -0400 From: Thomas 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: Dorgham Sisalem CC: Gamze Seckin , rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <200008151511.RAA14717@mailhub.fokus.gmd.de> 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 Dorgham Sisalem wrote: > > What I was trying to imply in my text suggestion is that one should try > to specify a congestion control behavior that takes the applications > needs as well as the networks state in consideration and not merely the > network state (loss and delay) as is currently the case for most > congestion control schemes (and certainly for TCP) or the applications > needs as Thomas was suggesting. > Such a control behavior should on the one hand lead to a smooth > perceived QoS and should not result in starving competing flows. > > Regards > Dorgham > > That was not quite what I got from the text. I am pretty much in full agreement with this interpretation. 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Tue Aug 15 10:31:33 2000 From rem-conf-request@es.net Tue Aug 15 10:31:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OkVh-0003Ng-00; Tue, 15 Aug 2000 10:28:21 -0700 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net (hazard.aciri.org) [63.196.11.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OkVe-0003NM-00; Tue, 15 Aug 2000 10:28:19 -0700 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id KAA85359; Tue, 15 Aug 2000 10:27:45 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: tme@21rst-century.com cc: Dorgham Sisalem , cabo@tzi.org, rem-conf@es.net Subject: Re: New congestion control text in RTP spec In-reply-to: Your message of "Fri, 11 Aug 2000 13:55:31 EDT." <39943E11.F2FF5311@21rst-century.com> Date: Tue, 15 Aug 2000 10:27:45 -0700 Message-ID: <85357.966360465@hazard.aciri.org> Sender: mjh@hazard.aciri.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Also consider the zeroconf home network case, which I think in the long run > will dominate the use of these >services. is at home listening to an >Internet radio using multicast >RTP over a home LAN. The TV remote control (say) starts its daily automatic d >ownload >of the latest channel guide using TCP. The radio reception gets progressively >worse over a 5 minute >period. My mother concludes the radio is defective, and throws it >out. Is that really what we want ? However if your mother is listening to a radio show being streamed over HTTP (as many people currently do) and you suddently start listening to your RTP multicast session, your mother will still throw the radio out. The point is that you can't decide which traffic needs priority from the transport protocol it's using. If you need to make value judgements and differentiate between traffic flows, you need to use differentiated services (or reservations) to do it. You don't want to engineer those value judgements into the congestion control mechanisms for a particular transport protocol. Cheers, Mark From rem-conf Tue Aug 15 10:42:35 2000 From rem-conf-request@es.net Tue Aug 15 10:42:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Okes-0004Mn-00; Tue, 15 Aug 2000 10:37:50 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Oker-0004MY-00; Tue, 15 Aug 2000 10:37:49 -0700 Received: from [209.8.42.105] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 520477; Tue, 15 Aug 2000 13:42:30 -0400 Message-ID: <399980D8.1E16F5F4@21rst-century.com> Date: Tue, 15 Aug 2000 13:41:45 -0400 From: Thomas 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: "Dr. Carsten Bormann" CC: Dorgham Sisalem , rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: 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 "Dr. Carsten Bormann" wrote: > > There are two kinds of congestion control, which could be > > loosely called on the backbone, and > > at the receiver. TCP needs to worry about both, as it will seize > > ALL of the bandwidth it can. > > Actually, it does not have the foggiest idea which of these two it is > worrying about... > Nor should it... > > > I would strongly argue that multicast RTP/UDP mostly needs to > > worry about the receiver congestion > > problem. > > You have to consider fairness in the highly statistically multiplexed > backbone as well as fairness in the lo-stat-mux links *that aren't entirely > yours*! > The only links where the kind of control you are hinting at might work are > the ones where all competing flows are your own flows. > I don't think we have a way to handle these differently (or even know they > are there)... > I say, try a simple minded receiver based congestion control first, and see if it works or leads to problems. I think that in practice even an aggressive RTP would not cause many problems; we shall see. There isn't enough of it at present to break the Internet, that's for sure. > > > I would strongly argue that if I'm watching a video > > (say) and start an FTP session or > > click on a web site button, that I do NOT in general want my TV > > picture to degrade or disappear. > > How does the TCP flow emanating from the FTP server know that it should not > compete with your RTP stream? It won't. It doesn't have to, nor, really, should it. I have two cats. One eats more or less a fixed amount, the other eats everything put in front of it and then the other cat's and then goes hunting for more. The first cat has to be somewhat aggressive to get anything to eat at all, so it is. Although this is a true story, I could just as well rename these cats RTP and TCP. > > (Actually, how does it know *that* its bottleneck is caused by competing > with it?) > > I think something like ECM, but receiver-oriented, could help in the case > that you are receiving multiple flows that you want to compete in a specific > way. > (In the example, the FTP client's TCP stack could control its window updates > such that it throttles the FTP server's TCP just right.) > I just don't think we know how to do this. > Is ECM deployed anywhere ? Multicasting is hardly deployed at all now. Maybe SSM will help, but to ask it to wait for something further will probably kill it commercially. > > Gruesse, Carsten I would remind people that we are discussing the profile draft text on congestion control, which I regard as flatly unacceptable and likely to be never honored by large scale broadcasters. I suggested an "aggressive" receiver based alternative. Maybe a compromise would be to just leave it as "If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters." followed by "Congestion control MAY be implemented through congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), but in any case receivers SHOULD to leave the session if the loss rate is unacceptably high." Which fudges the definition of "acceptable", which is probably correct at this point. 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Tue Aug 15 11:49:18 2000 From rem-conf-request@es.net Tue Aug 15 11:49:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Olh2-000763-00; Tue, 15 Aug 2000 11:44:08 -0700 Received: from lafontaine.cybercable.fr [212.198.0.202] by mail1.es.net with smtp (Exim 1.81 #2) id 13Olh0-00075t-00; Tue, 15 Aug 2000 11:44:07 -0700 Received: (qmail 1926551 invoked from network); 15 Aug 2000 18:44:01 -0000 Received: from r209m110.cybercable.tm.fr (HELO kav) ([195.132.209.110]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 15 Aug 2000 18:44:01 -0000 Message-ID: <005c01c006e8$421dc340$0100a2c6@cybercable.fr> From: =?iso-8859-1?Q?Kav=E9_Salamatian?= To: , "rem-conf" , "Dorgham Sisalem" References: <200008151511.RAA14717@mailhub.fokus.gmd.de> <39997CC5.1EE83B12@21rst-century.com> Subject: Re: New congestion control text in RTP spec Date: Tue, 15 Aug 2000 20:40:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: =?iso-8859-1?Q?Kav=E9_Salamatian?= X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello everybody, Sorry for introducing myself in this interesting discussion. But I have two ingenous question: 1- What is network state ?????? 2- What is application needs ????? I know the answer to this two question is very difficult but I think that if we can at least understand where is the difficulty we will have make a step further. Some remarks about the first question. This question is in fact a fundamental question in IPPM framework. What is a good IP Performance measure ?? The network state is, I think, an abstract hidden variable, that cannot be seen directly by any end user. End users see only its reflect, loss, delay, etc .... The problem is about how to reconstitute the hidden variable (network state) from its noisy observation (loss rate, delay variation, etc). However, to restrict the search domain for the hidden variable we use an underlying model for the network relating observation to the hidden variable. For example in TCP the network is a rigid pipe containing a full TCP window. All the problems of TCP are related to this underlying model assumption. At the other side some multimedia applications need an underlying model of the connection that is similar to a variable valve with varying rate. In my point of view the first question to ask (or to answer) is what is the underlying model we want to use or at least to list the different possible underlying models. Maybe a draft listing different approach will be valuable. The second point is how to transform observation to states in the underlying model. This question was answered in the TCP framework by the well known TCP congestion control (the estimated network state is the TCP window length). It maybe need some work on the other framework. I do not want to enter into technical discussion about this on this list but I will be interested to discuss offline. About the second question I do not think that any generic framework can be developped. Application have too wide spectrum of needs. The meaning of smooth QoS used by Dorgham is particuliar to each application. Afterall I agree with the underlined interpretation of Dorgham, but, in my point of view it does not solve any problem as it is to much general and too much concept need to be defined. Network state ?? Application needs ?? smooth perceived behavior ?? starving competitor flows ?? Regards Kavé Salamatian Assistant Professor, Université Paris VI, Paris France ----- Original Message ----- From: "Thomas Marshall Eubanks" To: "Dorgham Sisalem" Cc: "Gamze Seckin" ; Sent: Tuesday, August 15, 2000 7:24 PM Subject: Re: New congestion control text in RTP spec > Dorgham Sisalem wrote: > > > > > What I was trying to imply in my text suggestion is that one should try > > to specify a congestion control behavior that takes the applications > > needs as well as the networks state in consideration and not merely the > > network state (loss and delay) as is currently the case for most > > congestion control schemes (and certainly for TCP) or the applications > > needs as Thomas was suggesting. > > Such a control behavior should on the one hand lead to a smooth > > perceived QoS and should not result in starving competing flows. > > > > Regards > > Dorgham > > > > > > > That was not quite what I got from the text. I am pretty much in full agreement > with this interpretation. > > > 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@on-the-i.com tme@multicasttech.com > > http://www.on-the-i.com http://www.buzzwaves.com > > From rem-conf Wed Aug 16 02:34:22 2000 From rem-conf-request@es.net Wed Aug 16 02:34:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13OzR7-0006V0-00; Wed, 16 Aug 2000 02:24:37 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13OzR5-0006Up-00; Wed, 16 Aug 2000 02:24:35 -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 ESMTP id e7G9OWw13731 for ; Wed, 16 Aug 2000 11:24:32 +0200 (MEST) Received: from esealnt406.al.sw.ericsson.se ([153.88.251.29]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 16 Aug 2000 11:23:11 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt406.al.sw.ericsson.se (NAVIEG 2.1 bld 61) with SMTP id M2000081609413426845 for ; Wed, 16 Aug 2000 09:41:34 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 16 Aug 2000 09:41:34 +0200 Message-ID: From: "Gert Olsson (ECS)" To: rem-conf@es.net Subject: RTCP interval testing in draft-ietf-avt-rtptest-03.txt Date: Wed, 16 Aug 2000 09:41:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 16 Aug 2000 09:23:11.0843 (UTC) FILETIME=[991E4B30:01C00763] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, just a small question about the RTCP transmission interval testing described in section 2.7.1 ('Basic Behavior') of: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-03.txt I have some problem understanding the last two of the four properties at the top of page 9. If applying the division by (e-3/2), mentioned in the new RTP draft, shouldn't the interval time be uniformly distributed between appr. 2.1 and 6.2 seconds (average appr. 4.1 seconds) ? (If not applying the division, it is prop. 1,2 and 4 that don't make sense to me.) BR, /GO __________________________________________________________________| Gert Olsson / phone: +46 46 23 24 97 / e-mail: gert.olsson@ecs.ericsson.se Ericsson Mobile Communications AB, SE-221 83 Lund, Sweden From rem-conf Wed Aug 16 08:11:50 2000 From rem-conf-request@es.net Wed Aug 16 08:11:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13P4eH-00027k-00; Wed, 16 Aug 2000 07:58:33 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13P4eE-00027a-00; Wed, 16 Aug 2000 07:58:31 -0700 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA09198; Wed, 16 Aug 2000 16:58:14 +0200 (MET DST) Message-Id: <200008161458.QAA09198@mailhub.fokus.gmd.de> X-Mailer: exmh version 1.6.7 5/3/96 To: =?iso-8859-1?Q?Kav=E9_Salamatian?= cc: tme@21rst-century.com, "rem-conf" Subject: Re: New congestion control text in RTP spec In-reply-to: Your message of "Tue, 15 Aug 2000 20:40:17 +0200." <005c01c006e8$421dc340$0100a2c6@cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 16:58:14 +0200 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list salamat@lri.Fr said: > About the second question I do not think that any generic framework > can be developped. Application have too wide spectrum of needs. The > meaning of smooth QoS used by Dorgham is particuliar to each > application. > Afterall I agree with the underlined interpretation of Dorgham, but, > in my point of view it does not solve any problem as it is to much > general and too much concept need to be defined. Network state ?? > Application needs ?? smooth perceived behavior ?? starving competitor > flows ?? I do agree it will very difficult to specify a general application framework (even though we already made an attempt at that, see: ftp://ftp.fokus.gmd.de/pub/step/papers/Sisa0002:Constrained.ps.gz ) Still I believe that the congestion text should not limit itself to this TCP-friendly definition and indicate clearly to the implementor of the congestion control scheme that he/she better take a good look at what the congestion control mechansim is doing to the quality as seen by the user Dorgham From rem-conf Thu Aug 17 00:06:16 2000 From rem-conf-request@es.net Thu Aug 17 00:06:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13PJaA-0002DJ-00; Wed, 16 Aug 2000 23:55:18 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13PJa8-0002D9-00; Wed, 16 Aug 2000 23:55:17 -0700 Received: from dynamicsoft.com (1Cust212.tnt1.freehold.nj.da.uu.net [63.17.113.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28224; Thu, 17 Aug 2000 02:56:44 -0400 (EDT) Message-ID: <399B8DB2.84CD5B12@dynamicsoft.com> Date: Thu, 17 Aug 2000 03:01:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gert Olsson (ECS)" CC: rem-conf@es.net Subject: Re: RTCP interval testing in draft-ietf-avt-rtptest-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Gert Olsson (ECS)" wrote: > > Hi, > just a small question about the RTCP transmission interval testing described in section 2.7.1 ('Basic Behavior') of: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-03.txt > > I have some problem understanding the last two of the four properties at the top of page 9. If applying the division by (e-3/2), mentioned in the new RTP draft, shouldn't the interval time be uniformly distributed between appr. 2.1 and 6.2 seconds (average appr. 4.1 seconds) ? No, it won't. Under static group memberships, the reconsideration algorithm will cause the interval to be distributed *non-uniformly*. This skewed distribution is critical to the operation of the algorithm. The skew also moves up the average interval. The division by e-3/2 helps reduce it again so it remains at the same value as if there were no reconsideration. -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: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Aug 17 04:10:45 2000 From rem-conf-request@es.net Thu Aug 17 04:10:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13PNMd-0004kl-00; Thu, 17 Aug 2000 03:57:35 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13PNMb-0004kb-00; Thu, 17 Aug 2000 03:57:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23227; Thu, 17 Aug 2000 06:57:31 -0400 (EDT) Message-Id: <200008171057.GAA23227@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-lnt-avt-uxp-01.txt Date: Thu, 17 Aug 2000 06:57:31 -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. Title : An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Author(s) : M. Nguyen, G. Liebl, B. Wimmer, F. Burkert, J. Pandel Filename : draft-lnt-avt-uxp-01.txt Pages : 15 Date : 16-Aug-00 This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon codes. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By defining a comparably simple payload format, the proposed scheme can be easily integrated into the existing framework for RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lnt-avt-uxp-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-lnt-avt-uxp-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-lnt-avt-uxp-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: <20000816095123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lnt-avt-uxp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-lnt-avt-uxp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000816095123.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Aug 17 09:18:11 2000 From rem-conf-request@es.net Thu Aug 17 09:18:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13PSA0-0000nf-00; Thu, 17 Aug 2000 09:04:52 -0700 Received: from (smtp.ntech.ac.za) [192.96.145.144] (mail) by mail1.es.net with esmtp (Exim 1.81 #2) id 13PS9w-0000ll-00; Thu, 17 Aug 2000 09:04:49 -0700 Received: from (ee.ntech.ac.za) [192.96.145.49] by smtp.ntech.ac.za with smtp (Exim 2.05 #1 (Debian)) id 13PU2r-0006lh-00; Thu, 17 Aug 2000 20:05:37 +0200 Received: from 9wnlbX6Br ([168.191.246.58]) by ee.ntech.ac.za; Thu, 17 Aug 2000 17:11:17 +0200 DATE: 17 Aug 00 8:32:54 AM FROM: spam_webmaster@omanmail.com Message-ID: <18SBO0eu7m62qCdXW> SUBJECT: Guess Who Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list LET THE WHOLE INTERNET SEE YOUR BUSINESS OR PRODUCT! Are you tired of searching for a stable bulk friendly ISP.... Stop searching! We are your one-stop Bulk mail experts. With all services under one roof. We have the A-Z of the bulk emailing business. Services that we offer: * Bulk Emailing Service Promote your web site by mass emailing. We can break our 85 million plus database by country, state, or by target. Our lists are updated daily and washed twice a week. MASS MAILING PRICES (All Prices include emails) 500,000 EMAILS.............................. $375.00 750,000 EMAILS.............................. $562.00 1,200,000 EMAILS ........................... $720.00 1,600,000 EMAILS............................ $960.00 3,000,000 EMAILS........................... $1500.00 3,000,000 + EMAILS PLEASE CALL FOR QUOTE Order by 12 pm PST mailed that night. We mail 7 days per week. *Bulletproof Dial-up Account - 56K V.90 For all you "do it your selfer's" Promote your site with reliable dial up service 7 days a week 24HRs a day. Stop wasting time and energy burning through ISPs. Triple the number of emails you are sending. 24 hr Set-up. Dial - up pricing 30 days of service $500.00 (unlimited use) one time set-up of $300.00 * Bulletproof Web Hosting Promote your web site as much as you want without the worries of it getting shut down because of spam complaints. Our operation centers are protected by Central Intelligence Agency level security that delivers safety-proof reliability. For this reason we are ranked the first largest Bulk Friendly Internet Service Provider in the world. Bulletproof Hosting Prices 30 days Hosting $600.00 and a one time Set-up of $200.00 24 hr Set-up *Targeted Email Lists Quotes available upon request For more information and to get started please call us at: 1 (323) 874-4647 . If you would like to be removed , please email: webmaster@www.yu with the word "Remove" in the subject line. We apologize for any inconvenience. From rem-conf Thu Aug 17 11:19:29 2000 From rem-conf-request@es.net Thu Aug 17 11:19:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13PUAP-00038w-00; Thu, 17 Aug 2000 11:13:25 -0700 Received: from (se-notes1.sue.de) [62.132.31.113] by mail1.es.net with smtp (Exim 1.81 #2) id 13PUAN-00038m-00; Thu, 17 Aug 2000 11:13:23 -0700 Received: from bulabula ([158.252.249.230]) by se-notes1.sue.de (Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) with SMTP id C125693E.005A40C6; Thu, 17 Aug 2000 18:25:52 +0200 From: finance101@acton-london.co.uk To: Subject: Work Smarter From Home Date: Thu, 17 Aug 2000 09:17:25 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_4BAC_00003CD8.000077D7" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------=_NextPart_000_4BAC_00003CD8.000077D7 Content-Type: text/html; $ ENTREPRENEURS $
Tired of working for someone else and getting paid what "they" feel you're
worth?
Tired of the "get-rich-quick" $5 fantasy programs?
Tired of the MLM "dream scene"?
Looking for a legitimate home-based enterprise that can generate you
$10k-$20k+ monthly?
THEN CHECK THIS OUT!!!

*80% profit on all sales that pay you from $1250-$6250 per sale

*No personal selling or "convince me" tactics involved

*No special skills or equipment required or "inventory" to keep

*Complete information system in place does the explaining for you

*Free-enterprise in its purest form, not MLM or franchise

*Full training and support in an environment of up most integrity

*Exceptional products, not "vitamins, lotions, and potions"

*Lead generation system that brings qualified prospects to you

*Multiple 6 figure income realistically attainable in 1st year

*3 year retirement program... PERIOD!


This program is all about money... how to make it,
how to keep it, and how to make it work for you.

CALL NOW!!! 1-800-320-9895 ext 6396


Leave your name and number twice!. After a brief
interview, I will get you all the information you
need to make your own relaxed and intelligent
decision about your future.
(Serious inquiries only please)




to be removed from future mailings send a blank email
with remove in the subject line and the email address
or addresses you would like removed to finance101@acton-london.co.uk



From rem-conf Sat Aug 19 15:24:04 2000 From rem-conf-request@es.net Sat Aug 19 15:24:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QGln-0006v3-00; Sat, 19 Aug 2000 15:07:15 -0700 Received: from ip33.dayton8.oh.pub-ip.psi.net (mail01.homewknow.com) [38.31.110.33] by mail1.es.net with smtp (Exim 1.81 #2) id 13QGlh-0006uN-00; Sat, 19 Aug 2000 15:07:09 -0700 From: Subject: FREE CASH GRANTS, $500 - $50,000! Date: Sat, 19 Aug 2000 14:04:35 Message-Id: <440.291750.701792@mail01.homewknow.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FREE CASH GRANTS, NEVER REPAY! You Can Get The Money You Need... To Start Your Home Business... To Consolidate Your Debt... To Go To college... To Start Your Home Business... Almost ANY Worthwhile Reason... Why? Foundations all over the United States GIVE away Millions of Dollars of CASH GRANTS every year. They must give this MONEY away, in order to maintain their tax free status. Who Can Apply? ANYONE can apply for a Grant from 18 years old and up! We Can Help! We will show you HOW & WHERE to get Grants. This MONEY has to be given away, WHY not to YOU? Grants from $500.00 to $50,000.00 are possible! GRANTS don't have to be paid back! Grants can be ideal for people who are or were bankrupt or just have bad credit. Interested, Please Visit Our Website Below And Place Your Order! ********** http://3433193646/~grantworld2000/intro.html ********** The Good News! DON'T pay $79.00 to $129.00 for this information and list. We Will Show You How To Apply For Your Grants, Where To Apply, And Exactly What To Say. We Help You Do It All For Just $34.95. If You Pay With Credit Card, All Information Will Be Sent To You The Next Day, via Certified Mail! This means you will receive your order within 24 to 48 Hours! We Gladly Accept Credit Cards & Checks Via Web and Postal Mail: American Express Master Card Visa Don't Delay, This Is A Limited Time Offer At This Amazing Low Price! Get That Grant Before College Rush Time Coming Up! Interested, Please Visit Our Website Below And Place Your Order! ********** http://3433193646/~grantworld2000/intro.html ********** To Order by postal mail, please send $34.95 Plus $4.00 S & H. Make payable to Grant Gold 2000. Grant Gold 2000 4132 Pompton Ct. Dayton, Ohio 45405 We Accept: Visa Master Card American Express Money Orders Checks If you would like to order via Fax, please include your credit card number, expiration date, and your email address. OUR 24 HOUR FAX NUMBER: (775) 414-7455 ***** Important Credit Card Information! Please Read Below! * Credit Card Address, City, State and Zip Code, must match billing address to be processed. CHECK____ MONEYORDER____ VISA____ MASTERCARD____ AmericanExpress___ Debt Card___ Name_______________________________________________________ (As it appears on Check or Credit Card) Address____________________________________________________ (As it appears on Check or Credit Card) ___________________________________________________ City,State,Zip(As it appears on Check or Credit Card) ___________________________________________________ (Credit Card Number) Expiration Month_____ Year_____ ___________________________________________________ Email Address (Please Write Neat) ___________________________________________________ Authorized Signature ********** Notice: Due To Much Misuse of Customers Copying The Information, Then Requesting A Refund, All sales final on reports. You cannot receive a refund from Grant Gold 2000 for the report, nor will you receive a refund by requesting a "chargeback" from your Credit Card Company. All Reports Will Be Shipped Via Certified or Registered Postal Mail. If you should receive a destroyed copy due to shipping, we will replace it at no extra charge. From rem-conf Sun Aug 20 13:34:05 2000 From rem-conf-request@es.net Sun Aug 20 13:34:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QbeK-00022W-00; Sun, 20 Aug 2000 13:24:56 -0700 Received: from post1.inre.asu.edu [129.219.13.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13QbeI-00022M-00; Sun, 20 Aug 2000 13:24:54 -0700 Received: from conversion.post1.inre.asu.edu by asu.edu (PMDF V5.2-31 #33824) id <0FZL00N01Y1GZ9@asu.edu> for rem-conf@es.net; Sun, 20 Aug 2000 13:24:52 -0700 (MST) Received: from smtp.asu.edu (smtp.asu.edu [129.219.13.92]) by asu.edu (PMDF V5.2-31 #33824) with ESMTP id <0FZL00IH4Y1GQA@asu.edu> for rem-conf@es.net; Sun, 20 Aug 2000 13:24:52 -0700 (MST) Received: from mercury (lanload1.eas.asu.edu [149.169.25.2]) by smtp.asu.edu (8.9.3/8.9.3) with SMTP id NAA26846 for ; Sun, 20 Aug 2000 13:24:54 -0700 (MST) Date: Sun, 20 Aug 2000 13:22:25 -0700 From: Li Bing Subject: unsubcribe To: rem-conf@es.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_GDeRKr/0ZkxC00b++LsHTw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_GDeRKr/0ZkxC00b++LsHTw) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit CSE, ASU __...----------------..._ ____________ _.--~~~~~~~~~~~~~~~-.\~~~~~~~~\~-._ _____|| ` ___ _.-~ 480-965-1746 (O) ~\\_ __ `\ ~-. _.-~`\ \_-~ 480-965-3753 (L) ___\___/ )\_/-~ `\ .-~~ ~~~------------------~~~~~ _.--._..--~~ \ /~\| .~/ // _-~ _ `\. | /\\ | / |___ 480-829-8492 (H) ______.~ /_\ | | |/ ||' |` \ |_bing.li@asu.edu_/ _-~ /~\\' | _/ |)=|| | ~-_|________________/_.-~ // || |_..-~ |\ || .. __________ \/ ____________ /()= || __./\\// \(_)\_______) (_________/(_) / \\ ||__..--~~~ ~~~~~~ `-._________________________..--' \___//~ `------`--' `---------' - Li Bing www.public.asu.edu/~libing --Boundary_(ID_GDeRKr/0ZkxC00b++LsHTw) Content-type: application/ms-tnef; name="winmail.dat" Content-disposition: attachment; filename="winmail.dat" Content-transfer-encoding: base64 eJ8+IhkUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCAAUAA0AFgAAAAAAFgEB A5AGAJAGAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAACwAAAHVuc3ViY3JpYmUAAAIBcQABAAAAFgAAAAHACuRaPLXehnF2IhHUivAAUNrP1j4AAAIB HQwBAAAAFQAAAFNNVFA6QklORy5MSUBBU1UuRURVAAAAAAsAAQ4AAAAAQAAGDgBkY0vkCsABAgEK DgEAAAAYAAAAAAAAAKqXib2OdNQRiuoAUNrP1j7CgAAACwAfDgEAAAACAQkQAQAAAEQCAABAAgAA QAQAAExaRnWvl+nCAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc/BldDAgBxMC gwBQBFUREMlGaXgJgHN5c5UCgH0KgXYIkHdrC4D0ZDQMYGMAUAsDC7YKsScKhAqEFUExIBcQQ1Nk RSwRYFNVFxEXx1+0Xy4YoC0Y3RihXxhx3xooFdQXyhhSGMF+HHwZwDxcXBx2HYEZwBoFfHxcIGAa 6xohHCJ+FxA0ADgwLTk2NS0xgDc0NiAoTykXEd8eER2AGgIXER8QXCGhGcA/ICMigRrrIfEgUiCH Mzf0NTMhUEwhgh/TIfEYgOovF8MpIfEvJIMiVBro/yBBIGAdMikvHHMcFBnwGLJXKnIikhfCLx4R fBrmLvZ+JqQXxi8tDBhwJIMaAP8igSLwF8Qe8CviIdIwABrljSagfB/yIIM4Mjkx8Og0OTIhUEgh gBokLOAvK8QmQS/1L+V8MUF8J1kV1HxgK4QxYGILgGcALmxpQGFzdS69CYB1JpMkdCvlHYAnM/Vx JpR8KT0e4DUlIZIt/x7QGioaIjOgIEMtiB7hMWD/GLEnZSxQMKEsVRigH9MaJe8kMiahGiorxCg5 QDxiGAnPMGMt4BrlHYAoXycCGiT/JcNCsDrnQrEr4iRBM8MxYe8rFCjTHfIa9WAeUUcvGiX/GLI4 UCZULBFGhxjTShE4UA9KzkoVGNFKsy0gTGksIEI2MRrmd03QLnD2dQJgDeAuNqUsEDZwNiIXFjsV xRPxAFDwCwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAA RgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAA wAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsADYAIIAYAAAAAAMAAAAAAAABGAAAA AIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBSgAggBgAA AAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB +A8BAAAAEAAAAKqXib2OdNQRiuoAUNrP1j4CAfoPAQAAABAAAACql4m9jnTUEYrqAFDaz9Y+AgH7 DwEAAACQAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gB AKoAN9luAAAAQzpcV0lOTlRcUHJvZmlsZXNcbGliaW5nXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0 aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAwD+DwUAAAADAA00/TcAAAIB fwABAAAALwAAADxORUJCSUtPS0tLTUhGREhDRklFS0VFQ0JDQkFBLmJpbmcubGlAYXN1LmVkdT4A AAMABhApF2iPAwAHEM4AAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAQ1NFLEFTVS0tLS0t LS0tLS0tLS0tLS0tLS0tLTQ4MC05NjUtMTc0NihPKS0tLTQ4MC05NjUtMzc1MyhMKS8pLy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS8vLy8tLy80ODAtOAAAAACQcw== --Boundary_(ID_GDeRKr/0ZkxC00b++LsHTw)-- From rem-conf Sun Aug 20 14:53:14 2000 From rem-conf-request@es.net Sun Aug 20 14:53:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Qctm-0003aT-00; Sun, 20 Aug 2000 14:44:58 -0700 Received: from smtp-out1.bellatlantic.net [199.45.39.156] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Qctl-0003aJ-00; Sun, 20 Aug 2000 14:44:57 -0700 Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA26232; Sun, 20 Aug 2000 17:44:48 -0400 (EDT) Message-ID: <39A05142.2C80BACD@cs.columbia.edu> Date: Sun, 20 Aug 2000 17:44:34 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Frederick CC: Flemming Andreasen , rem-conf@es.net Subject: Re: Timestamp/sequence# following SSRC collision References: <39975A36.5BFBB0FD@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >From the viewpoint of the sender (and the one changing the SSRC), it's easier to keep the sequence number and timestamp progression going, particularly if the two pieces of code are separate. Thus, I would certainly not want to prescribe a change. (A receiver is ill-advised to fail if for some reason there's a ts/seq. no discontinuity, so it should be ok either way.) Ron Frederick wrote: > > In message <39975A36.5BFBB0FD@cisco.com> you write: > > Greetings > > > > The initial value of the RTP timestamp and sequence number SHOULD be > > random, and if a source discovers an SSRC collision with itself, it MUST > > send an RTCP BYE packet. When the source re-joins the session with a new > > SSRC, should the initial RTP timestamp and sequence number be random > > again, or can we continue using the old "sequence" ? Does it matter ? > > > >From the point of view of some other receiver in the session, the new SSRC > is going to make this participant seem like a brand new sender, at least > until some time later when the first RTCP arrives with their CNAME. So, I > don't really see any value in preserving the sequence numbers and timestamps. > I would treat this case the same as when you first start up and suggest > picking a new random offset for each. I'm not sure it strongly matters, > though. > -- > Ron Frederick > ronf@entera.com From rem-conf Sun Aug 20 20:06:23 2000 From rem-conf-request@es.net Sun Aug 20 20:06:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Qhkn-0006gs-00; Sun, 20 Aug 2000 19:56:01 -0700 Received: from firewall-swip.esab.net (trade.esab.se) [192.36.151.66] by mail1.es.net with smtp (Exim 1.81 #2) id 13Qhki-0006fH-00; Sun, 20 Aug 2000 19:55:56 -0700 Received: from jimi.gbg.esab.se([172.20.5.17]) by TRADE.ESAB.SE (IBM OS/400 SMTP V04R02M00) with TCP; Mon, 21 Aug 2000 04:53:56 +0000 Message-ID: <00003e261156$000047b8$00005c49@152.23.36.39> To: From: Successisgood@aol.com Subject: Cyber-Biz Secrets Date: Sun, 20 Aug 2000 09:22:24 -0400 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: netremove@netease.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Truth Is Finally Revealed.... How Does The Richest Man In The World Use The Greatest Business Secrets Of All Time To Make Over 32.4 Million Dollars A Day?!! No matter who you are, where you live or what your sex, age or race is by the time you finish reading this special article, you will know: * How to start a proven money making business that requires no inventory, no shipping and no employees within 7 days, guaranteed! * How to get a $300 professionally designed Web Site for FREE! * How to increase your sales by more than 137% in 30 days regardless of your business! * How to get paid for a 1000-hour workweek, without going to work! * How to turn 50 cents into $50, with a simple click of a button! * How to get a $179 business-building CD-ROM for FREE! * If you ever wanted a business where you could hit the ground running.... a business where you could just open a box and start making immediate profits.... a business that's completely set up and ready to pull in maximum sales.... with a product that sells itself... then I've got some great news for you! Act NOW <<<<<< There is A DEADLINE!!! >>>>>> Instant Information Request Directions: **>NOTE: You may also just Click Below to send it through your normal e-mail program. mailto:netcash3000@netease.com?subject=send_info_on_InfoMax820 It's much easier to do it this way, it will fill in the return e-mail and subject for you. 2. You will receive the complete info on the reports via e-mail within 24 hours. P.S. Act NOW!-- Only the first 75 requests will be granted to receive this Special Web Site e-Report for *FREE* titled "The Greatest Business Secrets Of All Time" P.P.S. *FREE Download Bonus e-Manual* "Microsoft, Viagra & Your Business Success" given to the first 35 people to respond within the next 24 hours, Your FREE reports will be fulfilled in the order in which they were received. Privacy Policy: We respect your privacy and your e-mail address/name will be kept strictly private it will never be sold, shared or given away for any reason. Simple Removal Instructions: To Be Removed: mailto:netremove@netease.com?subject=remove820 You will then be deleted from our e-mail database forever. NO FLAMES!! You will not be added to the remove database unless you do this. No Exceptions, anything but "remove" in the subject will generate an automatic response. Thank You!! From rem-conf Mon Aug 21 01:07:21 2000 From rem-conf-request@es.net Mon Aug 21 01:07:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QmRf-0002MK-00; Mon, 21 Aug 2000 00:56:35 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13QmRd-0002MA-00; Mon, 21 Aug 2000 00:56:33 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id KAA00888; Mon, 21 Aug 2000 10:51:47 +0300 (IDT) Message-ID: <39A0E43C.BDD9B4E0@bitband.com> Date: Mon, 21 Aug 2000 10:11:41 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Dorgham Sisalem CC: =?iso-8859-1?Q?Kav=E9?= Salamatian , tme@21rst-century.com, rem-conf Subject: Re: New congestion control text in RTP spec References: <200008161458.QAA09198@mailhub.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 Collegues, Please allow me to add a brief comment wirh respect to congestion control in RTP: Congestion control was required to be added to TCP because TCP has a policy of packet retransmission which does not have a limit on the load (or attempted throughput) it inserts into the network. This total lack of limits was the cause of the congestion/collapse fenomena which was observed in the early large deployments of IP networks which carried many TCP streams. With RTP on the other hand, it seems the load generated by each transmitter is constant, and does not increase when pakcet loss or network delay increases. This is not entirely true when packet retransmission is added, but as long as this is true, i.e. there is a definitive upper limit on the load generated by each particular client, there might be no need for an additional congestion control mechanism, becasue with such an upper limit RTP will not cause a congestion collapse. In the case when retransmission error control is implemented, there should be an uppe rlimit on the total amount of bandwidth generated by all traffic including retransmissions and handshakes, to avoid the TCP-like behaviour which required congestion control in the first place. Hope this comment is useful, Leonid Rosenboim From rem-conf Mon Aug 21 03:09:11 2000 From rem-conf-request@es.net Mon Aug 21 03:09:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QoMo-0004IO-00; Mon, 21 Aug 2000 02:59:42 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13QoMm-0004IC-00; Mon, 21 Aug 2000 02:59:40 -0700 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA19188; Mon, 21 Aug 2000 11:59:20 +0200 (MET DST) Message-Id: <200008210959.LAA19188@mailhub.fokus.gmd.de> X-Mailer: exmh version 1.6.7 5/3/96 To: leonid@bitband.com cc: =?iso-8859-1?Q?Kav=E9?= Salamatian , tme@21rst-century.com, rem-conf Subject: Re: New congestion control text in RTP spec In-reply-to: Your message of "Mon, 21 Aug 2000 10:11:41 +0200." <39A0E43C.BDD9B4E0@bitband.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Aug 2000 11:59:20 +0200 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list leonid@bitband.com said: > Congestion control was required to be added to TCP because TCP has a > policy of packet retransmission which does not have a limit on the > load (or attempted throughput) it inserts into the network. This > total lack of limits was the cause of the congestion/collapse > fenomena which was observed in the early large deployments of IP > networks which carried many TCP streams. I would say this is a little bit over simplistic, the goal of congestion control is to figure out the appropriate transmission rate to use that does not lead to network overload. If a few or all RTP senders start transmitting data at a very high rate (say their Ethernet line speed) because the user thinks that his video stream should get all bandwidth available then we will soon end up in a very bad situation and have a new form of netowrk collapse (regardless if we are using retranmissions or not Dorgham From rem-conf Mon Aug 21 04:27:23 2000 From rem-conf-request@es.net Mon Aug 21 04:27:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QpZa-0005gW-00; Mon, 21 Aug 2000 04:16:58 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13QpZZ-0005gM-00; Mon, 21 Aug 2000 04:16:57 -0700 Received: from [207.176.21.199] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 521618; Mon, 21 Aug 2000 07:20:35 -0400 Message-ID: <39A11092.58E26F97@21rst-century.com> Date: Mon, 21 Aug 2000 07:20:51 -0400 From: Thomas 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: leonid@bitband.com CC: Dorgham Sisalem ,"=?iso-8859-1?Q?Kav=E9?= Salamatian" , rem-conf Subject: Re: New congestion control text in RTP spec References: <200008161458.QAA09198@mailhub.fokus.gmd.de> <39A0E43C.BDD9B4E0@bitband.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 Leonid Rosenboim wrote: > Dear Collegues, > > Please allow me to add a brief comment wirh respect to congestion control > in RTP: > > In the case when retransmission error control is implemented, there should > be > an uppe rlimit on the total amount of bandwidth generated by all traffic > including > retransmissions and handshakes, to avoid the TCP-like behaviour which > required > congestion control in the first place. > I would argue that re-transmission congestion control is indeed a potential problem, but for the RMT working group. I do not believe that the draft profile is intended for this case, although wording could be added : "More aggressive TCP like congestion control MUST be added in case relieable multicast retransmission error control is being used." > > Hope this comment is useful, > > Leonid Rosenboim 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Mon Aug 21 04:31:13 2000 From rem-conf-request@es.net Mon Aug 21 04:31:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13QpfT-0005jY-00; Mon, 21 Aug 2000 04:23:03 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13QpfS-0005jO-00; Mon, 21 Aug 2000 04:23:02 -0700 Received: from [207.176.21.199] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 521620; Mon, 21 Aug 2000 07:26:54 -0400 Message-ID: <39A11212.313CD3F4@21rst-century.com> Date: Mon, 21 Aug 2000 07:27:15 -0400 From: Thomas 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: Dorgham Sisalem CC: leonid@bitband.com, "=?iso-8859-1?Q?Kav=E9?= Salamatian" ,rem-conf Subject: Re: New congestion control text in RTP spec References: <200008210959.LAA19188@mailhub.fokus.gmd.de> 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 Dorgham Sisalem wrote: > leonid@bitband.com said: > > Congestion control was required to be added to TCP because TCP has a > > policy of packet retransmission which does not have a limit on the > > load (or attempted throughput) it inserts into the network. This > > total lack of limits was the cause of the congestion/collapse > > fenomena which was observed in the early large deployments of IP > > networks which carried many TCP streams. > > I would say this is a little bit over simplistic, the goal of I think that what Leonid says here is the literal truth. > > congestion control is to figure out the appropriate transmission rate > to use that does not lead to network overload. If a few or all RTP > senders start transmitting data at a very high rate (say their Ethernet > line speed) because the user thinks that his video stream should get > all bandwidth available then we will soon end up in a very bad > situation and have a new form of netowrk collapse (regardless if we are > using retranmissions or not > > Dorgham And any form of receiver based RTP congestion control, no matter how simple minded, will shut down the reception in this case, because the packets will not get through. I would argue, in the spirit of "if it ain't broke, don't fix it", that this scenario has not yet been a problem in practice, that it is unclear that it will become a problem in practice, and furthermore it is unclear how it should be implemented in practice, nor how to keep it, if implemented, >from trashing the RTP stream being delivered, so that it is at best way premature to call for its inclusion in the draft profile, except maybe as a MAY. 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Tue Aug 22 05:15:37 2000 From rem-conf-request@es.net Tue Aug 22 05:15:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RCfl-0005qV-00; Tue, 22 Aug 2000 04:56:53 -0700 Received: from pelican.tk.uni-linz.ac.at [140.78.188.41] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13RCfj-0005qL-00; Tue, 22 Aug 2000 04:56:51 -0700 Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id NAA27538; Tue, 22 Aug 2000 13:55:23 +0200 (MET DST) From: Michael Welzl Reply-To: Sender: "Michael Welzl" To: "'Jon Crowcroft'" , "'Jamal Hadi Salim'" , "'Henning Schulzrinne'" , , , , , , , , Subject: ABR to the Internet collaboration (BOF?) Date: Tue, 22 Aug 2000 14:00:48 +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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (If you personally received this mail, you have been hand picked because you seem to work in a related area or showed some interest in what I am doing.) Hi all, I am a Ph.D. student whose work is basically about bringing an ABR-like mechanism to the Internet. I identified some data to be transmitted to end nodes and designed a protocol to carry them (draft-welzl-ptp-03.txt). Please take a look at http://www.tk.uni-linz.ac.at/~michael/ptp/ to see the current state of my work; the specification encompasses the definition of Content Types (the type of data to be transmitted). However, I am convinced that a more generic approach (like IntServ / RSVP) would be better: - Various Content Types could be used, showing different properties - like "does the calculation infer per-flow state in routers?". This is not necessarily restricted to bandwidth calculations; for instance, a link's MTU could also be transmitted to provide more efficient Path MTU Discovery. - Partly depending on the data to be transmitted, it would make sense not only to define a new protocol but also to define extensions to other protocols such as RSVP and RTCP. Actually, the name "ABR to the Internet" is not quite precise; in fact, it's more like "ABR Explicit Rate Feedback related mechanisms carrying certain data on the Internet". In any case, it all needs IETF standardization because it will never really work without router support. Therefore, I believe parties working in related areas should request permission to hold a BOF session. I would personally do so, but I might not be able to attend the next two IETF meetings due to our departments current financial situation. Be it for a BOF or not, I would really like to get some cooperation and discussion going. If we cannot find an appropriate place (what about AVT?), I can set up a bulletin board or mailing list. I just set up the page at http://www.tk.uni-linz.ac.at/~michael/ptp/ in support of this mail, and I can add to it whatever you wish. Hoping for feedback, regards, Michael Welzl PS: Feel free to forward this to anybody you think might be interested. Also, if you know the e-mail address of Tim Mangan ( http://www.frforum.com/3000/tim.html ), please forward this to him; tmangan@softwarewow.com doesn't seem to work - he originally had the idea of forming a Working Group. David Lapsley should also be interested, but lapsley@ee.mu.oz.au doesn't work either. ---------------------------------------------------------------------- Dipl.-Ing. Michael Welzl Researcher Telecooperation Group Dpt. of Computer Science University of Linz Altenberger Str. 69, A-4040 Linz, Austria Phone: +43/732/2468-9264 Fax: +43/732/2468-9829 ICQ # 38201212 http://www.tk.uni-linz.ac.at/~michael/ From rem-conf Tue Aug 22 07:44:14 2000 From rem-conf-request@es.net Tue Aug 22 07:44:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RFAX-0000ey-00; Tue, 22 Aug 2000 07:36:49 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RFAV-0000eo-00; Tue, 22 Aug 2000 07:36:47 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA04445; Tue, 22 Aug 2000 10:33:42 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id TAA27249; Tue, 22 Aug 2000 19:33:19 +0500 Message-Id: <200008221433.TAA27249@hafez.east.isi.edu> To: michael cc: "'Jon Crowcroft'" , "'Jamal Hadi Salim'" , "'Henning Schulzrinne'" , sisalem , rem-conf , pingpan , adg , kim , ssjoo , istoica , hzhang Subject: Re: ABR to the Internet collaboration (BOF?) In-Reply-To: Your message of "Tue, 22 Aug 2000 14:00:48 +0200." Date: Tue, 22 Aug 2000 10:33:19 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Michael Welzl writes: ... >Be it for a BOF or not, I would really like to get some cooperation >and discussion going. If we cannot find an appropriate place (what >about AVT?), I can set up a bulletin board or mailing list. This is very much outside the scope of the AVT working group's charter, so I don't believe that the rem-conf list is appropriate. Colin Perkins (AVT co-chair) From rem-conf Tue Aug 22 11:50:38 2000 From rem-conf-request@es.net Tue Aug 22 11:50:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RIwI-0003b1-00; Tue, 22 Aug 2000 11:38:22 -0700 Received: from mailman.cisco.com [171.68.225.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RIwG-0003an-00; Tue, 22 Aug 2000 11:38:20 -0700 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01544 for ; Tue, 22 Aug 2000 11:37:15 -0700 (PDT) Message-ID: <39A2C95B.290E8189@cisco.com> Date: Tue, 22 Aug 2000 14:41:32 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf Subject: Optional DTMF support in RFC 2833 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks Just wanted to draw all RFC 2833 interested parties to the following implementation note (http://www.cs.columbia.edu/~hgs/rtp/payload.html): "Implementations can support events 0 through 15 (DTMF) by simply ignoring the packets, but MUST declare all event numbers that are meaningful to it in the fmtp parameter, including 0 through 15." Thanks Flemming -- Flemming Andreasen Cisco Systems From rem-conf Wed Aug 23 02:34:16 2000 From rem-conf-request@es.net Wed Aug 23 02:34:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RWnL-0004LC-00; Wed, 23 Aug 2000 02:26:03 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RWnE-0004L2-00; Wed, 23 Aug 2000 02:25:57 -0700 Received: from fokus.gmd.de (donald [193.175.132.118]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA24851; Wed, 23 Aug 2000 11:25:29 +0200 (MET DST) Message-Id: <200008230925.LAA24851@mailhub.fokus.gmd.de> To: michael@tk.uni-linz.ac.at cc: "'Jon Crowcroft'" , "'Jamal Hadi Salim'" , "'Henning Schulzrinne'" , rem-conf@es.net, pingpan@research.bell-labs.com, adg@ieee.org, kim@cs.uml.edu, ssjoo@etri.re.kr, istoica@cs.cmu.edu, hzhang@cs.cmu.edu Subject: Re: ABR to the Internet collaboration (BOF?) In-reply-to: Your message of "Tue, 22 Aug 2000 14:00:48 +0200." Date: Wed, 23 Aug 2000 11:25:23 +0200 From: Dorgham Sisalem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list before we discuss what needs to be specified, it would be worth considering the benefits and backdraws of such an approach. While I have always been in favour of ABR-like mechanisms I am not sure that they really buy us much. End-to-end approaches for measuring bottleneck bandwidth and MTU might be more complicated and less accurate than simply asking the routers for the information, but they are more secure and easier to use. I doubt that network providers would be willing to open their mibs just like that. Even if they did, I am still not convinced that the information collected by PTP improve the adaptation process dramatically. The example you give in your paper is not very convincing ( however, as it the test description is very unclear I might have missed the point there) Regards Dorgham From rem-conf Wed Aug 23 03:01:45 2000 From rem-conf-request@es.net Wed Aug 23 03:01:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RXH8-0005N1-00; Wed, 23 Aug 2000 02:56:50 -0700 Received: from pelican.tk.uni-linz.ac.at [140.78.188.41] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13RXH6-0005Mr-00; Wed, 23 Aug 2000 02:56:48 -0700 Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA32560; Wed, 23 Aug 2000 11:56:06 +0200 (MET DST) From: Michael Welzl Reply-To: Sender: "Michael Welzl" To: "'Dorgham Sisalem'" Cc: "'Jon Crowcroft'" , "'Jamal Hadi Salim'" , "'Henning Schulzrinne'" , , , , , , , Subject: RE: ABR to the Internet collaboration (BOF?) Date: Wed, 23 Aug 2000 12:01:32 +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 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Two notes in advance: - First, let's keep avt (rem-conf@es.net) out of any future discussion. I left it in there just this once to let EVERYONE know about that. - I just set up a mailing list on the subject and updated the page accordingly. To subscribe: Send a mail to majordomo@tk.uni-linz.ac.at with the text subscribe abr-internet in the body of your message. To unsubscribe: Send a mail to majordomo@tk.uni-linz.ac.at with the text unsubscribe abr-internet in the body of your message. The address for discussion is abr-internet@tk.uni-linz.ac.at > before we discuss what needs to be specified, it would be > worth considering > the benefits and backdraws of such an approach. While I have > always been > in favour of ABR-like mechanisms I am not sure that they > really buy us much. Agree. The next thing I'll do is tidy the ns code (and example scripts) and upload it so everyone can fool around with it. > End-to-end approaches for measuring bottleneck bandwidth and > MTU might be > more complicated and less accurate than simply asking the > routers for the > information, but they are more secure and easier to use. I > doubt that network > providers would be willing to open their mibs just like that. I have no tests or simulations with respect to MTU yet; this is just a simple, MAYBE advantageous example I always use to explain how the protocol works and why the idea isn't necessarily restricted to bandwidth estimation. > Even if they > did, I am still not convinced that the information collected > by PTP improve the > adaptation process dramatically. The example you give in your > paper is not > very convincing ( however, as it the test description is very unclear > I might have missed the point there) I will of course answer any questions you might have about how the simulations were performed. The topology used for the simulations in "A stateless QoS Signaling Protocol for the Internet" can be seen in the slides at http://www.tk.uni-linz.ac.at/~michael/ptp/icpads2000.ppt What else is unclear about the description? Regarding improvements, I have only evaluated the packet loss ratio so far and believe I achieved good results, especially with the PTP / normal adaptation combo (normal down, PTP up). The combo yielded a smaller packet loss ratio no matter how I changed the parameters (with the exception of increasing the background traffic to a degree where an unbearable amount of PTP packets get lost, of course). I'm not saying that PTP bandwidth trend estimation is better than ALS. In fact, it's almost certainly worse, but it imposes a lot less work on routers (stateless, no need to keep track of active flows) and still yields useful results. I'm saying we should start categorizing the Content Types like this (as a simplification, of course - we'd certainly need more specific attributes like "work imposed on routers", "measured benefits", ...): ALS: - advantages, disadvantages - recommended carriers PTP BW Trend Estimation: - advantages, disadvantages - recommended carriers ... See y'all on the mailing list, Kind regards, Michael Welzl From rem-conf Wed Aug 23 03:40:12 2000 From rem-conf-request@es.net Wed Aug 23 03:40:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RXrd-0006WV-00; Wed, 23 Aug 2000 03:34:33 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RXrb-0006WJ-00; Wed, 23 Aug 2000 03:34:31 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07182; Wed, 23 Aug 2000 06:34:28 -0400 (EDT) Message-Id: <200008231034.GAA07182@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-mpeg4-es-03.txt Date: Wed, 23 Aug 2000 06:34:27 -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 for MPEG-4 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata Filename : draft-ietf-avt-rtp-mpeg4-es-03.txt Pages : 19 Date : 22-Aug-00 This document describes RTP payload formats for carrying of MPEG-4 Audio and Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for MIME type registrations and the use of SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-03.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-mpeg4-es-03.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-mpeg4-es-03.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: <20000822153107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000822153107.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Aug 23 11:45:07 2000 From rem-conf-request@es.net Wed Aug 23 11:45:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RfKm-0004Qd-00; Wed, 23 Aug 2000 11:33:08 -0700 Received: from (eth.net) [202.9.145.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RfKj-0004Q8-00; Wed, 23 Aug 2000 11:33:07 -0700 Received: from eth.net ([10.2.1.41]) by eth.net with Microsoft SMTPSVC(5.5.1877.117.11); Wed, 23 Aug 2000 23:56:39 +0530 Received: from madan ([202.9.165.42]) by eth.net with Microsoft SMTPSVC(5.5.1877.357.35); Wed, 23 Aug 2000 23:58:42 +0530 Message-ID: <000801c00d32$9e9ba420$2aa509ca@madan> Reply-To: "Madan A S" From: "Madan A S" To: , References: <200008161458.QAA09198@mailhub.fokus.gmd.de> <39A0E43C.BDD9B4E0@bitband.com> Subject: Re: New congestion control text in RTP spec Date: Tue, 22 Aug 2000 13:33:24 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 > With RTP on the other hand, it seems the load generated by each transmitter > is constant, and does not increase when pakcet loss or network delay > increases. > This is not entirely true when packet retransmission is added, but as long > as this is true, i.e. there is a definitive upper limit on the load generated by > each particular client, there might be no need for an additional congestion control > mechanism, becasue with such an upper limit RTP will not cause a congestion collapse. > Would somebody mind explaining me, Why the load generation from transmitter is CONSTANT in case of RTP ? From rem-conf Wed Aug 23 12:12:14 2000 From rem-conf-request@es.net Wed Aug 23 12:12:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Rfrc-0005bR-00; Wed, 23 Aug 2000 12:07:04 -0700 Received: from sjc3-1.relay.mail.uu.net [199.171.54.122] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Rfrb-0005bG-00; Wed, 23 Aug 2000 12:07:03 -0700 Received: from 21rst-century.com by sjc3sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjdng13196; Wed, 23 Aug 2000 19:06:13 GMT Message-ID: <39A42042.1AF101D4@21rst-century.com> Date: Wed, 23 Aug 2000 15:04:34 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Madan A S CC: leonid@bitband.com, rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <200008161458.QAA09198@mailhub.fokus.gmd.de> <39A0E43C.BDD9B4E0@bitband.com> <000801c00d32$9e9ba420$2aa509ca@madan> 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 Madan A S wrote: > > With RTP on the other hand, it seems the load generated by each > transmitter > > is constant, and does not increase when pakcet loss or network delay > > increases. > > This is not entirely true when packet retransmission is added, but as long > > as this is true, i.e. there is a definitive upper limit on the load > generated by > > each particular client, there might be no need for an additional > congestion control > > mechanism, becasue with such an upper limit RTP will not cause a > congestion collapse. > > > > Would somebody mind explaining me, > Why the load generation from transmitter is CONSTANT in case of RTP ? We are assuming multicasting - this is not true in the unicast case. In multicasting, assuming at least one receiver, the source sends out one and only one stream. (In case of N multiple streams to do FEC/striping, then, assuming at least one listener for each sub-stream, it sends out exactly N streams.) That is the real economic reason to do multicasting. -- 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Wed Aug 23 12:22:21 2000 From rem-conf-request@es.net Wed Aug 23 12:22:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Rg4H-0006Qn-00; Wed, 23 Aug 2000 12:20:09 -0700 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Rg4F-0006QW-00; Wed, 23 Aug 2000 12:20:08 -0700 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7NJInY05958; Wed, 23 Aug 2000 22:18:49 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 23 Aug 2000 14:18:47 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B7E3@daeis05nok> From: zhigang.liu@nokia.com To: madanas@ieee.org, leonid@bitband.com, rem-conf@es.net Subject: RE: New congestion control text in RTP spec Date: Wed, 23 Aug 2000 14:15:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > -----Original Message----- > From: EXT Madan A S [mailto:madanas@eth.net] > Sent: Tuesday, August 22, 2000 3:03 AM > To: leonid@bitband.com; rem-conf@es.net > Subject: Re: New congestion control text in RTP spec > > > > With RTP on the other hand, it seems the load generated by each > transmitter > > is constant, and does not increase when pakcet loss or network delay > > increases. > > This is not entirely true when packet retransmission is > added, but as long > > as this is true, i.e. there is a definitive upper limit on the load > generated by > > each particular client, there might be no need for an additional > congestion control > > mechanism, becasue with such an upper limit RTP will not cause a > congestion collapse. > > > > Would somebody mind explaining me, > Why the load generation from transmitter is CONSTANT in case of RTP ? No, it isn't. For voice, a codec without silence suppression may generate constant RTP payload. However, if the silence suppression is turned on, there will be no RTP packets generated during the silent periods, except for some small packet carrying comfort noise information (if the CNG is switched on also). As to video, you probably all know it's VBR in nature. The load won't be constant unless you do some buffering. But this is probably not tolerable for real-time video. RTP stands for real-time, anyway. I didn't follow this thread continuously (I'm currently busy with RTP header compression in rohc WG). So I'm not sure what kind of congestion control you guys are talking about. To me, it looks like a more general problem of QoS (admission control, policing, blah, blah), which is not specific to RTP. The picture in my mind is a big (perhaps not big in some cases) IP pipe which carries all kinds of IP flows (TCP, UDP, etc). Congestion control can be only effective if all flows conform to some rules. (e.g. TCP is a little bit aggressive here). Again, I'm just waving my hands. Br, Zhigang From rem-conf Wed Aug 23 23:56:00 2000 From rem-conf-request@es.net Wed Aug 23 23:55:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RqqN-0006QC-00; Wed, 23 Aug 2000 23:50:31 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13RqqK-0006Q2-00; Wed, 23 Aug 2000 23:50:29 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id JAA19999; Thu, 24 Aug 2000 09:46:27 +0300 (IDT) Message-ID: <39A4C978.AFEBB761@bitband.com> Date: Thu, 24 Aug 2000 09:06:32 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Madan A S CC: rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <200008161458.QAA09198@mailhub.fokus.gmd.de> <39A0E43C.BDD9B4E0@bitband.com> <000801c00d32$9e9ba420$2aa509ca@madan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Madan A S wrote: > > With RTP on the other hand, it seems the load generated by each > transmitter > > is constant, and does not increase when pakcet loss or network delay > > increases. > > This is not entirely true when packet retransmission is added, but as long > > as this is true, i.e. there is a definitive upper limit on the load > generated by > > each particular client, there might be no need for an additional > congestion control > > mechanism, becasue with such an upper limit RTP will not cause a > congestion collapse. > > > > Would somebody mind explaining me, > Why the load generation from transmitter is CONSTANT in case of RTP ? To put it back into context - the bitrate is constant with respect to network behaviour, i.e. it does not change when network delay and packet loss chanmges. In otehrwords, there is an upper limit on the number of packets per second generated by any RTP sender, which does not change due to increased packet loss, contrary to TCP which DOES increase the number of packets per second transmitted when packets loss increased to overcome the lost packets. As to the unicast vs. multicast scenario, I do not think it matters, it is true that for unicast the actual packet rate is N times larger (where N is number of listeners), but there still is an upper limit, which does not change when packet loss (or network delay) increase. Also, I do not see a material difference here between unitact and multicast, after all multicast can be viewed as a set of unicast sessions where data for multiple listeners is duplicated by Routers (which are closer to the listener) rather then Servers at the source. Hope this helps, Leonid From rem-conf Thu Aug 24 03:08:22 2000 From rem-conf-request@es.net Thu Aug 24 03:08:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Rtqz-00018f-00; Thu, 24 Aug 2000 03:03:21 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Rtqx-00018V-00; Thu, 24 Aug 2000 03:03:19 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA17455; Thu, 24 Aug 2000 12:03:02 +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 xma017452; Thu, 24 Aug 00 12:03:03 +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 MAA05355; Thu, 24 Aug 2000 12:03: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 MAA17664; Thu, 24 Aug 2000 12:03:00 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900011063402; Thu, 24 Aug 2000 12:09:53 +0200 To: Cc: , , Subject: Re: New congestion control text in RTP spec Message-ID: <0056900011063402000002L022*@MHS> Date: Thu, 24 Aug 2000 12:09:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 08/24/00 12:05:30" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list zhigang.liu@nokia.com wrote: > > -----Original Message----- > > From: EXT Madan A S [mailto:madanas@eth.net] > > Sent: Tuesday, August 22, 2000 3:03 AM > > To: leonid@bitband.com; rem-conf@es.net > > Subject: Re: New congestion control text in RTP spec > > > > > > > With RTP on the other hand, it seems the load generated by each > > transmitter > > > is constant, and does not increase when pakcet loss or network de= lay > > > increases. > > > This is not entirely true when packet retransmission is > > added, but as long > > > as this is true, i.e. there is a definitive upper limit on the lo= ad > > generated by > > > each particular client, there might be no need for an additional > > congestion control > > > mechanism, becasue with such an upper limit RTP will not cause a > > congestion collapse. > > > > > > > Would somebody mind explaining me, > > Why the load generation from transmitter is CONSTANT in case of RTP= ? > > No, it isn't. For voice, a codec without silence suppression may gene= rate > constant RTP payload. However, if the silence suppression is turned o= n, > there will be no RTP packets generated during the silent periods, exc= ept > for some small packet carrying comfort noise information (if the CNG = is > switched on also). > > As to video, you probably all know it's VBR in nature. The load won't= be > constant unless you do some buffering. But this is probably not toler= able > for real-time video. RTP stands for real-time, anyway. > You should not confuse "real time" with the end-to-end delay issue. small E2E delay is a very strong requirement for videophony *only*, video broadcast (or even VOD) with several seconds of delay is quite OK. "> Why the load generation from transmitter is CONSTANT in case of RTP = ?" Well that depends, both cases are possible. Actually there is a continuum of possible rate variations, also "constant bit rate" is even tricky to define with codecs that support variable frame rates (MPEG-4), actually you can define it only with the addition of the end to end delay parameter and probably the buffer sizes. It is true that video codecs can be run in a "constant quality" mode and then potentially *extremely large* bit rate variations are pos= sible, and actually desirable. Specifically a camera monitoring a lobby would send almost nothing when the lobby is empty. Note that this kind of extremely static and long scenes is pretty rare in TV or Cinema content, because viewers have a strong tendency to get bored very fast :-) However this kind of thing is done for storage, for image quality optimization for exemple video CDROM (MPEG-1) and DVD (MPEG-2) are done somewhat in that way, with bit rate boundaries due to disk reader technology and MPEG standard (decoder buffer size). Note that the video codec of MPEG-4 offers more flexibility (non constant video frame rate, wider decoder buffer size range) and therefore can produce better quality using VBR mode, with potentially quite large "intantaneous" bit rate changes (specifically encoded frame size change, but also the frame rate can be reduced). So direct usage of this kind of content for VOD services would produce VBR videos. Also applying the same "best quality" encoding for broadcast would produce VBR videos. So you can expect that some RTP video will have variable "instantaneous" bit rates, because this is how you get better quality. *however* codecs can *also* be used with "more" rate control, and then you will get constant BR, with potentially large delays to compensate (buffering) instantaneous BR variations .... ********************* Furtheremore for digital TV broadcast statistical multiplexing is in use rigth now i.e. a set of real time video encoders are synchronized so that the sum of all BR is constant to fit the pipe size while individual BR change constantly according to an algorithm that tries to optimize quality for each stream. For exemple the NBC channel broadcast a basket match will get more BR, while ABC will get less because at the same time it is broadcasting a Goddard movie with very long very static scenes ... In that case you may get wide (and rapid too) BR changes for all streams ... with a constant sum ! This is what the broadcaster may want on the Internet too: assuming "they" are paying the *total* bandwidth, they will want to maximize quality at all cost inside that enveloppe. Although this could be done with a varying sum, which would be driven by some congestion control, but does the work discussed here cover that ? *************************** Also the business model is unclear to me - for broadcast (say using IP multicast) i.e. what would be the exact motivation of a broadcaster to reduce the BR (and therefore the quality) ? Because a certain number of users report congestion problems ? - for pay per view VOD, once the user has paid, it would difficult to reduce the BR and explain that he (she) is getting crappy quality because of congestion ? comments anybody ? > > I didn't follow this thread continuously (I'm currently busy with RTP= > header compression in rohc WG). So I'm not sure what kind of congesti= on > control you guys are talking about. To me, it looks like a more gener= al > problem of QoS (admission control, policing, blah, blah), which is no= t > specific to RTP. The picture in my mind is a big (perhaps not big in = some > cases) IP pipe which carries all kinds of IP flows (TCP, UDP, etc). > Congestion control can be only effective if all flows conform to some= > rules. (e.g. TCP is a little bit aggressive here). what do you mean by aggressive ? It is my understanding that if a UDP and TCP flow "fight" for bandwidth the TCP congestion control will cause the UDP stream to "win" ? does not sound like aggressive to me ? Isn't the issue that once all TCP flow are reduced to the min UDP (RTP actually) flows should start to behave and reduce BR too ? you mean you want to make sure TCP gets a "fair" share too, how would "fair" be defined ? Regards, -- Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com = From rem-conf Thu Aug 24 07:10:50 2000 From rem-conf-request@es.net Thu Aug 24 07:10:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13RxcB-0004Ze-00; Thu, 24 Aug 2000 07:04:19 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13Rxc9-0004ZI-00; Thu, 24 Aug 2000 07:04:17 -0700 Received: from [209.8.42.118] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 522569; Thu, 24 Aug 2000 10:07:39 -0400 Message-ID: <39A52C62.54D695C3@21rst-century.com> Date: Thu, 24 Aug 2000 10:08:35 -0400 From: Thomas 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: philippe.gentric@philips.com CC: zhigang.liu@nokia.com, madanas@ieee.org, leonid@bitband.com, rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <0056900011063402000002L022*@MHS> 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 Philippe; We have been sloppy in our use of terms such as "constant load". philippe.gentric@philips.com wrote: > zhigang.liu@nokia.com wrote: > > > > -----Original Message----- > > > From: EXT Madan A S [mailto:madanas@eth.net] > > > Sent: Tuesday, August 22, 2000 3:03 AM > > > To: leonid@bitband.com; rem-conf@es.net > > > Subject: Re: New congestion control text in RTP spec > > > > > > > > > > With RTP on the other hand, it seems the load generated by each > > > transmitter > > > > is constant, and does not increase when pakcet loss or network delay > > > > increases. > > > > This is not entirely true when packet retransmission is > > > added, but as long > > > > as this is true, i.e. there is a definitive upper limit on the load > > > generated by > > > > each particular client, there might be no need for an additional > > > congestion control > > > > mechanism, becasue with such an upper limit RTP will not cause a > > > congestion collapse. > > > > > > > > > > Would somebody mind explaining me, > > > Why the load generation from transmitter is CONSTANT in case of RTP ? > > > > No, it isn't. For voice, a codec without silence suppression may generate > > constant RTP payload. However, if the silence suppression is turned on, > > there will be no RTP packets generated during the silent periods, except > > for some small packet carrying comfort noise information (if the CNG is > > switched on also). > >' There is the rate being generated by the source, and the rate being pushed across the network. Even if the rate from the source is constant, in TCP slow start and congestion control will cause a constantly varying load. In a download type situation TCP will expand to fill whatever bandwidth is available. If there are multiple TCP download type sessions going on, then in a double average sense (both an ensemble average and an average over time), each session would get roughly 1/N of the available end to end bandwidth. This discussion started because the draft profile suggested (to me, at any rate), that a TCP like congestion control be the ideal for RTP/UDP sessions. This is not a good idea for the typical audio or video stream scenario. A RTP stream with layering can be reduced, but never increased above a certain level, while TCP file transfers can. In the absence of congestion, for a multicast RTP/UDP audio or video session, there is a roughly constant bit rate. (Yes, audio has constant bit rate and variable bit rate, and video can get even more complicated, but we are talking about the response to congestion and network conditions here - presumably the congestion does not depend on what is being broadcast !) The point simply is that if there were no other TCP or UDP traffic the RTP stream would use a certain number of bits per second on average; it wouldn't grow to fill the entire available bandwidth. In multicasting (if done right) every node in the network with a multicast stream would see the same (possible time variable) bit rate, call it r(t) In unicasting, for a given group size N, every node participating would see a bit rate >from the stream of at most N times r(t) and at least r(t). Now, Leonid is right in that, if N is a constant, so is the flow at a given node (ignoring variations in r(t)), but in most real world broadcasts N is not constant, so that the flow rate will change in unicasting, while in multicasting it is always either 1 or 0 times r(t). (Of course, all methods also have small control packets flowing back and forth, such as RTCP packets; generally the bit rates of these are small enough to ignored. In default rtp/rtcp, the real flow is about 1.05 x r(t), for example.) So, you could say loosely that RTP multicasts with no congestion control cause a "constant load" - what you really mean is that the load attempted is just r(t), independent of network conditions. > > > > ********************* > > Furtheremore for digital TV broadcast statistical multiplexing > is in use rigth now i.e. a set of real time video encoders > are synchronized so that the sum of all BR is constant > to fit the pipe size while individual BR change constantly > according to an algorithm that tries to optimize quality > for each stream. For exemple the NBC channel > broadcast a basket match will get more BR, > while ABC will get less because at the same time > it is broadcasting a Goddard movie with very long > very static scenes ... > > In that case you may get wide (and rapid too) BR changes > for all streams ... with a constant sum ! > > This is what the broadcaster may want on the Internet too: > assuming "they" are paying the *total* bandwidth, > they will want to maximize quality > at all cost inside that enveloppe. > > Although this could be done with a varying sum, > which would be driven by some congestion control, > but does the work discussed here cover that ? > Not in my opinion. This might work at the sender, but how could it work at the other end? Suppose Indiana watches the basketball game, but New York chooses to fall asleep during the Goddard movie - how does this even out ? > > *************************** > > Also the business model is unclear to me > > - for broadcast (say using IP multicast) > i.e. what would be the exact motivation > of a broadcaster to reduce the BR > (and therefore the quality) ? > Because a certain number of users report > congestion problems ? > I would argue that broadcasters would basically never reduce their bit rate on the commodity Internet, at least not in any dynamic fashion (neglecting VBR changes due to changing content). In large scale multicasts on the commodity Internet, someone will always be in trouble (i.e., dropping packets) SOMEWHERE. So, if the audience is large, having the broadcaster reduce the bit rate in case of loss somewhere is likely to lead to a "race to the bottom" and very poor quality for all., This is not a workable business model. In a campus setting, though (i.e., on a small sub-domain with more or less uniform connectivity and equipment everywhere) you might usefully take the viewpoint that a given level of congestion reports might mean an overload of the entire local network, and thus reduce the broadcast bitrate. This is especially true as a RTP video stream might be a substantial part of the backbone of a campus network, while it is a very small part of the capacity of the current Internet backbones. > > - for pay per view VOD, once the user has paid, > it would difficult to reduce the BR and explain > that he (she) is getting crappy quality because > of congestion ? > YES - unless it's so bad that there is no reception at all. This has got to be (with FEC) kept to a level comparable to broadcast TV - a few minutes per day at most. > > comments anybody ? > > > > > I didn't follow this thread continuously (I'm currently busy with RTP > > header compression in rohc WG). So I'm not sure what kind of congestion > > control you guys are talking about. To me, it looks like a more general > > problem of QoS (admission control, policing, blah, blah), which is not > > specific to RTP. The picture in my mind is a big (perhaps not big in some > > cases) IP pipe which carries all kinds of IP flows (TCP, UDP, etc). > > Congestion control can be only effective if all flows conform to some > > rules. (e.g. TCP is a little bit aggressive here). > > what do you mean by aggressive ? > It is my understanding that if a UDP and TCP flow > "fight" for bandwidth the TCP congestion control will > cause the UDP stream to "win" ? does not sound > like aggressive to me ? > > Isn't the issue that once all TCP flow are reduced to the min > UDP (RTP actually) flows should start to behave and reduce BR too ? > > you mean you want to make sure TCP gets a "fair" share too, > how would "fair" be defined ? > ' By aggressive we meant that a RTP stream should not back off every time it losses a few packets. In broadcasting, a human requests a RTP video or audio stream - it should be possible to get good reception and still surf the web or do downloads. If it is not, the customer will not use the service ! TCP is very aggressive from a streaming perspective. In slow start, it keeps doubling the bit rate until it uses up all of the available bandwidth, and then some. So, if your streaming has to co-exist with other local TCP sessions, there will be (short) periods when packets will be lost because of even small TCP file transfers. It's only on time scale longer than several RTTs that TCP can be viewed, on average, as being a friendly and fair service. I would argue that most congestion now-a-days is either at the source or at the receiver. Multicasting will take care of the source problem, so we are worried about the receiver. I still think that, if a recipient requests a RTP stream, it should just try and use the bandwidth requested (that is what I meant by "aggressive," and I think Leonid too), and TCP should (as it will) use the remaining bandwidth. If that doesn't work on a local network, then the user will get bad reception and the session should shut down or request less bandwidth (see below). This MIGHT cause problems on campus networks, but I have never heard any reports of this. It is highly unlikely to cause problems on the backbones. In the spirit of the Internet ("if it ain't broke, don't fix it"), I would say that adopting a TCP like congestion control as a standard for RTP is at best premature. I still think that the profile should just say that RTP receivers SHOULD monitor for dropped packets & jitter and SHOULD implement congestion control (shedding layers or terminating the session) if the packet loss reaches unacceptable levels over an extended period of time, and that anything more involved be left out of the standard until there is both a demonstrated need and a workable solution shown. To me, shutting things down if you are not getting a signal through seems like common sense, and it would take case of cases such as someone requesting a much bigger stream than the local network can handle. > > Regards, > > -- > Philippe Gentric > Software Architect > PHILIPS DIGITAL NETWORKS > Broadcast & Internet Delivery Solutions > Laboratoires d'Electronique Philips > B.P. 15 - 22, Av. Descartes > 94453 Limeil-Brevannes Cedex France > Phone : 33 (0)1 45 10 68 12 > Fax : 33 (0)1 45 10 69 60 > philippe.gentric@philips.com 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@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Thu Aug 24 12:16:05 2000 From rem-conf-request@es.net Thu Aug 24 12:16:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13S25x-0000Nd-00; Thu, 24 Aug 2000 11:51:21 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13S25v-0000NT-00; Thu, 24 Aug 2000 11:51:19 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id LAA31429; Thu, 24 Aug 2000 11:40:36 -0700 Message-Id: <3.0.3.32.20000824114245.00aea350@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 24 Aug 2000 11:42:45 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 8/30 The Future of Interactive Television -- Lawrence A. Rowe, Computer Science Division - EECS, U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar The Future of Interactive Television Wednesday August 30, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Lawrence A. Rowe Computer Science Division - EECS, U.C. Berkeley Traditional broadcast television programs are composed of one video stream, fixed image size, and fixed picture quality. Interaction is limited to changing channels unless you have access to a service like WebTV. Many companies are developing technology that will allow traditional television to be distributed over the Internet, so called "Internet TV." This talk will discuss features that can be exploited using Internet TV including multiple video streams, interaction between participants, and variable quality streams. In spite of these technical capabilities, most Internet Webcasts today are produced using traditional television technologies and are constrained to the limitations of traditional television broadcasting. Research on developing computer-based webcasting technology will be described that exploits capabilities of this new medium including broadcast management, video-effects processing, and live production control. The use of this technology to produce this seminar and the Berkeley Internet Broadcasting System (BIBS) Class Lecture Webcasts will be described. --------------- 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'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Thu Aug 24 13:19:23 2000 From rem-conf-request@es.net Thu Aug 24 13:19:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13S3IB-00021Z-00; Thu, 24 Aug 2000 13:08:03 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13S3I9-00021P-00; Thu, 24 Aug 2000 13:08:01 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id NAA12781 for rem-conf@es.net; Thu, 24 Aug 2000 13:07:57 -0700 Date: Thu, 24 Aug 2000 13:07:57 -0700 From: John Lazzaro Message-Id: <200008242007.NAA12781@snap.CS.Berkeley.EDU> To: rem-conf@es.net Subject: Re: New congestion control text in RTP spec X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [ Thomas Marshall Eubanks writes ] > By aggressive we meant that a RTP stream should not back off every time it > losses a few packets. In broadcasting, a human requests a RTP video or > audio stream - it should be possible to get good reception and still > surf the web or do downloads. If it is not, the customer will not use the > service ! But should TCP users of the affected shared links be at the mercy of Joe Sixpack's decision to shut off the IP-radio/TV? Once its clear to a unicast source that its receiver is getting unusable reception quality for significant periods of time, some sort of automatic congestion control seems in order (conceptually, a low-bandwidth "please stand by" screen, if you will, followed by a "disconnecting, please try later" message if things don't improve), rather than waiting for a human to give up on using a receiver application. I remember trying to get work done on the net during the first "Victoria's Secret" fashion show a few years ago, and it was pretty slow going -- on that day, at least, Joe Sixpack didn't seem to be turning off the IP-TV and giving up very quickly! ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Thu Aug 24 14:54:13 2000 From rem-conf-request@es.net Thu Aug 24 14:54:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13S4oo-0003u2-00; Thu, 24 Aug 2000 14:45:50 -0700 Received: from mgw-x2.nokia.com [131.228.20.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13S4om-0003ts-00; Thu, 24 Aug 2000 14:45:49 -0700 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e7OLh4Y22417; Fri, 25 Aug 2000 00:43:04 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Aug 2000 16:40:12 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B7ED@daeis05nok> From: zhigang.liu@nokia.com To: philippe.gentric@philips.com, zhigang.liu@nokia.com Cc: madanas@ieee.org, leonid@bitband.com, rem-conf@es.net Subject: RE: New congestion control text in RTP spec Date: Thu, 24 Aug 2000 16:39:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > You should not confuse "real time" with the end-to-end delay issue. > small E2E delay is a very strong requirement for videophony > *only*, video broadcast (or even VOD) with several seconds of > delay is quite OK. Well, I thought "real time" IS about "end-to-end" delay. But, maybe "real time" has a different meaning here (e.g. live)? I perfectly understand that video broadcast or streaming can tolerate some E2E delay. But I'm wondering if several seconds of delay can be still called "real time". Again, I'm now totally confused about the terminology of "real time"? ... (this part is omitted which I Agree) ... > *however* codecs can *also* be used with "more" rate control, > and then you will get constant BR, with potentially > large delays to compensate (buffering) instantaneous > BR variations .... Yes. If the buffer is considered part of the codec, then you can always smooth out the bit rate, with the cost of longer delay. ... (cut many lines here about multiplexing) ... Statistical multiplexing is one of the fundamental ideas for Internet. (e.g. Ethernet LAN, IP core network). > > > > I didn't follow this thread continuously (I'm currently > busy with RTP > > header compression in rohc WG). So I'm not sure what kind > of congestion > > control you guys are talking about. To me, it looks like a > more general > > problem of QoS (admission control, policing, blah, blah), > which is not > > specific to RTP. The picture in my mind is a big (perhaps > not big in some > > cases) IP pipe which carries all kinds of IP flows (TCP, UDP, etc). > > Congestion control can be only effective if all flows > conform to some > > rules. (e.g. TCP is a little bit aggressive here). > > > > what do you mean by aggressive ? > It is my understanding that if a UDP and TCP flow > "fight" for bandwidth the TCP congestion control will > cause the UDP stream to "win" ? does not sound > like aggressive to me ? By aggressive I mean TCP tries to take whatever it can. But on the other hand, you're right. It's also polite by reducing sliding window if the bandwidth is taken by other streams. > Isn't the issue that once all TCP flow are reduced to the min > UDP (RTP actually) flows should start to behave and reduce BR too ? Yes, it is. As I said, it looks more like a QoS issue. > you mean you want to make sure TCP gets a "fair" share too, > how would "fair" be defined ? Good question. Again, fairness a QoS issue, which is quite complicated. I'm not sure here is the right place to discuss it. But, the basic idea is that each IP flow (either UPD or TCP or whatever) will contract some QoS (e.g. average and peak throughput, maximum delay, etc.). Then some entity(ies) has to make sure each flow obeys the contract. But again, congestion control discussed here may be a different thing. It looks like voluntary self-control based on some guessing of network condition, not based on some QoS contract. Besides, is the congestion control per-flow based, or per protocol based (e.g. UDP or TCP), or aggregate (i.e. all IP flows from one node)? Zhigang From rem-conf Fri Aug 25 07:57:40 2000 From rem-conf-request@es.net Fri Aug 25 07:57:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SKoV-0004Kk-00; Fri, 25 Aug 2000 07:50:35 -0700 Received: from ns.interchange.ca (mail.interchange.ca) [216.126.79.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SKoS-0004KS-00; Fri, 25 Aug 2000 07:50:33 -0700 Received: by mail.interchange.ca (Fastmailer, from userid 555) id 0D1B39B55; Fri, 25 Aug 2000 10:50:02 -0400 (EDT) MIME-Version: 1.0 Message-Id: <39A68799.0001C1.03583@frodo.searchcanada.ca> Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_DVRUW1OPJZXOO49D7TH0" To: rem-conf@es.net Subject: RTP-HC Implementation From: "Mukhund Janardhanamurthy" X-Fastmail-IP: 202.86.152.220 Date: Fri, 25 Aug 2000 10:50:02 -0400 (EDT) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------Boundary-00=_DVRUW1OPJZXOO49D7TH0 Content-Type: Text/Plain Content-Transfer-Encoding: 7bit Hi, I am a final year student at MIT - Anna University, Chennai, INDIA. I am interested in networking and plan to implement RTP header compression on the lines of RFC2508 as my project. But I need help on how exactly to implement this (like: how to implement it as a seperate layer between IP and, say PPP) and which programming language is best suited for this purpose. Any suggestions and advice are gladly welcome. With regards, Mukhund. _________________________________________________________________ http://fastmail.ca/ - Fast Free Web Email for Canadians --------------Boundary-00=_DVRUW1OPJZXOO49D7TH0-- From rem-conf Fri Aug 25 08:50:23 2000 From rem-conf-request@es.net Fri Aug 25 08:50:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SLjJ-0005ix-00; Fri, 25 Aug 2000 08:49:17 -0700 Received: from purple.cs.ucl.ac.uk [128.16.64.86] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SLjH-0005ij-00; Fri, 25 Aug 2000 08:49:16 -0700 Received: from purple.cs.ucl.ac.uk (localhost [127.0.0.1]) by purple.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id QAA01356; Fri, 25 Aug 2000 16:49:51 +0100 Message-Id: <200008251549.QAA01356@purple.cs.ucl.ac.uk> To: rem-conf@es.net Subject: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt cc: 4on2andIP-sys@advent.ee.columbia.edu Date: Fri, 25 Aug 2000 16:49:51 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the IETF AVT working group and the ad-hoc group on transport of MPEG4-on-IP: The IETF Audio/Video Transport working group has received a request to publish http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-03.txt the "RTP payload format for MPEG-4 Audio/Visual streams" as a proposed standard. Accordingly, this message starts a two week working group last call for comments on this draft. All comments should be sent to the AVT working group mailing list by 8th September 2000. At this time we will make our decision whether or not to request IESG approval for publication, based on the consensus of replies. We particularly value input from the MPEG committee as to technical correctness and the appropriate nature of this specification. It is our intent that this payload format is complementary to the ongoing work in MPEG defining a general framework for transport of the MPEG-4 Systems environment. If this intent is not reflected in the draft, we value comment with detailed and specific suggestions for change. Note that we had originally planned to issue this working group last call after the forthcoming MPEG meeting. However, time constraints imposed by the ITU-T schedule for publication of the next version of H.323 require that we issue this last call early. We hope that this will not cause undue problems, and look forward to your input. Thanks, Colin Perkins (IETF AVT co-chair) From rem-conf Fri Aug 25 13:11:59 2000 From rem-conf-request@es.net Fri Aug 25 13:11:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SPio-0001EQ-00; Fri, 25 Aug 2000 13:05:02 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13SPim-0001EC-00; Fri, 25 Aug 2000 13:05:00 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 25 Aug 2000 15:03:01 UT Subject: Define a unicast RTP session. To: rem-conf@es.net From: Vincent_Virgilio@nmss.com Date: Fri, 25 Aug 2000 14:59:27 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/25/2000 04:04:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, A simple question: If there is a single conversation between two RTP implementations, i.e. two oppositely directed RTP packet flows, using UDP over _unicast_ IP, how many sessions are there: one or two? If there are two sessions, does that mean that the sessions are each defined by one and only one destination transport address pair? Seems like the obvious answer would be yes. If, instead, there is one session, does that mean that the session is defined by two destination transport address pairs? Again, the obvious answer would seem to be yes. Further, if this is the case, does the wording of the RFC in the definition of a session allow the destination port pairs to differ, in addition to the network addresses? Sincerely, Vince Virgilio Natural Microsystems From rem-conf Fri Aug 25 13:20:13 2000 From rem-conf-request@es.net Fri Aug 25 13:20:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SPuP-0001sj-00; Fri, 25 Aug 2000 13:17:01 -0700 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SPuO-0001hW-00; Fri, 25 Aug 2000 13:17:00 -0700 Received: from savage.entera.com ([10.0.1.19]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with ESMTP id com; Fri, 25 Aug 2000 13:16:38 -0700 Received: from localhost ([127.0.0.1] helo=entera.com ident=ronf) by savage.entera.com with esmtp (Exim 3.12 #1 (Debian)) id 13SPtP-0000y5-00; Fri, 25 Aug 2000 13:15:59 -0700 X-Mailer: exmh version 2.1.1 10/15/1999 (debian) To: Henning Schulzrinne cc: Flemming Andreasen , rem-conf@es.net Subject: Re: Timestamp/sequence# following SSRC collision In-Reply-To: Message from Henning Schulzrinne of "Sun, 20 Aug 2000 17:44:34 -0400." <39A05142.2C80BACD@cs.columbia.edu> References: <39975A36.5BFBB0FD@cisco.com> <39A05142.2C80BACD@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2000 13:15:58 -0700 From: ronf@entera.com (Ron Frederick) Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <39A05142.2C80BACD@cs.columbia.edu> you write: > From the viewpoint of the sender (and the one changing the SSRC), it's > easier to keep the sequence number and timestamp progression going, > particularly if the two pieces of code are separate. Thus, I would > certainly not want to prescribe a change. (A receiver is ill-advised to > fail if for some reason there's a ts/seq. no discontinuity, so it should > be ok either way.) > My assumption was that this would be one piece of code, since at the time you generate each packet you are filling in all of the sequence number, timestamp, and SSRC. However, I agree that it should be ok either way and it is probably best for the RTP spec to not require either behavior. -- Ron Frederick ronf@entera.com From rem-conf Fri Aug 25 18:04:20 2000 From rem-conf-request@es.net Fri Aug 25 18:04:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SUK3-0005ON-00; Fri, 25 Aug 2000 17:59:47 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SUK1-0005OD-00; Fri, 25 Aug 2000 17:59:46 -0700 Received: from Young ([150.183.107.207]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000082610001360:16414 ; Sat, 26 Aug 2000 10:00:13 +0900 Message-ID: <008e01c00ef8$dc7de3d0$cf6bb796@Young> From: =?ks_c_5601-1987?B?wNO/tbHHXCjF18Wpv/7AzFwp?= To: , "Colin Perkins" Cc: <4on2andIP-sys@advent.ee.columbia.edu> References: <200008251549.QAA01356@purple.cs.ucl.ac.uk> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Sat, 26 Aug 2000 09:59:17 +0900 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-08-26 10:00:13 AM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-08-26 10:00:24 AM, Serialize complete at 2000-08-26 10:00:24 AM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ks_c_5601-1987" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RGVhciBDb2xpbiwNCg0KPiBUbyB0aGUgSUVURiBBVlQgd29ya2luZyBncm91cCBhbmQgdGhlIGFk LWhvYyBncm91cCBvbiB0cmFuc3BvcnQgb2YgTVBFRzQtb24tSVA6DQo+IA0KPiBUaGUgSUVURiBB dWRpby9WaWRlbyBUcmFuc3BvcnQgd29ya2luZyBncm91cCBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0 IHRvIHB1Ymxpc2gNCj4gICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtYXZ0LXJ0cC1tcGVnNC1lcy0wMy50eHQNCj4gdGhlICJSVFAgcGF5bG9hZCBmb3Jt YXQgZm9yIE1QRUctNCBBdWRpby9WaXN1YWwgc3RyZWFtcyIgYXMgYSBwcm9wb3NlZCBzdGFuZGFy ZC4NCg0KVGhhbmsgeW91IGZvciB0aGUgYW5ub3VuY2VtZW50Lg0KDQo+IA0KPiBBY2NvcmRpbmds eSwgdGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IGZvciBjb21tZW50cw0KPiBvbiB0aGlzIGRyYWZ0LiBBbGwgY29tbWVudHMgc2hvdWxkIGJlIHNl bnQgdG8gdGhlIEFWVCB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA8cmVtLWNvbmZAZXMu bmV0PiBieSA4dGggU2VwdGVtYmVyIDIwMDAuIEF0IHRoaXMgdGltZSB3ZSB3aWxsIG1ha2Ugb3Vy IGRlY2lzaW9uDQo+IHdoZXRoZXIgb3Igbm90IHRvIHJlcXVlc3QgSUVTRyBhcHByb3ZhbCBmb3Ig cHVibGljYXRpb24sIGJhc2VkIG9uIHRoZSBjb25zZW5zdXMNCj4gb2YgcmVwbGllcy4NCj4gDQo+ IFdlIHBhcnRpY3VsYXJseSB2YWx1ZSBpbnB1dCBmcm9tIHRoZSBNUEVHIGNvbW1pdHRlZSBhcyB0 byB0ZWNobmljYWwgY29ycmVjdG5lc3MNCj4gYW5kIHRoZSBhcHByb3ByaWF0ZSBuYXR1cmUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLiBJdCBpcyBvdXIgaW50ZW50IHRoYXQgdGhpcw0KPiBwYXlsb2Fk IGZvcm1hdCBpcyBjb21wbGVtZW50YXJ5IHRvIHRoZSBvbmdvaW5nIHdvcmsgaW4gTVBFRyBkZWZp bmluZyBhIGdlbmVyYWwNCj4gZnJhbWV3b3JrIGZvciB0cmFuc3BvcnQgb2YgdGhlIE1QRUctNCBT eXN0ZW1zIGVudmlyb25tZW50LiBJZiB0aGlzIGludGVudCBpcyBub3QNCj4gcmVmbGVjdGVkIGlu IHRoZSBkcmFmdCwgd2UgdmFsdWUgY29tbWVudCB3aXRoIGRldGFpbGVkIGFuZCBzcGVjaWZpYyBz dWdnZXN0aW9ucw0KPiBmb3IgY2hhbmdlLiANCj4gDQoNCkFzIHlvdSBrbm93LCB3ZSB3aWxsIGhh dmUgYSBtZWV0aW5nIG9uIDZ0aCBTZXB0ZW1iZXIuIEFmdGVyIHRoaXMgbWVldGluZyB3ZSBjYW4g bWFrZSBhIGNvbW1lbnQgZnJvbSBNUEVHIGNvbW1pdHRlZSB0byBJRVRGIEFWVCB3b3JraW5nIGdy b3VwIG9uIHRoaXMgcHJvcG9zYWwgYmFzZWQgb24gdGhlIGNvbnNlbnN1cyBvZiB0aGlzIEFIRyBn cm91cC4gQWNjb3JkaW5nIHRvIHRoZSBkaXNjdXNzaW9ucyB3ZSBoYWQgc28gZmFyLCB0aGlzIHBy b3Bvc2FsIGlzIHZlcnkgdXNlZnVsIGZvciBzb21lIHNwZWNpZmljIGNhc2VzIGJ1dCBjYW4gbm90 IGJlIGEgZ2VuZXJhbCBzb2x1dGlvbiBhbmQgbWlnaHQgY2F1c2Ugc29tZSBwcm9ibGVtIG9uIGlu dGVyb3BlcmFiaWxpdHkuIFNvLCB3ZSB3aWxsIGRpc2N1c3Mgc3VnZ2VzdGlvbnMgZm9yIGNoYW5n ZSB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgd2UgaGF2ZSBub3cgYXQgdGhlIGNvbW1pbmcgQUhH IG1lZXRpbmcgYW5kIG1ha2UgYSBjb21tZW50cyBmb3JtYWxseS4NCg0KQlRXLCBob3cgY2FuIEkg c3Vic2NyaWJlIHJlbS1jb25mIHJlZmxlY3Rvcj8NCg0KWW91bmctS3dvbiBMSU0gKGNvLWNoYWly IG9mIEFIRyBvbiBNUEVHLTQgY29udGVudCBvbiBJUCBuZXR3b3JrKQ0K From rem-conf Sat Aug 26 11:07:01 2000 From rem-conf-request@es.net Sat Aug 26 11:07:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SkBX-0006A5-00; Sat, 26 Aug 2000 10:56:03 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SkBV-00069v-00; Sat, 26 Aug 2000 10:56:01 -0700 Received: from dynamicsoft.com (1Cust23.tnt2.freehold.nj.da.uu.net [63.17.114.23]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA16494; Sat, 26 Aug 2000 13:57:34 -0400 (EDT) Message-ID: <39A80455.4188B61C@dynamicsoft.com> Date: Sat, 26 Aug 2000 13:54:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vincent_Virgilio@nmss.com CC: rem-conf@es.net Subject: Re: Define a unicast RTP session. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vincent_Virgilio@nmss.com wrote: > > Hello, > > A simple question: > > If there is a single conversation between two RTP implementations, i.e. two > oppositely directed RTP packet flows, using UDP over _unicast_ IP, how many > sessions are there: one or two? Two. > > If there are two sessions, does that mean that the sessions are each > defined by one and only one destination transport address pair? Seems like > the obvious answer would be yes. Yes (pair being even,even+1) Unicast RTP is used extensively by SIP/SDP. Check out the appendices of rfc2543 which describe SDPs usage for unicast RTP sessions within SIP. -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: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Sun Aug 27 03:34:01 2000 From rem-conf-request@es.net Sun Aug 27 03:34:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13SzZ3-0006lK-00; Sun, 27 Aug 2000 03:21:21 -0700 Received: from csperkins.demon.co.uk (purple.cs.ucl.ac.uk) [193.237.26.84] by mail1.es.net with esmtp (Exim 1.81 #2) id 13SzYz-0006lA-00; Sun, 27 Aug 2000 03:21:19 -0700 Received: from purple.cs.ucl.ac.uk (localhost [127.0.0.1]) by purple.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id LAA02556; Sun, 27 Aug 2000 11:19:50 +0100 Message-Id: <200008271019.LAA02556@purple.cs.ucl.ac.uk> To: young@techway.co.kr cc: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt In-Reply-To: Message from " \( \)" of "Sat, 26 Aug 2000 09:59:17 +0900." <008e01c00ef8$dc7de3d0$cf6bb796@Young> Date: Sun, 27 Aug 2000 11:19:50 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Young-Kwon LIM writes: >As you know, we will have a meeting on 6th September. After this meeting >we can make a comment from MPEG committee to IETF AVT working group on >this proposal based on the consensus of this AHG group. According to the >discussions we had so far, this proposal is very useful for some specific >cases but can not be a general solution and might cause some problem on >interoperability. So, we will discuss suggestions for change to meet the >requirements we have now at the comming AHG meeting and make a comments >formally. We look forward to your input. When considering changes, please be aware of the very short time constraint imposed by the ITU timetable, which may limit our scope for modification of this proposal. >BTW, how can I subscribe rem-conf reflector? Send a message to with the word "subscribe" in the body. Regards, Colin From rem-conf Mon Aug 28 00:07:59 2000 From rem-conf-request@es.net Mon Aug 28 00:07:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TIvM-0001dQ-00; Mon, 28 Aug 2000 00:01:40 -0700 Received: from gw-nl4.philips.com [192.68.44.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TIvK-0001dG-00; Mon, 28 Aug 2000 00:01:38 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id JAA06458; Mon, 28 Aug 2000 09:01:36 +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 xma006456; Mon, 28 Aug 00 09:01:36 +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 JAA29880; Mon, 28 Aug 2000 09:01:36 +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 JAA20482; Mon, 28 Aug 2000 09:01:35 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900011226707; Mon, 28 Aug 2000 09:08:27 +0200 To: Cc: Subject: Re: New congestion control text in RTP spec Message-ID: <0056900011226707000002L072*@MHS> Date: Mon, 28 Aug 2000 09:08:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 08/28/00 09:05:23" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list zhigang.liu@nokia.com wrote: > > You should not confuse "real time" with the end-to-end delay issue.= > > small E2E delay is a very strong requirement for videophony > > *only*, video broadcast (or even VOD) with several seconds of > > delay is quite OK. > > Well, I thought "real time" IS about "end-to-end" delay. But, > maybe "real time" has a different meaning here (e.g. live)? > I perfectly understand that video broadcast or streaming can > tolerate some E2E delay. But I'm wondering if several seconds > of delay can be still called "real time". Again, I'm now > totally confused about the terminology of "real time"? > > ... to me, it is real-time compared to download: you start seeing (or hearing) -almost- as soon as you start receiving, also "live" is possible i.e. you can stream an event with *only* a few seconds of delay -- Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com = From rem-conf Mon Aug 28 02:31:00 2000 From rem-conf-request@es.net Mon Aug 28 02:30:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TLDo-0003eD-00; Mon, 28 Aug 2000 02:28:52 -0700 Received: from (f1engine.clair.net) [207.219.65.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TLDm-0003e3-00; Mon, 28 Aug 2000 02:28:50 -0700 Received: from 209.136.189.213 ([209.136.189.213]) by f1engine.clair.net (8.8.5/SCO5) with SMTP id DAA05972; Mon, 28 Aug 2000 03:26:48 -0500 (EST) From: jip5@aol.com Message-Id: <200008280826.DAA05972@f1engine.clair.net> To: hgt3@aol.com Subject: INCREASE SALES WITH MAJOR CREDIT CARDS .. Date: Mon, 28 Aug 00 05:33:17 Eastern Daylight Time Reply-To: jip5@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; -98% OF OUR APPLICANTS ARE ACCEPTED
-TERMINALS & PRINTERS OR PROCESS
DIRECTLY THROUGH YOU WEBSITE OR P.C.
-0 DOWN W/GOOD CREDIT,
-NO APPLICATION FEE WITH THIS AD.
-LOWEST RATES, LOW MONTHLY PAYMENTS
-ASK ABOUT OUR $100 CASH BACK!!

CALL NOW!! 800-487-9955

Also, complete Virtual Storefront
packages are available. You just add your product, service or idea.

 From rem-conf Mon Aug 28 02:40:37 2000 From rem-conf-request@es.net Mon Aug 28 02:40:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TLO5-0004UL-00; Mon, 28 Aug 2000 02:39:29 -0700 Received: from ns2.multicasttech.com (multicasttech.com) [63.105.122.8] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13TLO4-0004So-00; Mon, 28 Aug 2000 02:39:28 -0700 Received: from [209.8.42.31] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 523240; Mon, 28 Aug 2000 05:42:14 -0400 Message-ID: <39AA3450.C2EBC2A3@21rst-century.com> Date: Mon, 28 Aug 2000 05:43:45 -0400 From: Thomas 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: philippe.gentric@philips.com CC: zhigang.liu@nokia.com, rem-conf@es.net Subject: Re: New congestion control text in RTP spec References: <0056900011226707000002L072*@MHS> 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 philippe.gentric@philips.com wrote: > zhigang.liu@nokia.com wrote: > > > > You should not confuse "real time" with the end-to-end delay issue. > > > small E2E delay is a very strong requirement for videophony > > > *only*, video broadcast (or even VOD) with several seconds of > > > delay is quite OK. > > > > Well, I thought "real time" IS about "end-to-end" delay. But, > > maybe "real time" has a different meaning here (e.g. live)? > > I perfectly understand that video broadcast or streaming can > > tolerate some E2E delay. But I'm wondering if several seconds > > of delay can be still called "real time". Again, I'm now > > totally confused about the terminology of "real time"? > > > > ... > > to me, > it is real-time compared to download: you start seeing (or > hearing) -almost- as soon as you start receiving, > also "live" is possible i.e. you can stream an event > with *only* a few seconds of delay > > -- > Philippe Gentric > Software Architect > PHILIPS DIGITAL NETWORKS > Broadcast & Internet Delivery Solutions > Laboratoires d'Electronique Philips > B.P. 15 - 22, Av. Descartes > 94453 Limeil-Brevannes Cedex France > Phone : 33 (0)1 45 10 68 12 > Fax : 33 (0)1 45 10 69 60 > philippe.gentric@philips.com Dear Philippe; In this country it is routine for radio stations to operate on a 8 second delay; this is still considered "live". If you are operating a audio or video conference, then I believe that any one way delay over about 250 milliseconds leads to human protocol errors (i.e., people start interrupting each other, etc.), and yet phone conversations are possible with delays up to over a second. I would suggest the following terminology : Real time : Delays (including codec delays, buffering, etc.) that are short enough that an audio or video conference is possible (ideally no more than 250 milliseconds). Live : Delays (including codec delays, buffering, etc.) of 10 seconds or less. Any delay much more than this, and live reporting (of sports events, say), will suffer in comparison with terrestrial broadcasts. Note that a 10 second delay need not mean a 10 second wait before the playback starts. 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@on-the-i.com http://www.on-the-i.com http://www.buzzwaves.com From rem-conf Mon Aug 28 07:20:18 2000 From rem-conf-request@es.net Mon Aug 28 07:20:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TPe8-0000Kb-00; Mon, 28 Aug 2000 07:12:20 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TPe7-0000KR-00; Mon, 28 Aug 2000 07:12:19 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09867; Mon, 28 Aug 2000 10:12:15 -0400 (EDT) Message-Id: <200008281412.KAA09867@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: Registration of parityfec MIME types to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 28 Aug 2000 10:12:15 -0400 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider the following Internet-Drafts as Proposed Standards: Registration of parityfec MIME types RTP Payload Format for DV Format Video The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-fecmime-01.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-video-03.txt From rem-conf Mon Aug 28 08:26:11 2000 From rem-conf-request@es.net Mon Aug 28 08:26:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TQjW-0001n5-00; Mon, 28 Aug 2000 08:21:58 -0700 Received: from smptout.kasenna.com (smtp.kasenna.wan) [63.206.76.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TQjU-0001mv-00; Mon, 28 Aug 2000 08:21:56 -0700 Received: from kasenna.com ([10.10.0.51]) by smtp.kasenna.wan (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA75579; Mon, 28 Aug 2000 08:16:32 -0700 (PDT) Sender: kordale@kasenna.com Message-ID: <39AA82C4.3A48EA5F@kasenna.com> Date: Mon, 28 Aug 2000 08:18:28 -0700 From: Ram Kordale Organization: Kasenna X-Mailer: Mozilla 4.7 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, confctrl@isi.edu CC: Ram Kordale Subject: RTSP: Aggregate vs non-aggregate control Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a question on what RTSP requires in the following scenario. If a server responds to an RTSP DESCRIBE message with an SDP description with an aggregate URL, what does the RTSP RFC say about control over individual tracks. For example, could a client send PLAY and PAUSE messages for individual tracks? Should a server be expected to deny such a request? I don't see why such requests cannot be made but the RFC has examples that deny such requests. Thanks. Ram -- Ram Kordale Kasenna Inc. From rem-conf Mon Aug 28 10:16:50 2000 From rem-conf-request@es.net Mon Aug 28 10:16:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TSSI-0003xh-00; Mon, 28 Aug 2000 10:12:18 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13TSSH-0003xM-00; Mon, 28 Aug 2000 10:12:17 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 28 Aug 2000 12:10:17 UT Subject: Re: Define a unicast RTP session. To: Jonathan Rosenberg , schulzrinne@cs.colombia.edu Cc: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Mon, 28 Aug 2000 12:11:44 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/28/2000 01:12:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan Rosenberg wrote: >Vincent_Virgilio@nmss.com wrote: >> >> Hello, >> >> A simple question: >> >> If there is a single conversation between two RTP implementations, i.e. two >> oppositely directed RTP packet flows, using UDP over _unicast_ IP, how many >> sessions are there: one or two? > >Two. >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: (732) 741-7244 >http://www.dynamicsoft.com I am surprised. I expected the answer to be "one" because . . . Doesn't the definition of a _single_ RTP session in RFC 1889 say/imply that for unicast there will be several (RTP/RTCP) destination transport addresses per session (one for each participant), which at least differ in their network part? Doesn't the SSRC collision logic apply (in a trivial way) to unicast sessions too, i.e. there can be a collision between the two sources in a two participant session? If a session was from sender to receiver only, how could senders detect a collision in a session of any size, besides the "roundabout " way of RTCP? Or was collision detection through RTCP intended? It seems that the design of RTCP permits sessions to contain bidirectional flows, since the sender reports also contain receiver information, thus correlating two opposite flows. The H.323 recommendation seems to imply the same, by mandating a single destination port ("common channel") for sender and receiver reports from a single endpoint. More argumentum ad H.323. Paragraph eight of section 6.2.8.2 says that one can open a "reverse logical channel" (RTP flow) and add it to an existing RTP session. Thus there would then be two oppositely directed flows in an RTP session. William Stallings, in _High Speed Networks_ (p. 287) defines a single unicast RTP session to contain a _set_ of IP addresses, with a common RTP destination port. Again, this implies bidirectional flow to me. Finally, how shall two oppositely directed RTP flows in a two-party conversation appear in the RTP MIB session table, as two entries or as one? Your answer suggests two entries. Is that what the MIB authors want? I read the SIP glossary, appendix and some of SDP. They say there may be one or more RTP sessions in an SDP session, but do not comment on the nature of an RTP session. The mechanics of SDP session negotiation may be critical here; I haven't digested that yet. Still, I venture that a unicast RTP session defined by multiple destination transport addresses (one unique pair for each participant) fits in with SIP and SDP usage. So I am still trying to understand your answer. Vince Virgilio From rem-conf Mon Aug 28 11:40:29 2000 From rem-conf-request@es.net Mon Aug 28 11:40:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TTjv-0005af-00; Mon, 28 Aug 2000 11:34:35 -0700 Received: from prognet.com [205.219.198.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TTjt-0005ZK-00; Mon, 28 Aug 2000 11:34:33 -0700 Received: from robla350 ([172.22.101.226]) by prognet.com (8.9.2/8.9.0) with ESMTP id LAA29864; Mon, 28 Aug 2000 11:34:40 -0700 (PDT) Message-Id: <4.2.0.58.20000828113039.019d45d0@goobox.prognet.com> X-Sender: robla@goobox.prognet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 28 Aug 2000 11:34:21 -0700 To: Ram Kordale , rem-conf@es.net, confctrl@ISI.EDU From: Rob Lanphier Subject: Re: RTSP: Aggregate vs non-aggregate control Cc: Ram Kordale In-Reply-To: <39AA82C4.3A48EA5F@kasenna.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 There's nothing prohibiting a client from issuing PLAY and PAUSE on individual tracks, but to the best of my knowledge, there aren't any servers out there that implement per-track control on aggregate streams. So, in the interest of interoperability, a client should be able to fall back to aggregate control in the cases where per-track control fails. Rob At 08:18 AM 8/28/00 -0700, Ram Kordale wrote: >I have a question on what RTSP requires in the following scenario. > >If a server responds to an RTSP DESCRIBE message with an SDP description >with an aggregate URL, what does the RTSP RFC say about control over >individual tracks. For example, could a client send PLAY and PAUSE >messages for individual tracks? Should a server be expected to deny such >a request? > >I don't see why such requests cannot be made but the RFC has examples >that deny such requests. > >Thanks. >Ram >-- > >Ram Kordale >Kasenna Inc. From rem-conf Mon Aug 28 13:31:51 2000 From rem-conf-request@es.net Mon Aug 28 13:31:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TVUg-00007X-00; Mon, 28 Aug 2000 13:26:58 -0700 Received: from (mail.videonext.com) [207.207.157.236] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TVUf-00007N-00; Mon, 28 Aug 2000 13:26:57 -0700 Received: from bpirko ([207.207.178.35]) by mail.videonext.com (8.9.3/8.9.3) with SMTP id QAA30651 for ; Mon, 28 Aug 2000 16:07:19 -0400 From: "Brian Pirko" To: Subject: video conferencing list Date: Mon, 28 Aug 2000 16:27:59 -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.2919.6700 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello - I am interested in joining a videoconferencing email list. bpirko@videonext.com From rem-conf Mon Aug 28 13:50:40 2000 From rem-conf-request@es.net Mon Aug 28 13:50:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TVo5-0001EC-00; Mon, 28 Aug 2000 13:47:01 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13TVo4-0001E2-00; Mon, 28 Aug 2000 13:47:00 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 28 Aug 2000 15:45:00 UT Subject: Re: Define a unicast RTP session. To: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Mon, 28 Aug 2000 15:46:28 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/28/2000 04:46:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Jonathan Rosenberg wrote: > >>Vincent_Virgilio@nmss.com wrote: >>> >>> Hello, >>> >>> A simple question: >>> >>> If there is a single conversation between two RTP implementations, i.e. two >>> oppositely directed RTP packet flows, using UDP over _unicast_ IP, how many >>> sessions are there: one or two? >> >>Two. >>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: (732) 741-7244 >>http://www.dynamicsoft.com >>I am surprised. I expected the answer to be "one" because . . . > - Doesn't the definition of a _single_ RTP session in RFC 1889 say/imply that for unicast there will be several (RTP/RTCP) destination >transport addresses per session (one for each participant), which at least differ in their network part? > - Doesn't the SSRC collision logic apply (in a trivial way) to unicast sessions too, i.e. there can be a collision between the two sources in a two >participant session? If a session was from sender to receiver only, how could senders detect a collision in a session of any size, besides the >"roundabout " way of RTCP? Or was collision detection through RTCP intended? > - It seems that the design of RTCP permits sessions to contain bidirectional flows, since the sender reports also contain receiver information, >thus correlating two opposite flows. The H.323 recommendation seems to imply the same, by mandating a single destination port ("common >channel") for sender and receiver reports from a single endpoint. > - More argumentum ad H.323. Paragraph eight of section 6.2.8.2 says that one can open a "reverse logical channel" (RTP flow) and add it to >an existing RTP session. Thus there would then be two oppositely directed flows in an RTP session. > - William Stallings, in _High Speed Networks_ (p. 287) defines a single unicast RTP session to contain a _set_ of IP addresses, with a >common RTP destination port. Again, this implies bidirectional flow to me. > - Finally, how shall two oppositely directed RTP flows in a two-party conversation appear in the RTP MIB session table, as two entries or as >one? Your answer suggests two entries. Is that what the MIB authors want? >I read the SIP glossary, appendix and some of SDP. They say there may be one or more RTP sessions in an SDP session, but do not >comment on the nature of an RTP session. The mechanics of SDP session negotiation may be critical here; I haven't digested that yet. Still, I >venture that a unicast RTP session defined by multiple destination transport addresses (one unique pair for each participant) fits in with SIP >and SDP usage. So I am still trying to understand your answer. >Vince Virgilio I (Vince) put forth one more desparate point. There is something that satisfies my expectation very nicely; in fact, I think it meets and proves it! >From the RTP FAQ (http://www.cs.columbia.edu/~hgs/rtp/faq.html#unicast_ports): Q: How are ports assigned for [here it comes] bidirectional unicast RTP sessions? A: Each side in a bidirectional RTP connection [indeed such a creature exists] assigns their source ports independently, i.e., there is no assumption that if Alice sends audio to Bob on port 5000 (and RTCP on 5001), Alice also has to receive audio on port 5000. (Imposing such a restriction on ports would make it difficult for a host to participate in several independent RTP sessions using different tools.) Each side in a unicast session simply indicates to the other side where it wants to receive RTP packets, e.g., using SDP. Section 10 of RFC 1889 says: In a unicast session, applications SHOULD be prepared to receive RTP data and control on one port pair and send to another. Note that the SSRC values used for each source are always different This is what I've been looking for, something that explicitly says there can be bidirectional unicast RTP sessions. And that the destination ports can differ. Vince Virgilio From rem-conf Mon Aug 28 14:36:29 2000 From rem-conf-request@es.net Mon Aug 28 14:36:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TWVu-0002tA-00; Mon, 28 Aug 2000 14:32:18 -0700 Received: from wally.packetvideo.com [209.101.176.195] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TWVt-0002t0-00; Mon, 28 Aug 2000 14:32:17 -0700 Received: from misty.packetvideo.com (packetvideo.com [209.101.176.201]) by wally.packetvideo.com (Postfix) with ESMTP id 1E1DDC5AC for ; Mon, 28 Aug 2000 14:32:17 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Aug 2000 14:33:16 -0700 Message-ID: <72660A24B978D411BB8A00B0D03DFE011B54AE@MISTY> From: Ralph Neff To: rem-conf@es.net Subject: RE: Define a unicast RTP session. Date: Mon, 28 Aug 2000 14:33:11 -0700 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 Vince, Thanks for bringing this up; I was wondering the same thing myself. However, I think it should be clarified that the text you included from the FAQ is not actually in the RTP spec (rfc1889), but rather in a revision to rfc1889 that is currently in internet-draft stage in avt. This draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-08.txt The original rfc1889 seems (to me at least) to imply that all participants in a unicast session are supposed to use a single "common port pair" (see Section 3 of rfc1889, definition of an RTP Session). I think the text of the new draft makes much more sense. -Ralph Neff -----------(original message)-------------- > Section 10 of RFC 1889 says: > > In a unicast session, applications SHOULD be prepared to receive RTP > data and control on one port pair and send to another. Note that the > SSRC values used for each source are always different > > This is what I've been looking for, something that explicitly says there > can be bidirectional unicast RTP sessions. And that the destination ports > can differ. > > Vince Virgilio From rem-conf Tue Aug 29 07:34:25 2000 From rem-conf-request@es.net Tue Aug 29 07:34:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TmQf-0005nf-00; Tue, 29 Aug 2000 07:31:57 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TmQe-0005nU-00; Tue, 29 Aug 2000 07:31:56 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA12299 for ; Tue, 29 Aug 2000 07:31:55 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id HAA20622 for rem-conf@es.net; Tue, 29 Aug 2000 07:31:51 -0700 (PDT) Date: Tue, 29 Aug 2000 07:31:51 -0700 (PDT) Message-Id: <200008291431.HAA20622@rum.isi.edu> To: rem-conf@es.net Subject: SIGCOMM live Internet MBone transmission X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ACM SIGCOMM 2000 Conference Multicast transmission on the Internet Wed August 30 - Fri Sept 1, 2000 http://www.acm.org/sigcomm/sigcomm2000 SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. Multicast transmission on the Internet We will multicast video and audio from the technical sessions of the onference live on the Internet. The transmission will start Wednesday August 30 at 9:00 and end Friday September 1 at 13:30. The local timezone is CEST (GMT+2). See the conference program for time details (URL above). The conference can be received using the free Marratech player software, as well as the standard MBone tools. Please visit Marratech's web page for further technical information on the transmission from SIGCOMM as well as download instructions for their software. All URLs are provided at the SIGCOMM site above. From rem-conf Tue Aug 29 07:34:25 2000 From rem-conf-request@es.net Tue Aug 29 07:34:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TmGP-0005gM-00; Tue, 29 Aug 2000 07:21:21 -0700 Received: from sky.irisa.fr [131.254.60.147] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TmGN-0005gC-00; Tue, 29 Aug 2000 07:21:19 -0700 Received: from irisa.fr (nermine.irisa.fr [131.254.13.74]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id QAA27670 for ; Tue, 29 Aug 2000 16:21:18 +0200 (MET DST) Message-ID: <39ABC6E0.F56327FF@irisa.fr> Date: Tue, 29 Aug 2000 16:21:20 +0200 From: Samir Mohamed Organization: Inria/Irisa X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en, fr MIME-Version: 1.0 To: rem-conf@es.net Subject: Most used video codecs Content-Type: multipart/mixed; boundary="------------B4A532B53CD402C965806E49" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------B4A532B53CD402C965806E49 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I'd like to know the most used video codecs employed to transmit video over the internet in real time. Well, is it MPEG1/2, H263 or any other? In addition, if you know an implementation of any kind of video codec that works under linux or unix, could you please send me the link to its location? Thanks for your interest and looking forward to receive all your comments and suggestions. -- Samir ,---------------------------------. ,------------------------------. | Short email: SamirAhmed@reso.com| | Samir Mohamed | | tel : 02 99 84 75 74 | | IRISA/INRIA, Bureau E318 | | fax : 02 99 84 25 29 | | Campus de Beaulieu 35042 | | Mobile: 06 74 13 93 08 | | RENNES Cedex, FRANCE | `---------------------------------' `------------------------------' --------------B4A532B53CD402C965806E49 Content-Type: text/x-vcard; charset=us-ascii; name="Samir.Mohamed.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Samir Mohamed Content-Disposition: attachment; filename="Samir.Mohamed.vcf" begin:vcard n:Mohamed;Samir tel;home:02 23 30 35 68 tel;work:02 99 84 75 74 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Samir.Mohamed@irisa.fr fn:Samir Mohamed end:vcard --------------B4A532B53CD402C965806E49-- From rem-conf Tue Aug 29 07:34:27 2000 From rem-conf-request@es.net Tue Aug 29 07:34:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TmP7-0005lo-00; Tue, 29 Aug 2000 07:30:21 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TmP6-0005lO-00; Tue, 29 Aug 2000 07:30:20 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA10619 for ; Tue, 29 Aug 2000 07:30:20 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id HAA19304 for rem-conf@es.net; Tue, 29 Aug 2000 07:30:16 -0700 (PDT) Date: Tue, 29 Aug 2000 07:30:16 -0700 (PDT) Message-Id: <200008291430.HAA19304@rum.isi.edu> To: rem-conf@es.net Subject: SIGCOMM live Internet MBone transmission X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ACM SIGCOMM 2000 Conference Multicast transmission on the Internet Wed August 30 - Fri Sept 1, 2000 http://www.acm.org/sigcomm/sigcomm2000 SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. Multicast transmission on the Internet We will multicast video and audio from the technical sessions of the onference live on the Internet. The transmission will start Wednesday August 30 at 9:00 and end Friday September 1 at 13:30. The local timezone is CEST (GMT+2). See the conference program for time details (URL above). The conference can be received using the free Marratech player software, as well as the standard MBone tools. Please visit Marratech's web page for further technical information on the transmission from SIGCOMM as well as download instructions for their software. All URLs are provided at the SIGCOMM site above. From rem-conf Tue Aug 29 07:48:28 2000 From rem-conf-request@es.net Tue Aug 29 07:48:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TmfK-0000Jf-00; Tue, 29 Aug 2000 07:47:06 -0700 Received: from dhcp204.sigcomm.sics.se (purple.east.isi.edu) [212.181.55.204] by mail1.es.net with esmtp (Exim 1.81 #2) id 13TmfI-0000Hg-00; Tue, 29 Aug 2000 07:47:05 -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 PAA00765; Tue, 29 Aug 2000 15:47:04 +0100 Message-Id: <200008291447.PAA00765@purple.east.isi.edu> To: leonid@bitband.com cc: 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt In-Reply-To: Message from Leonid Rosenboim of "Tue, 29 Aug 2000 16:42:10 +0200." <39ABCBC2.732A91DB@bitband.com> Date: Tue, 29 Aug 2000 15:47:04 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Leonid Rosenboim writes: > >Colin Perkins wrote: > >> --> Leonid Rosenboim writes: >> >from a quick look at the latest draft, I have not seen any references to the issue of >> >combined Audio/Video streaming. I understand that with this scheme Video and Audio >> >will each have its own RTP session, which are basically independent of one another, >> >except the initiation which is done with SDP or H.245. >> > >> >Still, perhaps there should be some specific description of how these streams should >> >be related, for instance to make sure that the Audio and Video do not run out of sync >> >with respect to one another. Should in such a case both Audio and Video timestamps >> >begin with the same random value and share the same timestamp resolution ? Surely, >> >they should at least have a common denominator or something. >> >> The synchronisation is achieved using standard RTCP sender report packets >> and the RTP timestamp. >> > >Perhaps it would be simplier if the payload would specify that in the >audio+video case, both audio and video sessions should have a common >timestamp initial value and resolution, as well as a common SSRC. This >draft is all about simplicity, so why make it more complex by mandating >RTCP sender report? Because this draft is supposed to interwork with existing RTP implementations. >Consider a situation where a few video packets got lost right at the >beginning of a session, but none of the audio packets got lost, the player >will have to assume the initial timestamp for the video is of the first >packet arrived, hence all subsequent video will loose sync with the audio, >as the audio initial timestamp will be correct, but vide initial timestamp >will not be correct. Not true. The periodic sender reports allow you to establish the mapping. >> >Also, since each will probably have a different payload type, they >> >could share the same port numbers, same SSRC, but could for example >> >have difference IP Precedence values if during network congestion it is >> >desired to still have Audio when the Video can not make it through. >> >> Yes, that is a possibility. > >I suggest this is "recommended" in the draft. No, this is outside the scope of a particular payload format. There are many ways of protecting media streams, the payload should work with all of them, rather than mandating a particular solution. Colin From rem-conf Tue Aug 29 08:41:53 2000 From rem-conf-request@es.net Tue Aug 29 08:41:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13TnUS-00028U-00; Tue, 29 Aug 2000 08:39:56 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13TnUQ-00028J-00; Tue, 29 Aug 2000 08:39:54 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id IAA20037; Tue, 29 Aug 2000 08:27:48 -0700 Message-Id: <3.0.3.32.20000829083000.0095b850@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 29 Aug 2000 08:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 8/30 The Future of Interactive Television -- Lawrence A. Rowe, Computer Science Division - EECS, U.C. Berkeley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar The Future of Interactive Television Wednesday August 30, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) Lawrence A. Rowe Computer Science Division - EECS, U.C. Berkeley Traditional broadcast television programs are composed of one video stream, fixed image size, and fixed picture quality. Interaction is limited to changing channels unless you have access to a service like WebTV. Many companies are developing technology that will allow traditional television to be distributed over the Internet, so called "Internet TV." This talk will discuss features that can be exploited using Internet TV including multiple video streams, interaction between participants, and variable quality streams. In spite of these technical capabilities, most Internet Webcasts today are produced using traditional television technologies and are constrained to the limitations of traditional television broadcasting. Research on developing computer-based webcasting technology will be described that exploits capabilities of this new medium including broadcast management, video-effects processing, and live production control. The use of this technology to produce this seminar and the Berkeley Internet Broadcasting System (BIBS) Class Lecture Webcasts will be described. --------------- 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'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: low bit rate video: 233.0.25.1/22334 audio: 233.0.25.2/22446 medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/298/index.html Sponsored by the Berkeley Multimedia Research Center From rem-conf Tue Aug 29 17:40:40 2000 From rem-conf-request@es.net Tue Aug 29 17:40:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Tvqc-0000Ys-00; Tue, 29 Aug 2000 17:35:22 -0700 Received: from brisco.passedge.com [63.97.251.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Tvqa-0000YE-00; Tue, 29 Aug 2000 17:35:20 -0700 Received: from mblaptop.passedge.com (MBAUGHER-LAPTOP [63.97.251.230]) by brisco.passedge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QXSBW3LJ; Tue, 29 Aug 2000 17:36:46 -0700 Message-Id: <4.3.1.0.20000829170050.00b02360@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 29 Aug 2000 17:21:33 -0700 To: rem-conf@es.net From: Mark Baugher Subject: Re: Define a unicast RTP session. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > > - Finally, how shall two oppositely directed RTP flows in a two-party >conversation appear in the RTP MIB session table, as two entries or as > >one? Your answer suggests two entries. Is that what the MIB authors >want? There are two rtpSessionTable entries, one in each endpoint's RTP MIB of the unicast connection. At each particular endpoint, there will be an rtpSenderTable entry for the session data that the endpoint is sending, and there will an rtpRcvrTable entry for the session data that the endpoint is receiving. Mark Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From rem-conf Tue Aug 29 18:37:08 2000 From rem-conf-request@es.net Tue Aug 29 18:37:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Twlf-0001ji-00; Tue, 29 Aug 2000 18:34:19 -0700 Received: from brisco.passedge.com [63.97.251.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Twld-0001jR-00; Tue, 29 Aug 2000 18:34:18 -0700 Received: from mblaptop.passedge.com (ppp-dk.rdrop.com [199.2.212.53]) by brisco.passedge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QXSBW3MQ; Tue, 29 Aug 2000 18:35:42 -0700 Message-Id: <4.3.1.0.20000829182941.00d20390@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 29 Aug 2000 18:34:13 -0700 To: rem-conf@es.net From: Mark Baugher Subject: Fwd: Re: Define a unicast RTP session. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am sorry but I realized while driving home that what I just said was wrong. For unicast, there are two rtpSessionTable entries at each endpoint. There is a session entry for the stream that the particular endpoint is sending and one for the stream that it is receiving. I apologize for this confusion. Mark >Date: Tue, 29 Aug 2000 17:21:33 -0700 >To: rem-conf@es.net >From: Mark Baugher >Subject: Re: Define a unicast RTP session. > >> >> > - Finally, how shall two oppositely directed RTP flows in a two-party >>conversation appear in the RTP MIB session table, as two entries or as >> >one? Your answer suggests two entries. Is that what the MIB authors >>want? >There are two rtpSessionTable entries, one in each endpoint's RTP MIB of the unicast connection. At each particular endpoint, there will be an rtpSenderTable entry for the session data that the endpoint is sending, and there will an rtpRcvrTable entry for the session data that the endpoint is receiving. > >Mark Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From rem-conf Wed Aug 30 00:44:53 2000 From rem-conf-request@es.net Wed Aug 30 00:44:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13U2Rp-0004zO-00; Wed, 30 Aug 2000 00:38:13 -0700 Received: from dhcp204.sigcomm.sics.se (purple.east.isi.edu) [212.181.55.204] by mail1.es.net with esmtp (Exim 1.81 #2) id 13U2Rn-0004zE-00; Wed, 30 Aug 2000 00:38:11 -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 IAA01787; Wed, 30 Aug 2000 08:38:48 +0100 Message-Id: <200008300738.IAA01787@purple.east.isi.edu> To: leonid@bitband.com cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt In-Reply-To: Message from Leonid Rosenboim of "Tue, 29 Aug 2000 17:23:21 +0200." <39ABD568.50DB4E7A@bitband.com> Date: Wed, 30 Aug 2000 08:38:48 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Leonid Rosenboim writes: >Colin Perkins wrote: >> [snip] >> >Perhaps it would be simplier if the payload would specify that in the >> >audio+video case, both audio and video sessions should have a common >> >timestamp initial value and resolution, as well as a common SSRC. This >> >draft is all about simplicity, so why make it more complex by mandating >> >RTCP sender report? >> >> Because this draft is supposed to interwork with existing RTP implementations. > >Do you mean existing implementations of this draft ? I do not see how >my suggestion hurts implementations of other payload types, as the tie >between Audio and Video timing I suggested was specific for this payload >type only. No, I mean with other payload types. For example using MPEG-4 video with non-MPEG-4 audio, and wishing to synchronize them. >> >Consider a situation where a few video packets got lost right at the >> >beginning of a session, but none of the audio packets got lost, the player >> >will have to assume the initial timestamp for the video is of the first >> >packet arrived, hence all subsequent video will loose sync with the audio, >> >as the audio initial timestamp will be correct, but vide initial timestamp >> >will not be correct. >> >> Not true. The periodic sender reports allow you to establish the mapping. >> > >In that case, RTCP sender reports and support of NTP time reference >needs to be MANDATED by this payload type. Aren't sender reports >optional ? Not if you need synchronization. >Do you really expect mobile phones to have NTP implementations embedded >in them ? No. I expect them to be able to understand NTP format timestamps. There is no requirement in RTP for the clock to be NTP-synchronized (so long as the sender is consistent, the clock can have an arbitrary reference). >Besides, I can see only one justification for having two different payload formats >for MPEG-4: one needs to be simple to implement, which is what this one is suppoed >to do, hence my suggestion to make it simplier. You are simplifying this format, at the expense of making interworking with other RTP implementations harder. The reason for developing this format is to work with H.323 terminals, which use standard RTP implementations. Colin From rem-conf Wed Aug 30 01:10:44 2000 From rem-conf-request@es.net Wed Aug 30 01:10:43 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13U2v2-0005zZ-00; Wed, 30 Aug 2000 01:08:24 -0700 Received: from (p-mail1.cnet.fr) [192.144.74.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13U2v0-0005yl-00; Wed, 30 Aug 2000 01:08:22 -0700 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Aug 2000 10:06:41 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B13299D@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: 'Colin Perkins' , leonid@bitband.com Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Date: Wed, 30 Aug 2000 10:08:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.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 Dear all, because of delays due to different buffer sizes, to average=20 bitrates of elementary streams, the time needed for bytes to get=20 across audio and video buffers will be completely different. If you want to save buffers, when Video and audio are multiplexed=20 together the audio shouild be tranmitted quite late. That is to=20 say that when you see some video passing through a pipe, you have to wait quite a while to see the audio that will be reproduced in phase. regards _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel=20 > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ -----Message d'origine----- De: Colin Perkins [mailto:csp@isi.edu] Date: mercredi 30 ao=FBt 2000 09:39 =C0: leonid@bitband.com Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Objet: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt=20 --> Leonid Rosenboim writes: >Colin Perkins wrote: >> [snip] >> >Perhaps it would be simplier if the payload would specify that in = the >> >audio+video case, both audio and video sessions should have a = common >> >timestamp initial value and resolution, as well as a common SSRC. = This >> >draft is all about simplicity, so why make it more complex by = mandating >> >RTCP sender report? >> >> Because this draft is supposed to interwork with existing RTP implementations. > >Do you mean existing implementations of this draft ? I do not see how >my suggestion hurts implementations of other payload types, as the tie >between Audio and Video timing I suggested was specific for this = payload >type only. No, I mean with other payload types. For example using MPEG-4 video = with non-MPEG-4 audio, and wishing to synchronize them. >> >Consider a situation where a few video packets got lost right at = the >> >beginning of a session, but none of the audio packets got lost, the player >> >will have to assume the initial timestamp for the video is of the = first >> >packet arrived, hence all subsequent video will loose sync with the audio, >> >as the audio initial timestamp will be correct, but vide initial timestamp >> >will not be correct. >> >> Not true. The periodic sender reports allow you to establish the = mapping. >> > >In that case, RTCP sender reports and support of NTP time reference >needs to be MANDATED by this payload type. Aren't sender reports >optional ? Not if you need synchronization. >Do you really expect mobile phones to have NTP implementations = embedded >in them ? No. I expect them to be able to understand NTP format timestamps. There = is no requirement in RTP for the clock to be NTP-synchronized (so long as = the sender is consistent, the clock can have an arbitrary reference). >Besides, I can see only one justification for having two different = payload formats >for MPEG-4: one needs to be simple to implement, which is what this = one is suppoed >to do, hence my suggestion to make it simplier. You are simplifying this format, at the expense of making interworking = with other RTP implementations harder. The reason for developing this format = is to work with H.323 terminals, which use standard RTP implementations. Colin From rem-conf Wed Aug 30 01:36:38 2000 From rem-conf-request@es.net Wed Aug 30 01:36:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13U3KJ-00072x-00; Wed, 30 Aug 2000 01:34:31 -0700 Received: from ogopogo.flash.net [209.30.2.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13U3KG-00072b-00; Wed, 30 Aug 2000 01:34:28 -0700 Received: from unknown (A030-0079.ATL3.splitrock.net [63.254.114.79]) by ogopogo.flash.net (8.9.3/Pro-8.9.3) with SMTP id DAA18115; Wed, 30 Aug 2000 03:34:10 -0500 (CDT) From: Subject: Best Cartridge Prices Date: Wed, 30 Aug 2000 04:30:57 Message-Id: <530.531493.64153@unknown> Reply-To: dprint2000@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list D&J PRINTING CORPORATION 2564 CHISE DR ACWORTH, GA 30102 (770) 619-0716 --LASER, FAX AND COPIER PRINTER TONER CARTRIDGES-- *WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS* CHECK OUT OUR NEW CARTRIDGE PRICES: APPLE LASER WRITER PRO 600 OR 16/600 $65 LASER WRITER SELECT 300, 310, 360 $65 LASER WRITER 300, 320 $54 LASER WRITER LS, NT, 2NTX, 2F, 2G AND 2SC $54 LASER WRITER 12/640 $75 HEWLETT PACKARD LASERJET SERIES 2, 3 AND 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $45 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $55 LASERJET SERIES 4000 HIGH YIELD (27X) $95 LASERJET SERIES 4V $90 LASERJET SERIES 5SI, 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $125 LASERJET SERIES 1100 (92A) $50 LASERJET SERIES 2100 (96A) $80 LASERJET SERIES 8100 (82X) $135 HEWLETT PACKARD LASERFAX LASERFAX 500, 700, FX1 $57 LASERFAX 5000, 7000, FX2 $57 LASERFAX FX3 $67 LASERFAX FX4 $77 LEXMARK OPTRA 4019, 4029 HIGH YIELD $130 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S, 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $110 EPSON EPL-7000, 8000 $100 EPL-1000, 1500 $100 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 (FX1) $59 CANON FAX L5000 THRU L7000 (FX2) $59 CANON COPIERS PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $85 NEC SERIES 2 LASER MODEL 90, 95 $105 PLEASE NOTE: * WE SHIP UPS GROUND. ADD $6.50 FOR SHIPPING AND HANDLING * WE ACCEPT ALL MAJOR CREDIT CARDS OR "COD" ORDERS. * COD CHECK ORDERS ADD $3.50 TO YOUR SHIPPING COST. * OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS. * OUR STANDARD MERCHANDISE REPLACEMENT POLICY IS NET 90 DAYS. * WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS. * WE DO NOT CARRY: BROTHER, MINOLTA, KYOSERA, PANASONIC, XEROX, FUJITSU, OKIDATA OR SHARP PRODUCTS. * WE ALSO DO NOT CARRY: COLOR PRINTER SUPPLIES, DESKJET/INKJET OR BUBBLEJET SUPPLIES. * WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS. -PLACE YOUR ORDER AS FOLLOWS- 1) BY PHONE (770) 619-0716 2) BY MAIL: D AND J PRINTING CORPORATION 2564 CHISE DR ACWORTH, GA 30102 INCLUDE THE FOLLOWING INFORMATION WHEN YOU PLACE YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) CONTACT NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE **** IF YOU ARE ORDERING BY PURCHASE ORDER, PLEASE INCLUDE A SEPARATE BILLING ADDRESS AND SHIPPING ADDRESS WHEN NEEDED. From rem-conf Wed Aug 30 08:39:46 2000 From rem-conf-request@es.net Wed Aug 30 08:39:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13U9nA-0003mP-00; Wed, 30 Aug 2000 08:28:44 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13U9n8-0003mE-00; Wed, 30 Aug 2000 08:28:42 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 30 Aug 2000 10:26:42 UT Subject: Re: Fwd: Re: Define a unicast RTP session. To: Mark Baugher Cc: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Wed, 30 Aug 2000 10:18:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/30/2000 11:28:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Mark, Thanks for the response. There seems to be plenty of evidence that unicast sessions can be bidirectional, which means that both endpoints in a two party call would be participating in the same single session. In fact, this may be the typical case. If each entry in the RTP MIB session table identifies a unique session, shouldn't there, then, be one MIB session entry at each endpoint? If the mode were simply host, and not host-monitor, each endpoint would have this one session table entry, along with one entry in the sender table and another in the receiver table (all with the same session index) - again, assuming bidirectional flow in the session. Please advise! Vince Virgilio From rem-conf Wed Aug 30 09:37:57 2000 From rem-conf-request@es.net Wed Aug 30 09:37:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UAnI-00055K-00; Wed, 30 Aug 2000 09:32:56 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13UAnG-00055A-00; Wed, 30 Aug 2000 09:32:55 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-182.dialup.cs.tu-berlin.de [130.149.145.182]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id SAA17847; Wed, 30 Aug 2000 18:29:44 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000830172446.02b33b90@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Aug 2000 18:24:03 +0200 To: CURET Dominique FTRD/DMI/REN , "'Colin Perkins'" , leonid@bitband.com From: Stephan Wenger Subject: RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt Cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B13299D@l-rmhs.lannion.cnet .fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >If you want to save buffers, when Video and audio are multiplexed >together the audio shouild be tranmitted quite late. That is to >say that when you see some video passing through a pipe, >you have to wait quite a while to see the audio that will >be reproduced in phase. Dominique, Although your statement is true from a theoretical point-of-view, it is not what most H.323 systems do these days. An H.323 terminal sends media data as soon as the coding/packetization process is finished. The lip-synchronization is performed at the receiver by delaying reproduction of audio (or, in rare cases, video) until synchronization is achieved. Many systems have some settings in the user interface that allow not to use lip- synchronization, in which case reproduction starts as soon as the RTP buffering mechanism delivers the packets. All this is, of course, due to the significantly higher algorithmic delay of the video codec compared to the audio codec. The argument that the packetization delay for audio is high (because it takes time at low audio bitrates to fill a packet) may, again, be true from a theoretical point-of-view. Real-world systems, however, use fairly small packets and accept the bad payload/ overhead ratio to deliver audio as soon as practical. Finally, sender based media synchronization does not work in multicast scenarios, because there may be different routings for streams going to the SAME receiver, leading in different time offsets between streams to the SAME receiver, yielding different time offsets between DIFFERENT receivers. Stephan >regards > > >_________________________________________ > > Dominique Curet > > France T=E9l=E9com R&D - DMI/PIA > > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > > ) CCETT B.P. 59 4, rue du Clos Courtel > > 35512 Cesson-Sevigne Cedex 09 FRANCE > > mailto:dominique.curet@rd.francetelecom.fr >_________________________________________ > > > > >-----Message d'origine----- >De: Colin Perkins [mailto:csp@isi.edu] >Date: mercredi 30 ao=FBt 2000 09:39 >=C0: leonid@bitband.com >Cc: rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu >Objet: Re: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt > > >--> Leonid Rosenboim writes: > >Colin Perkins wrote: > >> [snip] > >> >Perhaps it would be simplier if the payload would specify that in the > >> >audio+video case, both audio and video sessions should have a common > >> >timestamp initial value and resolution, as well as a common SSRC. This > >> >draft is all about simplicity, so why make it more complex by= mandating > >> >RTCP sender report? > >> > >> Because this draft is supposed to interwork with existing RTP >implementations. > > > >Do you mean existing implementations of this draft ? I do not see how > >my suggestion hurts implementations of other payload types, as the tie > >between Audio and Video timing I suggested was specific for this payload > >type only. > >No, I mean with other payload types. For example using MPEG-4 video with >non-MPEG-4 audio, and wishing to synchronize them. > > >> >Consider a situation where a few video packets got lost right at the > >> >beginning of a session, but none of the audio packets got lost, the >player > >> >will have to assume the initial timestamp for the video is of the= first > >> >packet arrived, hence all subsequent video will loose sync with the >audio, > >> >as the audio initial timestamp will be correct, but vide initial >timestamp > >> >will not be correct. > >> > >> Not true. The periodic sender reports allow you to establish the= mapping. > >> > > > >In that case, RTCP sender reports and support of NTP time reference > >needs to be MANDATED by this payload type. Aren't sender reports > >optional ? > >Not if you need synchronization. > > >Do you really expect mobile phones to have NTP implementations embedded > >in them ? > >No. I expect them to be able to understand NTP format timestamps. There is >no requirement in RTP for the clock to be NTP-synchronized (so long as the >sender is consistent, the clock can have an arbitrary reference). > > >Besides, I can see only one justification for having two different= payload >formats > >for MPEG-4: one needs to be simple to implement, which is what this one= is >suppoed > >to do, hence my suggestion to make it simplier. > >You are simplifying this format, at the expense of making interworking with >other RTP implementations harder. The reason for developing this format is >to work with H.323 terminals, which use standard RTP implementations. > >Colin From rem-conf Wed Aug 30 10:04:10 2000 From rem-conf-request@es.net Wed Aug 30 10:04:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UBFD-00067U-00; Wed, 30 Aug 2000 10:01:47 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13UBFC-00067K-00; Wed, 30 Aug 2000 10:01:46 -0700 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id KAA08137; Wed, 30 Aug 2000 10:01:43 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 30 Aug 2000 17:01:42 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Aug 2000 10:01:41 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E9@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Vincent_Virgilio@nmss.com'" , Mark Baugher Cc: rem-conf@es.net Subject: RE: Fwd: Re: Define a unicast RTP session. Date: Wed, 30 Aug 2000 10:01:38 -0700 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 I think I'll step in as another one of the RTP MIB authors who had to wrangle with this issue... We took the definition from 1889 quite literally From section 3 RTP session: The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses plus a common port pair. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. Therefore in the case of unicast there ARE two sessions, because there are two different destination transport addresses. Did we get it right, I hope so (we are on track to have an RFC issued). Is there room for a LOT of interpretation, I believe that there is. However in the case of the RTP MIB a session is defined by a destination address, how would you put both sessions into the MIB as one entry if they have separate destination addresses ? Now this is different in Multicast because the destination address for ALL flows is a multicast address that is common for all senders. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Vincent_Virgilio@nmss.com [mailto:Vincent_Virgilio@nmss.com] > Sent: Wednesday, August 30, 2000 8:18 AM > To: Mark Baugher > Cc: rem-conf@es.net > Subject: Re: Fwd: Re: Define a unicast RTP session. > > > > Hi Mark, > > Thanks for the response. > > There seems to be plenty of evidence that unicast sessions can be > bidirectional, which means that both endpoints in a two party > call would be > participating in the same single session. In fact, this may > be the typical > case. If each entry in the RTP MIB session table identifies a unique > session, shouldn't there, then, be one MIB session entry at > each endpoint? > If the mode were simply host, and not host-monitor, each > endpoint would > have this one session table entry, along with one entry in > the sender table > and another in the receiver table (all with the same session index) - > again, assuming bidirectional flow in the session. > > Please advise! > > Vince Virgilio > > > From rem-conf Wed Aug 30 10:08:04 2000 From rem-conf-request@es.net Wed Aug 30 10:08:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UBJX-0006MD-00; Wed, 30 Aug 2000 10:06:15 -0700 Received: from (localhost.localdomain) [210.220.69.183] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13UBJQ-0006KR-00; Wed, 30 Aug 2000 10:06:08 -0700 Received: from sdn-ar-001tnknoxP262.dialsprint.net_[168.191.249.152] (sdn-ar-001tnknoxP262.dialsprint.net [168.191.249.152]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id CAA25605; Thu, 31 Aug 2000 02:08:51 +0900 From: chris1488@earthlink.net Received: from by sdn-ar-001tnknoxP262.dialsprint.net with ESMTP; Wed, 30 Aug 2000 13:06:14 -0400 Message-ID: <00004c1b4947$00007546$00001475@> To: Subject: The #1 Home Based Business In AMERICA!! 5237 Date: Wed, 30 Aug 2000 13:06:07 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

FOLLOW ME TO FINANCIAL FREEDOM!!



I Am looking for people with good work ethic and extrordinary desire
to earn at least $10,000 per month working from home!



NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the

training and personal support you will need to ensure your success!


This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in

control of your time,your finances,and your life!



If you've tried other opportunities in the past that have failed to
live up their promises,



THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!



THIS IS NOT A GET RICH QUICK SCHEME!



YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!



CALL ONLY IF YOU ARE SERIOUS!



1-800-345-9708



DONT GO TO SLEEP WITHOUT LISTENING TO THIS!



"ALL our dreams can come true- if we have the courage to persue them"
<= BR> -Walt Disney



Please Leave Your Name And Number And Best Time To Call



DO NOT RESPOND BY EMAIL



------------------------------------------------------------------------
This message is sent in compliance of the new email bill section
301.PerSection

301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal
=
requests.Just Put Remove
mailto:bagboy@= burmesses.net
------------------------------------------------------------------------=

From rem-conf Wed Aug 30 13:55:05 2000 From rem-conf-request@es.net Wed Aug 30 13:55:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UEnP-00020d-00; Wed, 30 Aug 2000 13:49:19 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13UEnM-00020T-00; Wed, 30 Aug 2000 13:49:16 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 30 Aug 2000 15:47:16 UT Subject: RE: Define a unicast RTP session. To: rem-conf@es.net Cc: bill.strahm@intel.com Bcc: From: Vincent_Virgilio@nmss.com Date: Wed, 30 Aug 2000 15:40:06 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/30/2000 04:49:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list And the plot thickens. Respectfully, I believe the RTP RFC, especially with the subsequent drafts, is very clear in its definition of _a_ session. First, the definition is singular. It becomes plural only when discussing different media types. Also, section 7.1 of the latest RTP internet draft (#8) discusses transport-level "clouds", which are defined by a single multicast address, or two unicast addresses. Later, in appendix B, this text is interpreted to apply to a session; that it means distinct [destination] port pairs may be used for the two ends of a unicast session. The same appendix entry also supports my interpretation of the definition of a session in section 3; the one you quoted. Similarly, section 11 of the same draft says the same, that there may be two different destination port pairs in a unicast session (emphasis and commentary added): _In a unicast session_ [singular], _both_ participants need to identify a port pair for _receiving_ [thus both may send] RTP and RTCP packets. Both participants MAY use the same port pair. A participant MUST NOT assume that the source port of the incoming RTP or RTCP packet can be used as the destination port for outgoing RTP or RTCP packets [thus two differnt dest port pairs per session permitted]. When RTP data packets are being sent in both directions [in one session], each participant MUST send RTCP SR packets to the port that the other participant has specified for reception of RTCP. The RTCP SR packets combine sender information for the outgoing data plus reception report information for the incoming data. If a side is not actively sending data, an RTCP RR packet is sent instead. That is not ambiguous. Must I say "to me"? This poses no problems to the MIB. In host mode, there would be one entry in the session table, and, given bidirectional flow, corresponding ones in the sender and receiver tables, as Mark said initially. The assignment of local and remote addresses in the session entry would be obvious. Local is where the agent runs (the network part) and where RTP packets are received; remote is where RTP packets are sent. Both addresses are considered destination addresses, depending on your perspective, which, in a session, can change. The local participant considers the remote address his destination address, and considers the local address the other participant's destination address. The other participant interprets his session entry in the same way. But who cares, this has no teeth. Moreover, the MIB does not say anywhere that a session is defined by one destination transport address (but, instead, I am willing to accept that >from you); it refers back to the RTP RFC definitions, covered above. Even so, were a session defined this way, a single entry would be made out of two using the interpretive scheme above, and assigning the local and remote address appropriately. Also, local would always truly mean local, and the sense of remote would be as stable. The first sentence of the definition of rtpSessionLocAddr seems to expect this: "The local address used by the RTP system." If there were two session entries, one per flow direction, one session entry would have the local address assigned using the network address of the local system. The other entry would have the local address assigned using the network address of the remote system. The latter seems to be in tension with the first sentence of the description of rtpSessionLocAddr. If rtpSessionLocAddr were _not_ assigned thus, there would be a collision in the inverse session table. One remote/local pair would map to two session indices. So rtpSessionLocAddr must be assigned this way, under your definition of a session. True; intended? But if we use the bidirectional definition of a session, there would be no tension (if there ever was) with the definition of rtpSessionLocAddr. So things fall into place nicely. In host mode, assuming bidirectional flow, objects senderJoins and receiverJoins would both be valid where they wouldn't be given your take on sessions. Your way, outbound sessions (host mode) would only increment senderJoins, and inbound sessions would only increment receiverJoins, since only host-monitor mode, not host mode, tracks remote receivers or senders. However, I do notice a loophole, in the descriptions of rtpSenderTable and rtpReceiverTable. They state that, regardless of mode (mode not mentioned), receiving hosts may add entries to the sender table and sending hosts may add entries to the receiver table. Hm. I think this blurs the line some between host and host-monitor mode. Vince Virgilio "Strahm, Bill" on 08/30/2000 12:01:38 PM To: "'Vincent_Virgilio@nmss.com'" , Mark Baugher cc: rem-conf@es.net Subject: RE: Fwd: Re: Define a unicast RTP session. I think I'll step in as another one of the RTP MIB authors who had to wrangle with this issue... We took the definition from 1889 quite literally From section 3 RTP session: The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses plus a common port pair. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. Therefore in the case of unicast there ARE two sessions, because there are two different destination transport addresses. Did we get it right, I hope so (we are on track to have an RFC issued). Is there room for a LOT of interpretation, I believe that there is. However in the case of the RTP MIB a session is defined by a destination address, how would you put both sessions into the MIB as one entry if they have separate destination addresses ? Now this is different in Multicast because the destination address for ALL flows is a multicast address that is common for all senders. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Vincent_Virgilio@nmss.com [mailto:Vincent_Virgilio@nmss.com] > Sent: Wednesday, August 30, 2000 8:18 AM > To: Mark Baugher > Cc: rem-conf@es.net > Subject: Re: Fwd: Re: Define a unicast RTP session. > > > > Hi Mark, > > Thanks for the response. > > There seems to be plenty of evidence that unicast sessions can be > bidirectional, which means that both endpoints in a two party > call would be > participating in the same single session. In fact, this may > be the typical > case. If each entry in the RTP MIB session table identifies a unique > session, shouldn't there, then, be one MIB session entry at > each endpoint? > If the mode were simply host, and not host-monitor, each > endpoint would > have this one session table entry, along with one entry in > the sender table > and another in the receiver table (all with the same session index) - > again, assuming bidirectional flow in the session. > > Please advise! > > Vince Virgilio > > > From rem-conf Wed Aug 30 14:05:58 2000 From rem-conf-request@es.net Wed Aug 30 14:05:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UF2k-00030c-00; Wed, 30 Aug 2000 14:05:10 -0700 Received: from ns-1.macromedia.com [207.88.220.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13UF2i-00030S-00; Wed, 30 Aug 2000 14:05:08 -0700 Received: from ns-2.macromedia.com (ns-2.macromedia.com [207.88.156.10]) by ns-1.macromedia.com (8.9.3/8.9.3) with ESMTP id OAA14456 for ; Wed, 30 Aug 2000 14:05:07 -0700 (PDT) Received: from macromedia.com (dhcp-10-60-1-218.macromedia.com [10.60.1.218]) by ns-2.macromedia.com (8.9.1a/8.8.8) with ESMTP id OAA23045 for ; Wed, 30 Aug 2000 14:05:07 -0700 (PDT) Message-ID: <39AD76FF.D85ED1C0@macromedia.com> Date: Wed, 30 Aug 2000 14:05:03 -0700 From: Christophe Leske X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Define a unicast RTP session. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could someone pls point me to the resource where i can unsubscribe from this list? I was interested in tapping mbone, it turns out that no commercial provider in the SF bay area DOES provide mbone access. I never got any answers of this list, and worse yet, i am getting spam and sex emails. Thank you, i got enough of this. -- Regards, Christophe Leske m a c r o m e d i a Director QA engineer-Dataman phone : [415] 832 - 7497 cleske@macromedia.com "What we do in life echoes in eternity." From rem-conf Wed Aug 30 15:13:32 2000 From rem-conf-request@es.net Wed Aug 30 15:13:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UG4F-0004KR-00; Wed, 30 Aug 2000 15:10:47 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13UG4D-0004K6-00; Wed, 30 Aug 2000 15:10:45 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 30 Aug 2000 17:08:45 UT Subject: Re: Fwd: Re: Define a unicast RTP session. To: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Wed, 30 Aug 2000 17:06:36 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/30/2000 06:10:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Again, so that others can follow . . . here's that latest, warts and all. ---------------------- Forwarded by Vincent Virgilio/Natural MicroSystems/US on 08/30/2000 05:06 PM --------------------------- Vincent Virgilio 08/30/2000 04:55 PM To: mbaugher@passedge.com, bill.strahm@intel.com cc: Subject: Re: Fwd: Re: Define a unicast RTP session. Of course, the below comment about uni-multicast is quite dumb if the session index has to map to a single session table entry . . . Vince Virgilio ---------------------- Forwarded by Vincent Virgilio/Natural MicroSystems/US on 08/30/2000 04:54 PM --------------------------- Vincent Virgilio 08/30/2000 04:29 PM To: Mark Baugher cc: bill.strahm@intel.com Subject: Re: Fwd: Re: Define a unicast RTP session. (Document link: Vincent Virgilio) Hi Mark (and Bill), When you say "bidirectional, unicast RTP streams" you mean two opposite flows, right? According to Bill, the definition of an RTP session in section 3 of RFC 1889 is unclear whether such a scenario constitutes one or two sessions. I say one, he says two. I used subsequent drafts of the RFC to prove my point. Bill rightly pointed out that was invalid of me to do so. Still, on further inspection, I maintain that the original section 3 definition is singular (which implies multiple unicast destinations per session), and that the first paragraph of section 7.1 in the same document explicitly says that there is such a thing as a two-party bidirectional unicast session. Within that paragraph, "clouds" and sessions are equated, and a cloud may be defined by a pair of unicast network addresses. I don't think things get ugly for uni-multicast; the tables just get bigger. Then, given the definition that permits multiple destination addresses per session, there would be multiple entries in the session table for a single session, each containing the same session index, but a unique remote address. The local address would remain the same across all such entries. To gets statistics for the whole session, accumulate across all entries with same index. The impact on sender and receiver tables is negligible, in size only, I think. Even so, uni-multicast is not explicitly allowed by RFC 1889. The session definition in section 3 is constrained to two participants in the first paragraph of section 7.1. What do you guys think? Actually, your session definition would greatly simplify some work I'm about to do. Which is to say, I have no vested interest in this argument! I have nothing to do with "H-media" people at all. Vince Virgilio Mark Baugher on 08/30/2000 04:02:49 PM To: Vincent_Virgilio@nmss.com, bill.strahm@intel.com cc: Subject: Re: Fwd: Re: Define a unicast RTP session. hi We had H-media MIB participation in the RTP MIB. I did not mean to say that unicast was difficult, but that there seems to be some confusion since the issue has popped up a few times on the list. I don't think the person or persons who raised the issue were always satisfied with the outcome. One obvious source of confusion is that you cannot talk about a unicast "session" for bidirectional, unicast RTP streams since there are two sessions, not one, in this scenario. So I don't know of any ready-made nomenclature for distinguishing two sessions in bidirectional unicast RTP communications from two unrelated, unidirectional, unicast sessions. It's not hard, per se. It works though I find myself getting confused when switching from unicast to multicast. could be a personal problem, however. Mark At 03:48 PM 8/30/00 -0500, Vincent_Virgilio@nmss.com wrote: >Hi Mark, > >I had no idea that this question was so difficult. Obviously you have the >last say in how your MIB should be implemented. I am concerned, though, >that the view of a system given by the MIB will differ from the >configuration negotiated through H.323. For example, there could be twice >as many sessions observed in the former as negotiated in the latter. > >Vince Virgilio > > > > > >Mark Baugher on 08/30/2000 03:42:07 PM > >To: Vincent_Virgilio@nmss.com >cc: >Subject: Re: Fwd: Re: Define a unicast RTP session. > > >Vincent > Bill said what I think in his note. I think there is a lot of confusion >about unicast in RTP. > >Mark >At 10:18 AM 8/30/00 -0500, you wrote: > > >Hi Mark, > > > >Thanks for the response. > > > >There seems to be plenty of evidence that unicast sessions can be > >bidirectional, which means that both endpoints in a two party call would >be > >participating in the same single session. In fact, this may be the >typical > >case. If each entry in the RTP MIB session table identifies a unique > >session, shouldn't there, then, be one MIB session entry at each endpoint? > >If the mode were simply host, and not host-monitor, each endpoint would > >have this one session table entry, along with one entry in the sender >table > >and another in the receiver table (all with the same session index) - > >again, assuming bidirectional flow in the session. > > > >Please advise! > > > >Vince Virgilio > > >Mark Baugher >PGP Fingerprint >01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C > > Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From rem-conf Wed Aug 30 15:13:33 2000 From rem-conf-request@es.net Wed Aug 30 15:13:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UG4E-0004KH-00; Wed, 30 Aug 2000 15:10:46 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13UG4C-0004K5-00; Wed, 30 Aug 2000 15:10:44 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 30 Aug 2000 17:08:44 UT Subject: RE: Fwd: Re: Define a unicast RTP session. To: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Wed, 30 Aug 2000 17:04:29 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/30/2000 06:10:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list So that others can follow the thread . . . ---------------------- Forwarded by Vincent Virgilio/Natural MicroSystems/US on 08/30/2000 05:04 PM --------------------------- "Strahm, Bill" on 08/30/2000 03:49:24 PM To: "'Vincent_Virgilio@nmss.com'" cc: Subject: RE: Fwd: Re: Define a unicast RTP session. The problem is that you are referencing a Internet Draft that I cannot use until it has been standardized. I am only willing to talk about what is ACTUALLY in 1889 to base the RTP MIB RFC on... Some comments below... ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Vincent_Virgilio@nmss.com [mailto:Vincent_Virgilio@nmss.com] > Sent: Wednesday, August 30, 2000 12:52 PM > To: Strahm, Bill > Subject: RE: Fwd: Re: Define a unicast RTP session. > > > > And the plot thickens. > > Respectfully, I believe the RTP RFC, especially with the > subsequent drafts, > is very clear in its definition of _a_ session. First, the > definition is > singular. It becomes plural only when discussing different > media types. > > Also, section 7.1 of the latest RTP internet draft (#8) discusses > transport-level "clouds", which are defined by a single > multicast address, > or two unicast addresses. Later, in appendix B, this text is > interpreted > to apply to a session; that it means distinct [destination] > port pairs may > be used for the two ends of a unicast session. The same > appendix entry > also supports my interpretation of the definition of a > session in section > 3; the one you quoted. Yes section 3 has many different interpretations... I have even heard something call Uni-Multicast where I broadcast all of my streams to everyone else unicast, they all do the same and this is all supposed to be 1 session... (all based on the Section 3 definition of an RTP session) Very ugly... > Similarly, section 11 of the same draft says the same, that > there may be > two different destination port pairs in a unicast session > (emphasis and > commentary added): > > _In a unicast session_ [singular], _both_ participants > need to identify > a port pair for _receiving_ [thus both may send] RTP and > RTCP packets. > Both participants MAY use the same port pair. A > participant MUST NOT > assume that the source port of the incoming RTP or RTCP > packet can be > used as the destination port for outgoing RTP or RTCP > packets [thus two > differnt dest port pairs per session permitted]. When RTP > data packets > are being sent in both directions [in one session], each > participant > MUST send RTCP SR packets to the port that the other > participant has > specified for reception of RTCP. The RTCP SR packets > combine sender > information for the outgoing data plus reception report > information for > the incoming data. If a side is not actively sending > data, an RTCP RR > packet is sent instead. > > That is not ambiguous. Must I say "to me"? Well in that Draft 9 may change everything... This text is not in 1889, so I am not considering it for the RTP MIB RFC. When Draft #n becomes standard, and we move the RTP MIB to the next standard level I would consider changing the sematics... > This poses no problems to the MIB. In host mode, there would > be one entry > in the session table, and, given bidirectional flow, > corresponding ones in > the sender and receiver tables, as Mark said initially. The > assignment of > local and remote addresses in the session entry would be > obvious. Local is > where the agent runs (the network part) and where RTP packets > are received; > remote is where RTP packets are sent. Both addresses are considered > destination addresses, depending on your perspective, which, > in a session, > can change. The local participant considers the remote address his > destination address, and considers the local address the other > participant's destination address. The other participant > interprets his > session entry in the same way. But who cares, this has no teeth. > Moreover, the MIB does not say anywhere that a session is > defined by one > destination transport address (but, instead, I am willing to > accept that > from you); it refers back to the RTP RFC definitions, covered > above. Even > so, were a session defined this way, a single entry would be > made out of > two using the interpretive scheme above, and assigning the > local and remote > address appropriately. > > Also, local would always truly mean local, and the sense of > remote would be > as stable. The first sentence of the definition of > rtpSessionLocAddr seems > to expect this: "The local address used by the RTP system." > If there were > two session entries, one per flow direction, one session > entry would have > the local address assigned using the network address of the > local system. > The other entry would have the local address assigned using > the network > address of the remote system. The latter seems to be in > tension with the > first sentence of the description of rtpSessionLocAddr. If > rtpSessionLocAddr were _not_ assigned thus, there would be a > collision in > the inverse session table. One remote/local pair would map > to two session > indices. So rtpSessionLocAddr must be assigned this way, under your > definition of a session. True; intended? But if we use the > bidirectional > definition of a session, there would be no tension (if there > ever was) with > the definition of rtpSessionLocAddr. > > So things fall into place nicely. In host mode, assuming > bidirectional > flow, objects senderJoins and receiverJoins would both be > valid where they > wouldn't be given your take on sessions. Your way, outbound > sessions (host > mode) would only increment senderJoins, and inbound sessions > would only > increment receiverJoins, since only host-monitor mode, not host mode, > tracks remote receivers or senders. However, I do notice a > loophole, in > the descriptions of rtpSenderTable and rtpReceiverTable. > They state that, > regardless of mode (mode not mentioned), receiving hosts may > add entries to > the sender table and sending hosts may add entries to the > receiver table. > Hm. I think this blurs the line some between host and > host-monitor mode. > > Vince Virgilio > > > > > > "Strahm, Bill" on 08/30/2000 12:01:38 PM > > To: "'Vincent_Virgilio@nmss.com'" , Mark > Baugher > cc: rem-conf@es.net > Subject: RE: Fwd: Re: Define a unicast RTP session. > > > I think I'll step in as another one of the RTP MIB authors who had to > wrangle with this issue... > > We took the definition from 1889 quite literally From section 3 > > > RTP session: The association among a set of participants > communicating with RTP. For each participant, the session is > defined by a particular pair of destination transport > addresses > (one network address plus a port pair for RTP and RTCP). The > destination transport address pair may be common for all > participants, as in the case of IP multicast, or may be > different for each, as in the case of individual > unicast network > addresses plus a common port pair. In a multimedia session, > each medium is carried in a separate RTP session with its own > RTCP packets. The multiple RTP sessions are distinguished by > different port number pairs and/or different multicast > addresses. > > Therefore in the case of unicast there ARE two sessions, > because there are > two different destination transport addresses. Did we get it > right, I hope > so (we are on track to have an RFC issued). Is there room > for a LOT of > interpretation, I believe that there is. However in the case > of the RTP > MIB > a session is defined by a destination address, how would you put both > sessions into the MIB as one entry if they have separate destination > addresses ? > > Now this is different in Multicast because the destination > address for ALL > flows is a multicast address that is common for all senders. > > Bill > > ______________________________________________ > Bill Strahm Programming today is a race between > bill.strahm@ software engineers striving to build > intel.com bigger and better idiot-proof programs, > (503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook > I am not speaking for Intel. And Intel rarely speaks for me > > > > -----Original Message----- > > From: Vincent_Virgilio@nmss.com [mailto:Vincent_Virgilio@nmss.com] > > Sent: Wednesday, August 30, 2000 8:18 AM > > To: Mark Baugher > > Cc: rem-conf@es.net > > Subject: Re: Fwd: Re: Define a unicast RTP session. > > > > > > > > Hi Mark, > > > > Thanks for the response. > > > > There seems to be plenty of evidence that unicast sessions can be > > bidirectional, which means that both endpoints in a two party > > call would be > > participating in the same single session. In fact, this may > > be the typical > > case. If each entry in the RTP MIB session table > identifies a unique > > session, shouldn't there, then, be one MIB session entry at > > each endpoint? > > If the mode were simply host, and not host-monitor, each > > endpoint would > > have this one session table entry, along with one entry in > > the sender table > > and another in the receiver table (all with the same > session index) - > > again, assuming bidirectional flow in the session. > > > > Please advise! > > > > Vince Virgilio > > > > > > > > > > > > From rem-conf Wed Aug 30 16:10:59 2000 From rem-conf-request@es.net Wed Aug 30 16:10:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UGz5-0006Mk-00; Wed, 30 Aug 2000 16:09:31 -0700 Received: from brisco.passedge.com [63.97.251.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13UGz3-0006MP-00; Wed, 30 Aug 2000 16:09:29 -0700 Received: from mblaptop.passedge.com (MBAUGHER-LAPTOP [63.97.251.230]) by brisco.passedge.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QXSBWPDK; Wed, 30 Aug 2000 16:10:52 -0700 Message-Id: <4.3.1.0.20000830160543.00c04f00@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 30 Aug 2000 16:09:26 -0700 To: Vincent_Virgilio@nmss.com,rem-conf@es.net From: Mark Baugher Subject: Re: Fwd: Re: Define a unicast RTP session. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vincent If I wanted my note to you posted to rem conf, I would have done that myself. Mark At 05:06 PM 8/30/00 -0500, Vincent_Virgilio@nmss.com wrote: >Again, so that others can follow . . . here's that latest, warts and all. > >---------------------- Forwarded by Vincent Virgilio/Natural >MicroSystems/US on 08/30/2000 05:06 PM --------------------------- > > >Vincent Virgilio >08/30/2000 04:55 PM > >To: mbaugher@passedge.com, bill.strahm@intel.com >cc: >Subject: Re: Fwd: Re: Define a unicast RTP session. > >Of course, the below comment about uni-multicast is quite dumb if the >session index has to map to a single session table entry . . . > >Vince Virgilio > >---------------------- Forwarded by Vincent Virgilio/Natural >MicroSystems/US on 08/30/2000 04:54 PM --------------------------- > > >Vincent Virgilio >08/30/2000 04:29 PM > >To: Mark Baugher >cc: bill.strahm@intel.com >Subject: Re: Fwd: Re: Define a unicast RTP session. (Document link: > Vincent Virgilio) > >Hi Mark (and Bill), > >When you say "bidirectional, unicast RTP streams" you mean two opposite >flows, right? According to Bill, the definition of an RTP session in >section 3 of RFC 1889 is unclear whether such a scenario constitutes one or >two sessions. I say one, he says two. I used subsequent drafts of the RFC >to prove my point. Bill rightly pointed out that was invalid of me to do >so. Still, on further inspection, I maintain that the original section 3 >definition is singular (which implies multiple unicast destinations per >session), and that the first paragraph of section 7.1 in the same document >explicitly says that there is such a thing as a two-party bidirectional >unicast session. Within that paragraph, "clouds" and sessions are equated, >and a cloud may be defined by a pair of unicast network addresses. > >I don't think things get ugly for uni-multicast; the tables just get >bigger. Then, given the definition that permits multiple destination >addresses per session, there would be multiple entries in the session table >for a single session, each containing the same session index, but a unique >remote address. The local address would remain the same across all such >entries. To gets statistics for the whole session, accumulate across all >entries with same index. The impact on sender and receiver tables is >negligible, in size only, I think. > >Even so, uni-multicast is not explicitly allowed by RFC 1889. The session >definition in section 3 is constrained to two participants in the first >paragraph of section 7.1. > >What do you guys think? Actually, your session definition would greatly >simplify some work I'm about to do. Which is to say, I have no vested >interest in this argument! I have nothing to do with "H-media" people at >all. > >Vince Virgilio > > > > >Mark Baugher on 08/30/2000 04:02:49 PM > >To: Vincent_Virgilio@nmss.com, bill.strahm@intel.com >cc: >Subject: Re: Fwd: Re: Define a unicast RTP session. > > >hi > We had H-media MIB participation in the RTP MIB. I did not mean to say >that unicast was difficult, but that there seems to be some confusion since >the issue has popped up a few times on the list. I don't think the person >or persons who raised the issue were always satisfied with the outcome. >One obvious source of confusion is that you cannot talk about a unicast >"session" for bidirectional, unicast RTP streams since there are two >sessions, not one, in this scenario. So I don't know of any ready-made >nomenclature for distinguishing two sessions in bidirectional unicast RTP >communications from two unrelated, unidirectional, unicast sessions. It's >not hard, per se. It works though I find myself getting confused when >switching from unicast to multicast. could be a personal problem, however. > >Mark > >At 03:48 PM 8/30/00 -0500, Vincent_Virgilio@nmss.com wrote: > > >Hi Mark, > > > >I had no idea that this question was so difficult. Obviously you have the > >last say in how your MIB should be implemented. I am concerned, though, > >that the view of a system given by the MIB will differ from the > >configuration negotiated through H.323. For example, there could be twice > >as many sessions observed in the former as negotiated in the latter. > > > >Vince Virgilio > > > > > > > > > > > >Mark Baugher on 08/30/2000 03:42:07 PM > > > >To: Vincent_Virgilio@nmss.com > >cc: > >Subject: Re: Fwd: Re: Define a unicast RTP session. > > > > > >Vincent > > Bill said what I think in his note. I think there is a lot of >confusion > >about unicast in RTP. > > > >Mark > >At 10:18 AM 8/30/00 -0500, you wrote: > > > > >Hi Mark, > > > > > >Thanks for the response. > > > > > >There seems to be plenty of evidence that unicast sessions can be > > >bidirectional, which means that both endpoints in a two party call would > >be > > >participating in the same single session. In fact, this may be the > >typical > > >case. If each entry in the RTP MIB session table identifies a unique > > >session, shouldn't there, then, be one MIB session entry at each >endpoint? > > >If the mode were simply host, and not host-monitor, each endpoint would > > >have this one session table entry, along with one entry in the sender > >table > > >and another in the receiver table (all with the same session index) - > > >again, assuming bidirectional flow in the session. > > > > > >Please advise! > > > > > >Vince Virgilio > > > > > >Mark Baugher > >PGP Fingerprint > >01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C > > > > > > >Mark Baugher >PGP Fingerprint >01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C > > > > > > > Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From rem-conf Wed Aug 30 22:20:32 2000 From rem-conf-request@es.net Wed Aug 30 22:20:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UMgV-0001v6-00; Wed, 30 Aug 2000 22:14:43 -0700 Received: from (abraracourcix.coming.fr) [212.155.170.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13UMgT-0001uo-00; Wed, 30 Aug 2000 22:14:41 -0700 Received: from 6756 [158.252.170.189] by abraracourcix.coming.fr (SMTPD32-4.03) id A99C5D2500D8; Thu, 31 Aug 2000 07:14:04 +03d00 To: qujei78@xmedia.ch From: qujei78@xmedia.ch (K.L.P. Inc) Comments: Authenticated sender is Subject: Call 24 hours a day!! Message-Id: <200008312892UAA33733@fgtyhjui8p.coming.fr> Date: Thu, 31 Aug 100 07:15:40 +03d00 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list UNIVERSITY DIPLOMAS Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledge and life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1-212-465-3248 Call 24 hours a day, 7 days a week, including Sundays and holidays. remove---- red4402@excite.com 598508821995029459852547 GBachelors, From rem-conf Thu Aug 31 07:09:52 2000 From rem-conf-request@es.net Thu Aug 31 07:09:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UUxx-00078a-00; Thu, 31 Aug 2000 07:05:17 -0700 Received: from gateus.nmss.com (ns.nmss.com) [208.236.204.65] by mail1.es.net with smtp (Exim 1.81 #2) id 13UUxv-00078Q-00; Thu, 31 Aug 2000 07:05:15 -0700 Received: from NMS_Notes4.nmss.com by ns.nmss.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 31 Aug 2000 09:03:15 UT Subject: Re: Fwd: Re: Define a unicast RTP session. To: rem-conf@es.net Bcc: From: Vincent_Virgilio@nmss.com Date: Thu, 31 Aug 2000 08:58:35 -0500 Message-ID: X-MIMETrack: Serialize by Router on NMS_Notes4/Natural MicroSystems/US(Release 5.0.4 |June 8, 2000) at 08/31/2000 10:05:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Mark, I apologize. Won't happen again. Vince Virgilio Mark Baugher wrote: >Vincent > If I wanted my note to you posted to rem conf, I would have done that myself. > >Mark From rem-conf Thu Aug 31 15:07:57 2000 From rem-conf-request@es.net Thu Aug 31 15:07:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UcEc-0003aD-00; Thu, 31 Aug 2000 14:50:58 -0700 Received: from (broadsoft.com) [161.58.239.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 13UcEa-0003a3-00; Thu, 31 Aug 2000 14:50:56 -0700 Received: from raymond ([216.181.56.35]) by broadsoft.com (8.8.8) id RAA53735; Thu, 31 Aug 2000 17:50:55 -0400 (EDT) From: "Doug Sauder" To: Subject: RE: New congestion control text in RTP spec Date: Thu, 31 Aug 2000 17:54:47 -0400 Message-ID: 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 In-Reply-To: <200008151656.MAA00445@newdev.harvard.edu> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REM-CONF members, I think I have read all of this thread now. My comment is that I think a real paradigm shift is necessary when considering congestion control in RTP. The congestion control for TCP originates from a different era. The conditions have changed drastically since then. First, and foremost, you won't find the kind of "be nice, be fair" attitude that prevailed before about 1995. The Internet today is big business. Individuals and companies pay for Internet service, and they want to get nothing less than what they paid for. So, what I think this really comes down to is -- as another in this thread has pointed out -- that it all has to do with diffserve, policing, and so on. I think it's been an implicit assumption throughout most of this discussion that most RTP traffic should be labeled with a high priority in almost all cases. I know that when I am listening to streaming audio, I don't want to see the quality decline when I decide to check my email at the POP server, especially if the agreement I have with my ISP should allow for both to happen at the same time (a DSL connection, for example). On the other hand, someone else mentioned receiving streaming audio via HTTP. So, priority can't be inferred by transport protocol alone. But, to get back to my point, *any* congestion control for RTP that does not take into consideration some kind of differentiated services it overly simplistic. Maybe UDP should only "compete" with UDP. That would be simple to police: X amount of bandwith must be allowed for UDP, Y amount bandwith must be allowed for TCP, and Z amount of bandwith can be allowed for either. In other words, there would be a minimum (guaranteed) and maximum bandwidth for UDP (and therefore RTP). To take these comments in a slightly different direction, I question the need for congestion control. I get the impression (which might be a wrong impression) that the real limiting factor in the use of the Internet is most likely going to be at the very edge of the network. Content providers are limited by the capacity of their servers. Home users and small businesses are limited by their connection speeds. Finally, considering that the Internet is such big business nowadays, won't this congestion "problem" just be taken care of by free market economics? Suppose a large company wants VPN service from a large ISP, and that that large company wants voice and data convergence. (They'll be using RTP to carry all the telephone traffic between their offices around the world.) This sounds to me like it's more a problem of traffic engineering than a problem of congestion control. And the ISP has great incentive to solve it. Doug Sauder Software Engineer BroadSoft, Inc > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Tuesday, August 15, 2000 12:56 > To: rem-conf@es.net > Subject: Re: New congestion control text in RTP spec > > > > What I was trying to imply in my text suggestion is that one should try > > to specify a congestion control behavior that takes the applications > > needs as well as the networks state in consideration and not merely the > > network state (loss and delay) as is currently the case for most > > congestion control schemes (and certainly for TCP) or the applications > > needs as Thomas was suggesting > > > > Such a control behavior should on the one hand lead to a smooth > > perceived QoS and should not result in starving competing flows. > > the IESG will look very hard at any proposal that does not protect > the network from congestive collapse and do so in a way that does not > unfairly harm the other traffic on the network > > Scott > > From rem-conf Thu Aug 31 16:48:37 2000 From rem-conf-request@es.net Thu Aug 31 16:48:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Udzh-0005I4-00; Thu, 31 Aug 2000 16:43:41 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Udze-0005Ho-00; Thu, 31 Aug 2000 16:43:39 -0700 Received: from accordion (accordion.anu.edu.au [150.203.20.58]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id JAA28872 for ; Fri, 1 Sep 2000 09:43:34 +1000 (EST) Message-Id: <3.0.32.20000901104335.01173410@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 01 Sep 2000 10:43:35 +1100 To: From: Markus Buchhorn Subject: RE: New congestion control text in RTP spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 17:54 31/08/00 -0400, Doug Sauder made some good points: >My comment is that I think a real paradigm shift is necessary when >considering congestion control in RTP. [...] >So, what I think this really comes down to is -- as another in this thread >has pointed out -- that it all has to do with diffserve, policing, and so >on. Agreed. But I'm not sure if that is a paradigm shift, or simply finally using the TOS byte in an intelligent fashion. Ultimately it comes down to which layer should handle traffic management and which should handle application management. A similar argument came up in multicast-addressing schemes for high-bandwidth streams in Internet2-like environments (do you allocate an address block, just so you can block some high-bandwidth sessions from hitting narrow-band links? Or to stop users requesting a stream they can never fully receive?). > I think it's been an implicit assumption throughout most of this >discussion that most RTP traffic should be labeled with a high priority in >almost all cases. [...] > On the other hand, someone else mentioned receiving streaming audio via HTTP. So, >priority can't be inferred by transport protocol alone. streaming and http just shouldn't be in the same sentence. Just as non "real-time" traffic that is multicast shouldn't be run over RTP (e.g. digital fountains, bulk data transfers, etc.). http is way overloaded because it beats many firewalls, and the client is cheap. >Finally, considering that the Internet is such big business nowadays, won't >this congestion "problem" just be taken care of by free market economics? I agree that ultimately on the commercial Internet it is the *end-user* who should decide their priorities (and abilities), probably on an application-by-application basis. Make it extremely dynamic if at all possible. Is this RTP stream a live video-conference/interactive surgery or some streamed content that can handle many seconds of buffering? Same as on TCP, is it an ftp session from Microsoft Updates, or my Doctor upgrading my pacemaker firmware over the network? :-) Looks the same to the network (but are hopefully NOT equally likely to kill me ;-) ). I will know far more about what I'm running than my ISP (unless we have a distinct protocol tag for *every* type of application), and how I want it handled - and I can decide how much I'm prepared to pay at the time. Let the users decide - they are the ultimate "intelligent" edge of the network after all. Then bill them accordingly. Packet Democracy or Capitalism - pick one :-) Cheers, Markus PS I haven't got a pacemaker, for any concerned souls out there. Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Thu Aug 31 22:45:40 2000 From rem-conf-request@es.net Thu Aug 31 22:45:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13UjaV-0001UV-00; Thu, 31 Aug 2000 22:42:03 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13UjaT-0001T5-00; Thu, 31 Aug 2000 22:42:01 -0700 Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA05014; Fri, 1 Sep 2000 01:43:34 -0400 (EDT) Message-ID: <39AF4161.7FE4D681@dynamicsoft.com> Date: Fri, 01 Sep 2000 01:40:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Strahm, Bill" CC: "'Vincent_Virgilio@nmss.com'" , Mark Baugher , rem-conf@es.net Subject: Re: Fwd: Re: Define a unicast RTP session. References: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E9@orsmsx41.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Strahm, Bill" wrote: > > I think I'll step in as another one of the RTP MIB authors who had to > wrangle with this issue... > > We took the definition from 1889 quite literally From section 3 > > RTP session: The association among a set of participants > communicating with RTP. For each participant, the session is > defined by a particular pair of destination transport addresses > (one network address plus a port pair for RTP and RTCP). The > destination transport address pair may be common for all > participants, as in the case of IP multicast, or may be > different for each, as in the case of individual unicast network > addresses plus a common port pair. In a multimedia session, > each medium is carried in a separate RTP session with its own > RTCP packets. The multiple RTP sessions are distinguished by > different port number pairs and/or different multicast > addresses. > > Therefore in the case of unicast there ARE two sessions, because there are > two different destination transport addresses. Did we get it right, I hope > so (we are on track to have an RFC issued). This was my understanding, and is exactly the reason I claimed it was two in the first place. Also, if one assumes that a single m line in SDP means one session, then with SIPs usage of SDP we also get two sessions - thats because one SDP is sent in the INVITE (indicating the receive port pairs of the caller), and another, different SDP in the 200 OK (indicating the receive port pairs of the callee). This is what I meant by mentioning that the annexes in SIP should be checked for more info. -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: (732) 741-7244 http://www.dynamicsoft.com