From exim@www1.ietf.org Mon Dec 1 09:36:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12222 for ; Mon, 1 Dec 2003 09:36:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp9z-0002iV-60 for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 09:36:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EaNno010442 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 09:36:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp9g-0002Yu-Vq; Mon, 01 Dec 2003 09:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQp9E-0002XD-Uk for avt@optimus.ietf.org; Mon, 01 Dec 2003 09:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12176; Mon, 1 Dec 2003 09:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQp9C-0002iF-00; Mon, 01 Dec 2003 09:35:34 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQp9C-0002i3-00; Mon, 01 Dec 2003 09:35:34 -0500 Received: from mramalho-w2k.cisco.com (sjc-vpn4-385.cisco.com [10.21.81.129]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1EYxAu009857; Mon, 1 Dec 2003 06:35:00 -0800 (PST) Message-Id: <4.3.2.7.2.20031201084844.00b3c1c0@mira-sjc5-e.cisco.com> X-Sender: mramalho@mira-sjc5-e.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Dec 2003 09:34:56 -0500 To: Stephen Casner From: "Michael A. Ramalho" Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide Cc: Marshall Eubanks , AVT WG , dccp@ietf.org In-Reply-To: <20031127105852.V32289@oak.packetdesign.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , All, I think Steve has hit the essence of the issue. Some comments in-line. Michael Ramalho At 11:10 AM 11/27/2003 -0800, Stephen Casner wrote: >Marshall, > > > most TCP implementations are badly tuned for broadband > > and don't actually deliver much more than 500 kbps at best. > >Banking on that for a media protocol design would be unwise. > > > I notice empirically that UDP flat rate audio and video can co-exist > > with tcp in practice, and wonder if poor tcp performance might be > > one of the reasons why. > >Sure. Flat-rate is the key. If the UDP traffic does not back off in >response to TCP's probing, then TCP stays within the bandwidth that is >left. The root of this whole discussion is that if you have ever more >flat-rate UDP traffic, it will push all the TCP out of the way until >the network is saturated with UDP traffic, then the UDP streams will >experience loss. I did some research on this issue for a major RBOC about 5 years ago when VoIP was the "imminent threat" to the PSTN. The study was for "best effort" networks (the story changes with QoS provisioned flows for UDP/VoIP). The whole issue on whether UDP-based applications would "crowd out" TCP to oblivion was the MIX of traffic ON A PARTICULAR service providers IP network. If VoIP/UDP was a minority traffic of the mix ... TCP backed off a little ... was never starved to oblivion (because UDP was a minority traffic type) ... network collapse did not occur ... and life went on (even though the UDP was "unfair" to TCP in the bandwidth sharing socialistic sense). If, however, the dominant traffic was VoIP/UDP (perhaps an IP network set up as an Internet Telephone Service Provider) the story was different. First, said service provider needed to size (that is traffic engineer) their network for: 1) all the VoIP/UDP traffic expected to be "admitted" and 2) have enough bandwidth "left over" for the anticipated TCP traffic running on the network (e.g., VoIP signalling, messaging, etc.). There is no getting around "traffic engineering" for this case! It becomes very much like QoS provisioning your whole network, except that you size the network based on monitoring UDP and TCP trends rather than admitting on every UDP flow. You also "allocate" some percentage of your network for TCP traffic (to ensure it's timely delivery/performance). This is doable for large backbone networks due to the law of large numbers. Now forgetting "fairness" for a while and considering only: 1) network collapse and 2) "best effort networks" ... the question comes down to insuring that UDP applications do not EVER become close to being the dominant traffic source. One way is forecasting - monitor your network to make sure UDP isn't becoming your dominant traffic source. If UDP applications are becoming a dominant source you must do something about it! You must either: 1) specifically admit/police UDP traffic (essentially providing a QoS mechanism for the flow or aggregate flow) or 2) design something in DCCP (or equivalent transport) to back it off or shut it down if the required rate changes are "too large". [This is a vast simplification. The needed traffic engineering would also consider the performance of the remaining TCP applications in the provisioning/sizing of the network design.] If DCCP only did #2 above .... it would still be "unfair to TCP" but it's unfairness would not lead to network collapse. Unfortunately the DCCP flow cannot figure out that the cause of the congestion is that the dominant traffic type in a given network traversed is non-elastic (or near in-elastic). This is a hard problem - you need network help here (use congestion notifications to provide hints to the transport?). I see DCCP as trying to go a step further and, out of "bandwidth fairness" to TCP, it is trying rate control the inherently "near in-elastic" application. This leads to the present quandary of DCCPs unsuitability for VoIP/UDP flows in best effort networks. Sorry for the long post - but this is a hard problem. >The TCP folks say that UDP traffic is unfair; DCCP >is being developed as a response. Now in this conversation, we're >discussing how to keep TCP from pushing DCCP out of the way. This is hard because any particular flow doesn't know the overall network condition. > -- Steve > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 11:38:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16856 for ; Mon, 1 Dec 2003 11:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr3x-0000Ud-6t for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 11:38:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1GcHxa001891 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 11:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr3h-0000Ti-T7; Mon, 01 Dec 2003 11:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr2x-0000FI-D6 for avt@optimus.ietf.org; Mon, 01 Dec 2003 11:37:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16800 for ; Mon, 1 Dec 2003 11:37:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr2v-0004qW-00 for avt@ietf.org; Mon, 01 Dec 2003 11:37:14 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AQr2v-0004q1-00 for avt@ietf.org; Mon, 01 Dec 2003 11:37:13 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB1GaZf23460 for ; Mon, 1 Dec 2003 11:36:35 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLSTDNL4; Mon, 1 Dec 2003 11:36:35 -0500 Received: from nortelnetworks.com (acart1d3.ca.nortel.com [47.129.129.79]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM8JZ; Mon, 1 Dec 2003 11:36:36 -0500 Message-ID: <3FCB6E12.9060500@nortelnetworks.com> Date: Mon, 01 Dec 2003 11:36:34 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Missing events in RFC 2833 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm finding it a little difficult to see how some of the applications supported by RFC 2833 work without a few more events. Here are some examples: 1. V.18 text telephones interwork with a number of other text telephone types. The only event defined specifically for V.18 operation seems rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. There don't seem to be any events for Baudot or V.23 or for Bell 103 in calling mode. 2. Signalling System No. 5 has two sets of signals: line signals, which are tones controlling trunk state, and register signals, which convey digits with some supporting information. There is a timing constraint that register signalling must begin within 80 +/- 20 ms of the end of the "seize" line signal. Yet no event is defined for "seize", only for the register signals. It's a little hard to see how the receiving gateway can propagate KPx (the initial register signal) on time if it doesn't know that "seize" was playing, even if the sending end can recognize and report the start of KPx within the 20 ms tolerance. As I see it, the present set of events is useful only to transfer the register events from one gateway to another which will report them to call control rather than propagating them as tones. These missing events raise the issue of whether proposals to add events to RFC 2833 should be backed up by requirements documents describing their use. I have been adding brief application descriptions in my rewrite of 2833bis, as justification for the normative text which I have also been adding. (Basically just obvious stuff, missing the first time around and highlighted by Flemming's comments earlier this year.) I am hoping that this additional information prompts a critical review of the current set of 2833/2833bis events, with a view to rounding them out as necessary to make applications work well. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 13:16:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20749 for ; Mon, 1 Dec 2003 13:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsag-0007Bn-4W for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 13:16:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IGAML027587 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 13:16:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsaX-0007AB-CU; Mon, 01 Dec 2003 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsZY-00077e-MN for avt@optimus.ietf.org; Mon, 01 Dec 2003 13:15:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20613 for ; Mon, 1 Dec 2003 13:14:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsZW-0006Ax-00 for avt@ietf.org; Mon, 01 Dec 2003 13:14:58 -0500 Received: from dhcp-34-73.cs.berkeley.edu ([128.32.34.73]) by ietf-mx with esmtp (Exim 4.12) id 1AQsZW-0006Aq-00 for avt@ietf.org; Mon, 01 Dec 2003 13:14:58 -0500 Received: by dhcp-34-73.CS.Berkeley.EDU (Postfix, from userid 501) id 39A446B890; Mon, 1 Dec 2003 10:14:50 -0800 (PST) To: avt@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide Message-Id: <20031201181450.39A446B890@dhcp-34-73.CS.Berkeley.EDU> Date: Mon, 1 Dec 2003 10:14:50 -0800 (PST) From: lazzaro@dhcp-34-73.CS.Berkeley.EDU (lazzaro) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > "Michael A. Ramalho" > > If UDP applications are becoming a dominant source you must do > something about it! You must either: > > 1) specifically admit/police UDP traffic (essentially providing > a QoS mechanism for the flow or aggregate flow) This is an opportunity, folks -- for QoS deployment, for multicast deployment, and for the migration of real-time non-standardized UDP apps like networked games to RTP and SIP (to take advantage of QoS and multicast-enabled networks). --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 13:17:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20822 for ; Mon, 1 Dec 2003 13:17:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsbX-0007L5-6l for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 13:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IH2sZ028096 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 13:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsbV-0007I8-T1; Mon, 01 Dec 2003 13:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQsap-0007Bv-44 for avt@optimus.ietf.org; Mon, 01 Dec 2003 13:16:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20653 for ; Mon, 1 Dec 2003 13:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQsan-0006Bq-00 for avt@ietf.org; Mon, 01 Dec 2003 13:16:17 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AQsam-0006Bn-00 for avt@ietf.org; Mon, 01 Dec 2003 13:16:16 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hB1IGFTA002572 for ; Mon, 1 Dec 2003 10:16:15 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hB1IGEFj002571 for avt@ietf.org; Mon, 1 Dec 2003 10:16:14 -0800 (PST) Date: Mon, 1 Dec 2003 10:16:14 -0800 (PST) From: John Lazzaro Message-Id: <200312011816.hB1IGEFj002571@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > "Michael A. Ramalho" > > If UDP applications are becoming a dominant source you must do > something about it! You must either: > > 1) specifically admit/police UDP traffic (essentially providing > a QoS mechanism for the flow or aggregate flow) This is an opportunity, folks -- for QoS deployment, for multicast deployment, and for the migration of real-time non-standardized UDP apps like networked games to RTP and SIP (to take advantage of QoS and multicast-enabled networks). --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 15:21:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26678 for ; Mon, 1 Dec 2003 15:21:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuXp-0006Qe-Qq for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 15:21:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KLLiY024706 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 15:21:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuXX-0006Ho-Tk; Mon, 01 Dec 2003 15:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuWp-0006Gs-Tp for avt@optimus.ietf.org; Mon, 01 Dec 2003 15:20:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26573; Mon, 1 Dec 2003 15:20:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuWn-0007bt-00; Mon, 01 Dec 2003 15:20:17 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AQuWn-0007bh-00; Mon, 01 Dec 2003 15:20:17 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hB1KK7s13621; Mon, 1 Dec 2003 12:20:07 -0800 (PST) Message-Id: <200312012020.hB1KK7s13621@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 01 Dec 2003 12:20:07 -0800 Subject: [AVT] RFC 3640 on RTP Payload Format for Transport of MPEG-4 Elementary Streams Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3640 Title: RTP Payload Format for Transport of MPEG-4 Elementary Streams Author(s): J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric Status: Standards Track Date: November 2003 Mailbox: jan.vandermeer@philips.com, dmackie@apple.com, viswanathan.swaminathan@sun.com, singer@apple.com, philippe.gentric@philips.com Pages: 43 Characters: 102606 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-mpeg4-simple-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3640.txt The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031201121840.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3640 --OtherAccess Content-Type: Message/External-body; name="rfc3640.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031201121840.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 16:06:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29615 for ; Mon, 1 Dec 2003 16:06:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvF8-00024N-M4 for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 16:06:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1L66o3007929 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 16:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvF3-00023J-MW; Mon, 01 Dec 2003 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvEg-00022Z-IV for avt@optimus.ietf.org; Mon, 01 Dec 2003 16:05:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29574 for ; Mon, 1 Dec 2003 16:05:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvEe-0000qC-00 for avt@ietf.org; Mon, 01 Dec 2003 16:05:36 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AQvEe-0000o6-00 for avt@ietf.org; Mon, 01 Dec 2003 16:05:36 -0500 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hB1L4wHW024949; Mon, 1 Dec 2003 13:04:58 -0800 (PST) (envelope-from casner@acm.org) Date: Mon, 1 Dec 2003 13:04:58 -0800 (PST) From: Stephen Casner To: AVT WG Subject: Re: [AVT] RFC 3640 on RTP Payload Format for Transport of MPEG-4 Elementary Streams In-Reply-To: <200312012020.hB1KK7s13621@gamma.isi.edu> Message-ID: <20031201130356.J32976@ash.packetdesign.com> References: <200312012020.hB1KK7s13621@gamma.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Mon, 1 Dec 2003 rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3640 > > Title: RTP Payload Format for Transport of MPEG-4 > Elementary Streams > Author(s): J. van der Meer, D. Mackie, V. Swaminathan, > D. Singer, P. Gentric > Status: Standards Track > Date: November 2003 Yea! -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 1 17:21:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05977 for ; Mon, 1 Dec 2003 17:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwPs-0007Hm-TY for avt-archive@odin.ietf.org; Mon, 01 Dec 2003 17:21:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1MLG0q028006 for avt-archive@odin.ietf.org; Mon, 1 Dec 2003 17:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwPd-0007Gs-TD; Mon, 01 Dec 2003 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQwP1-0007Fs-WF for avt@optimus.ietf.org; Mon, 01 Dec 2003 17:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05749 for ; Mon, 1 Dec 2003 17:20:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQwOz-0003c1-00 for avt@ietf.org; Mon, 01 Dec 2003 17:20:21 -0500 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 1AQwOy-0003bT-00 for avt@ietf.org; Mon, 01 Dec 2003 17:20:20 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id hB1MKFo03742; Mon, 1 Dec 2003 23:20:16 +0100 (CET) From: "Gunnar Hellstrom" To: "avt IETF" , "Gregg Vanderheiden" , "Paul Jones" , "Toip list" Subject: FW: [AVT] Missing events in RFC 2833 Date: Mon, 1 Dec 2003 23:20:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Message-Flag: Follow up Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Below, Tom Taylor asks if there is any interest to complete the textphone related tone events in RFC2833 so that all V.18 submodes can be transported with RFC2833. We have to verify that we have satisfying detection and transport methods in RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can leave RFC2833 half done for text transport. I would like to do so, but then the market forces must be strong enough to make RFC2793 and textphone detection commonplace. Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, but with less exact information than the native V.18 has. We have no analysis if that task is realistic, nor if it is likely to be implemented by IP endpoint developers. ( The missing events for complete text transport are probably: V.21 data in lo channel at 110 bits/s Bell 103 hi channel data at 300 bits/s Bell 103 lo channel data at 300 bits/s V.23 data at 1200 bits/s V.23 data at 75 bits/s Baudot data at 45.45 bits/s Baudot data at 50 bits/s (assuming that V.8 signals and V.21 at 300 bits/s in both directions and DTMF are covered ) Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Monday, December 01, 2003 5:37 PM To: avt@ietf.org Subject: [AVT] Missing events in RFC 2833 I'm finding it a little difficult to see how some of the applications supported by RFC 2833 work without a few more events. Here are some examples: 1. V.18 text telephones interwork with a number of other text telephone types. The only event defined specifically for V.18 operation seems rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. There don't seem to be any events for Baudot or V.23 or for Bell 103 in calling mode. 2. Signalling System No. 5 has two sets of signals: line signals, which are tones controlling trunk state, and register signals, which convey digits with some supporting information. There is a timing constraint that register signalling must begin within 80 +/- 20 ms of the end of the "seize" line signal. Yet no event is defined for "seize", only for the register signals. It's a little hard to see how the receiving gateway can propagate KPx (the initial register signal) on time if it doesn't know that "seize" was playing, even if the sending end can recognize and report the start of KPx within the 20 ms tolerance. As I see it, the present set of events is useful only to transfer the register events from one gateway to another which will report them to call control rather than propagating them as tones. These missing events raise the issue of whether proposals to add events to RFC 2833 should be backed up by requirements documents describing their use. I have been adding brief application descriptions in my rewrite of 2833bis, as justification for the normative text which I have also been adding. (Basically just obvious stuff, missing the first time around and highlighted by Flemming's comments earlier this year.) I am hoping that this additional information prompts a critical review of the current set of 2833/2833bis events, with a view to rounding them out as necessary to make applications work well. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 11:32:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25349 for ; Tue, 2 Dec 2003 11:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDRl-0007kC-U7 for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 11:32:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GWLJg029767 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 11:32:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDRR-0007il-TM; Tue, 02 Dec 2003 11:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDRM-0007iN-4Q for avt@optimus.ietf.org; Tue, 02 Dec 2003 11:31:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25323 for ; Tue, 2 Dec 2003 11:31:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDRI-0003cg-00 for avt@ietf.org; Tue, 02 Dec 2003 11:31:52 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ARDRH-0003bn-00 for avt@ietf.org; Tue, 02 Dec 2003 11:31:51 -0500 Received: from [129.215.30.232] (port=1377 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ARDQl-0003dV-00 for avt@ietf.org; Tue, 02 Dec 2003 16:31:19 +0000 Date: Tue, 2 Dec 2003 16:30:57 +0000 From: Colin Perkins To: avt@ietf.org Message-Id: <20031202163057.2cb5f78f.csp@csperkins.org> In-Reply-To: <200311212103.QAA02407@ietf.org> References: <200311212103.QAA02407@ietf.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: I-D ACTION:draft-ietf-avt-rfc2793bis-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RTP Payload for Text Conversation > Author(s) : G. Hellstrom > Filename : draft-ietf-avt-rfc2793bis-00.txt > Pages : 19 > Date : 2003-11-21 > > This memo describes how to carry text conversation session contents > in RTP packets. Text conversation session contents are specified in > ITU-T Recommendation T.140 [1]. > > Text conversation is used alone or in connection to other > conversational facilities such as video and voice, to form multimedia > conversation services. > > This RTP payload description contains an optional possibility to > include redundant text from already transmitted packets in order to > reduce the risk of text loss caused by packet loss. The redundancy > coding follows RFC 2198. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-00.txt A few comments on this draft: In Section 2, the draft needs to cite RFC 2119 as a numbered reference In Section 3, why "SHOULD be used" rather than "MUST be used"? Regarding Sections 3.4 and 3.5, I think it's important to distinguish between the text/t140 format - which imposes restrictions on the type of FEC which can be used - and the audio/t140 format which is largely agnostic on the FEC/redundancy format used. Section 3.5 can be interpreted to imply that the only form of FEC that can be used is RFC 2733, but should allow the use of FEC with RFC 2733 as an example. Section 3.7 needs to require that the clock frequency for audio/t140 SHOULD match that of any audio send as part of the same RTP session. As I mentioned in the meeting, there are corner cases where the T140 block counter can't detect loss (for example consider, when switching from text to audio, I can't distinguish between the last packet of text and first packet of audio being lost, or the first two packets of audio being lost - until I get the next text packet). Even if this is not considered aa issue, the draft needs to highlight the scenario, and explain why it's not an issue. How is the RTP M bit used? Usual audio conventions? In Section 5, the draft should note that jitter in the network may cause packets to arrive faster than the signalled cps for short periods of time. A receiver has to be aware that this might happen, and buffer to smooth the arrival rate, even if it signals the cps. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 11:57:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26913 for ; Tue, 2 Dec 2003 11:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDpk-0001n5-Ep for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 11:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Gv8VM006881 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 11:57:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDpe-0001lt-4D; Tue, 02 Dec 2003 11:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDpN-0001lO-L3 for avt@optimus.ietf.org; Tue, 02 Dec 2003 11:56:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26853 for ; Tue, 2 Dec 2003 11:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDpM-0004E2-00 for avt@ietf.org; Tue, 02 Dec 2003 11:56:44 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1ARDpL-0004Dz-00 for avt@ietf.org; Tue, 02 Dec 2003 11:56:43 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hB2GubBQ018777; Tue, 2 Dec 2003 11:56:39 -0500 Message-ID: <00c801c3b8f5$40ed2ed0$0401a8c0@berlin> From: "Paul E. Jones" To: "A vWijk" , , , , References: Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 Date: Tue, 2 Dec 2003 11:56:36 -0500 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Arnoud, RFC 2833 can be used to convey tone information (frequencies and durations), as well as tone events. It's not restricted to DTMF. RFC 2833 could potentially be used as an alternative to RFC 2793. A gateway or IP phone, for example, could simply examine the tones and convey those as "descriptions" (either frequency and duration information or event codes) over an IP network. The other end could then receive those descriptions and reproduce the tones. They would not have to understand the underlying textphone protocol. The problem with RFC 2833, as I see it, is that it stands at odds with the desire of folks on the ToIP mailing list to try to remove textphone signaling from the IP network. There has been a strong desire expressed to terminate that textphone signaling at the gateway and only use text on the IP network. Doing that, arguably, would make interfacing with IP-based IVR systems, IP-based voice/text-mail systems, or other IP-based systems much easier. I say "arguably" because some have suggested to me that it's very simple to write software that understand the textphone signals received in RFC 2833 packets... though I personally think it puts an unfortunate burden on a Pocket PC, for example. To this point, neither the ITU nor the IETF has considered RFC 2833 as an option or alternative to RFC 2793. I think this is probably an important topic that we should take up immediately, as both bodies are forging ahead with plans based on RFC 2793 only. Paul ----- Original Message ----- From: "A vWijk" To: ; ; ; ; Sent: Tuesday, December 02, 2003 7:45 AM Subject: Betr.: FW: [AVT] Missing events in RFC 2833 > Gunnar, > why is this desirable? > > We will have T.140 over RTP and in some cases over TCP/IP. > Why the tones? > > Or am I mixing things up again? RFC2833 is for DTMF signalling? > > greetz > > Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > >>> "Gunnar Hellstrom" 01-12-03 23:20 >>> > Below, Tom Taylor asks if there is any interest to complete the textphone > related tone events in RFC2833 so that all V.18 submodes can be transported > with RFC2833. > > We have to verify that we have satisfying detection and transport methods in > RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can > leave RFC2833 half done for text transport. > > I would like to do so, but then the market forces must be strong enough to > make RFC2793 and textphone detection commonplace. > > Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, > but with less exact information than the native V.18 has. We have no > analysis if that task is realistic, nor if it is likely to be implemented by > IP endpoint developers. > > ( The missing events for complete text transport are probably: > V.21 data in lo channel at 110 bits/s > Bell 103 hi channel data at 300 bits/s > Bell 103 lo channel data at 300 bits/s > V.23 data at 1200 bits/s > V.23 data at 75 bits/s > Baudot data at 45.45 bits/s > Baudot data at 50 bits/s > > (assuming that V.8 signals and V.21 at 300 bits/s in both directions and > DTMF are covered ) > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom > Taylor > Sent: Monday, December 01, 2003 5:37 PM > To: avt@ietf.org > Subject: [AVT] Missing events in RFC 2833 > > > I'm finding it a little difficult to see how some of the applications > supported by RFC 2833 work without a few more events. Here are some > examples: > > 1. V.18 text telephones interwork with a number of other text telephone > types. The only event defined specifically for V.18 operation seems > rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. > There don't seem to be any events for Baudot or V.23 or for Bell 103 in > calling mode. > > 2. Signalling System No. 5 has two sets of signals: line signals, which > are tones controlling trunk state, and register signals, which convey > digits with some supporting information. There is a timing constraint > that register signalling must begin within 80 +/- 20 ms of the end of > the "seize" line signal. Yet no event is defined for "seize", only for > the register signals. It's a little hard to see how the receiving > gateway can propagate KPx (the initial register signal) on time if it > doesn't know that "seize" was playing, even if the sending end can > recognize and report the start of KPx within the 20 ms tolerance. As I > see it, the present set of events is useful only to transfer the > register events from one gateway to another which will report them to > call control rather than propagating them as tones. > > These missing events raise the issue of whether proposals to add events > to RFC 2833 should be backed up by requirements documents describing > their use. I have been adding brief application descriptions in my > rewrite of 2833bis, as justification for the normative text which I have > also been adding. (Basically just obvious stuff, missing the first time > around and highlighted by Flemming's comments earlier this year.) I am > hoping that this additional information prompts a critical review of the > current set of 2833/2833bis events, with a view to rounding them out as > necessary to make applications work well. > > Tom Taylor > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/toip_archive/maillist.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 13:43:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01562 for ; Tue, 2 Dec 2003 13:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFUK-0000wR-Na for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 13:43:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ih80e003616 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 13:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFUD-0000vk-Gt; Tue, 02 Dec 2003 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARFTP-0000rv-KR for avt@optimus.ietf.org; Tue, 02 Dec 2003 13:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01528 for ; Tue, 2 Dec 2003 13:41:58 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARFTN-0005xv-00 for avt@ietf.org; Tue, 02 Dec 2003 13:42:09 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ARFTM-0005xs-00 for avt@ietf.org; Tue, 02 Dec 2003 13:42:09 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 498766CE71; Tue, 2 Dec 2003 19:42:07 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id BDB3A19C49; Tue, 2 Dec 2003 19:42:06 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 5F7A719C46; Tue, 2 Dec 2003 19:42:06 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id TAA11402; Tue, 2 Dec 2003 19:42:05 +0100 (MET) Subject: Re: [AVT] RFC 3640 on RTP Payload Format for Transport of MPEG-4 Elementary Streams To: Stephen Casner Cc: AVT WG X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 2 Dec 2003 19:39:12 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 02/12/2003 19:43:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , stephen you wrote: >> >> RFC 3640 >> >> Title: RTP Payload Format for Transport of MPEG-4 >> Elementary Streams >> Author(s): J. van der Meer, D. Mackie, V. Swaminathan, >> D. Singer, P. Gentric >> Status: Standards Track >> Date: November 2003 > >Yea! > > -- Steve double yea ! a bit of history: the subject was initiated at the Munich IETF meeting in August 1997 (39th) ! then at least 4 drafts were generated (?) and it went a bit asleep, then I started to work on it after the La Baule MPEG meeting in Octobre 2000 because audio frame aggregation was required for efficiency and made 8+ drafts for MultiSL/SingleSL in 2000 and 2001 (I lost the count !) Then based on crowd feedback the SL went out of the picture/story (the format remained the same ;-) and Jan made the 9 drafts of the "simple" series: so this adds up to at least 21 drafts ... almost 19 IETF meetings, plus probably as many MPEG meetings, going around the planet several times on the way, plus many different people and quite some work. So I would say it should go into the book named after a beer or speaking of beverage with bubbles (we all have our preferences ;-) I invite every one involved to try a new concept: the virtual distributed jet-lag-free toast: whenever it will be the evening for you today, wherever you are, raise your glass and shout: 3640!-) Anyway thanks everybody, for your help if you cared, for your patience if you did not ;-) Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 14:48:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04489 for ; Tue, 2 Dec 2003 14:48:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGVF-0004Md-Lp for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 14:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Jm9VF016769 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 14:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGV7-0004Lt-06; Tue, 02 Dec 2003 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGUk-0004LD-S2 for avt@optimus.ietf.org; Tue, 02 Dec 2003 14:47:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04454 for ; Tue, 2 Dec 2003 14:47:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGUh-00070J-00 for avt@ietf.org; Tue, 02 Dec 2003 14:47:35 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARGUh-00070G-00 for avt@ietf.org; Tue, 02 Dec 2003 14:47:35 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id hB2JlW0s004492; Tue, 2 Dec 2003 20:47:34 +0100 (CET) From: "Gunnar Hellstrom" To: "A vWijk" , , , , Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833 Date: Tue, 2 Dec 2003 20:47:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Arnoud and all, I do not think it is desirable to try to patch up RFC2833 to transport all kinds of textphone data events. In my view it is likely to be complex, unreliable and against the efforts to create mainstream conversational services for all with high functionality in the IP network. But I wanted to expose this question from Tom to the text conversation interested people to get your view, and give som good advice back to Tom, who is just now cleaning up RFC2833. You are rtight that RFC2833 started as a mechanism for DTMF transport and that is what it is most famous for. But have a look in it, and you will find that many other signals that are likely to appear in PSTN connections can be coded with RFC2833. If we had any wish to recreate the same tones at exit as was input, there could be a case for patching up RFC2833 to (detect and) transport all textphone data properly. Now, the case is the opposite, we want to disconnect the technologies in the both ends as much as possible, and have a pure text code in between. Therefore, complete V.18 in the PSTN edge and RFC2793 transport is the solution I see have a future. Agree? Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: A vWijk [mailto:A.vWijk@viataal.nl] Sent: Tuesday, December 02, 2003 1:45 PM To: avt@ietf.org; gunnar.hellstrom@omnitor.se; paulej@packetizer.com; toip@snowshore.com; gv@trace.wisc.edu Subject: Betr.: FW: [AVT] Missing events in RFC 2833 Gunnar, why is this desirable? We will have T.140 over RTP and in some cases over TCP/IP. Why the tones? Or am I mixing things up again? RFC2833 is for DTMF signalling? greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> "Gunnar Hellstrom" 01-12-03 23:20 >>> Below, Tom Taylor asks if there is any interest to complete the textphone related tone events in RFC2833 so that all V.18 submodes can be transported with RFC2833. We have to verify that we have satisfying detection and transport methods in RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can leave RFC2833 half done for text transport. I would like to do so, but then the market forces must be strong enough to make RFC2793 and textphone detection commonplace. Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, but with less exact information than the native V.18 has. We have no analysis if that task is realistic, nor if it is likely to be implemented by IP endpoint developers. ( The missing events for complete text transport are probably: V.21 data in lo channel at 110 bits/s Bell 103 hi channel data at 300 bits/s Bell 103 lo channel data at 300 bits/s V.23 data at 1200 bits/s V.23 data at 75 bits/s Baudot data at 45.45 bits/s Baudot data at 50 bits/s (assuming that V.8 signals and V.21 at 300 bits/s in both directions and DTMF are covered ) Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Monday, December 01, 2003 5:37 PM To: avt@ietf.org Subject: [AVT] Missing events in RFC 2833 I'm finding it a little difficult to see how some of the applications supported by RFC 2833 work without a few more events. Here are some examples: 1. V.18 text telephones interwork with a number of other text telephone types. The only event defined specifically for V.18 operation seems rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. There don't seem to be any events for Baudot or V.23 or for Bell 103 in calling mode. 2. Signalling System No. 5 has two sets of signals: line signals, which are tones controlling trunk state, and register signals, which convey digits with some supporting information. There is a timing constraint that register signalling must begin within 80 +/- 20 ms of the end of the "seize" line signal. Yet no event is defined for "seize", only for the register signals. It's a little hard to see how the receiving gateway can propagate KPx (the initial register signal) on time if it doesn't know that "seize" was playing, even if the sending end can recognize and report the start of KPx within the 20 ms tolerance. As I see it, the present set of events is useful only to transfer the register events from one gateway to another which will report them to call control rather than propagating them as tones. These missing events raise the issue of whether proposals to add events to RFC 2833 should be backed up by requirements documents describing their use. I have been adding brief application descriptions in my rewrite of 2833bis, as justification for the normative text which I have also been adding. (Basically just obvious stuff, missing the first time around and highlighted by Flemming's comments earlier this year.) I am hoping that this additional information prompts a critical review of the current set of 2833/2833bis events, with a view to rounding them out as necessary to make applications work well. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 15:34:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08367 for ; Tue, 2 Dec 2003 15:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHDg-0006WS-JD for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 15:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KY4BG025024 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 15:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHDc-0006Uj-VD; Tue, 02 Dec 2003 15:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHDU-0006UP-G1 for avt@optimus.ietf.org; Tue, 02 Dec 2003 15:33:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08213; Tue, 2 Dec 2003 15:33:38 -0500 (EST) Message-Id: <200312022033.PAA08213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Dec 2003 15:33:38 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ilbc-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --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 iLBC Speech Author(s) : A. Duric, S. Andersen Filename : draft-ietf-avt-rtp-ilbc-04.txt Pages : 12 Date : 2003-12-2 This document describes the RTP payload format for the internet Low Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ilbc-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-ilbc-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: <2003-12-2153912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ilbc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-2153912.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 16:05:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10907 for ; Tue, 2 Dec 2003 16:05:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHhp-0000FO-6o for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 16:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2L5DnG000900 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 16:05:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHhe-0000Dc-0W; Tue, 02 Dec 2003 16:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHh4-0000Co-JS for avt@optimus.ietf.org; Tue, 02 Dec 2003 16:04:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10863 for ; Tue, 2 Dec 2003 16:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHh2-0000sA-00 for avt@ietf.org; Tue, 02 Dec 2003 16:04:25 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1ARHh1-0000rF-00 for avt@ietf.org; Tue, 02 Dec 2003 16:04:23 -0500 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB2L2rU04786; Tue, 2 Dec 2003 16:02:53 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLY2GS3V; Tue, 2 Dec 2003 16:02:53 -0500 Received: from nortelnetworks.com (acart1d3.ca.nortel.com [47.129.129.79]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM8ZR; Tue, 2 Dec 2003 16:02:53 -0500 Message-ID: <3FCCFDFC.9080905@nortelnetworks.com> Date: Tue, 02 Dec 2003 16:02:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rkumar@cisco.com, avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Trunk unavailable event in 2833bis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What was the reasoning for not defining "trunk unavailable" as a state in 2833bis? It would seem natural to do so, and to say that if the duration expires without a refresh, the receiver assumes that the state has expired. (That is, you don't have to define and keep sending "trunk available" events.) Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 19:22:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25445 for ; Tue, 2 Dec 2003 19:22:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKmO-00025A-Po for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 19:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30M8jW007957 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 19:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKmG-00023c-Rp; Tue, 02 Dec 2003 19:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKlc-00022y-Ra for avt@optimus.ietf.org; Tue, 02 Dec 2003 19:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25424 for ; Tue, 2 Dec 2003 19:21:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKlb-0006KG-00 for avt@ietf.org; Tue, 02 Dec 2003 19:21:19 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARKla-0006KD-00 for avt@ietf.org; Tue, 02 Dec 2003 19:21:18 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB30LJsD009133 for ; Tue, 2 Dec 2003 16:21:19 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030021.hB30LJsD009133@coyote.icir.org> To: avt@ietf.org Date: Tue, 02 Dec 2003 16:21:19 -0800 From: Eddie Kohler Subject: [AVT] Is "congestion collapse" misleading? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , There was a discussion earlier about whether "congestion collapse" is a fair description of the situation when nonresponsive UDP flows cause TCP bandwidth to suffer. Well, the *situation* is a problem, and local administration cannot correct it. Say that S is sending a nonresponsive flow to R. At the same time A is sending a responsive flow to B. S-R and A-B share parts of a path. S ------+----------+-----> R | | | v A B S-R experiences a high loss rate, say somewhere between A and R. Sure, R's administrator can take steps to prevent other flows from/to R from degrading. But the A-B flow is affected too; and depending on loss rates and bandwidths, the A-B flow might "collapse", since S-R doesn't respond to loss rates. The user at R might or might not stop the flow. Anyway, we can't count on them. The Internet architecture should support this kind of topology, which isn't entirely unusual in practice. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 19:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25909 for ; Tue, 2 Dec 2003 19:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKzs-0002pG-0D for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 19:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30a3pb010837 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 19:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKzp-0002nk-Vk; Tue, 02 Dec 2003 19:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKzO-0002mp-0H for avt@optimus.ietf.org; Tue, 02 Dec 2003 19:35:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25861; Tue, 2 Dec 2003 19:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzM-0006UV-00; Tue, 02 Dec 2003 19:35:32 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARKzL-0006UR-00; Tue, 02 Dec 2003 19:35:31 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB30ZWsD009262; Tue, 2 Dec 2003 16:35:32 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030035.hB30ZWsD009262@coyote.icir.org> To: avt@ietf.org cc: dccp@ietf.org Date: Tue, 02 Dec 2003 16:35:32 -0800 From: Eddie Kohler Subject: [AVT] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , (To protect itself from "greedy TCP flows" gobbling up available bandwidth?) No. TFRC exists to smooth out responses to congestion. A single loss (such as that caused by TCP probing) does not halve the TFRC transmit rate. In many cases it will cause only small changes (which, as we've discussed, the application might be able to ignore). In many cases it will not change the rate at all. If the congested link has high levels of statistical multiplexing, the TCP flows won't likely gobble up the available bandwidth anyway -- even during a silent period. If the congested link has low levels of statmux -- like one DCCP flow and one TCP flow -- then yes, the TCP would try for the available bandwidth. And during a silent period, the TFRC flow would have to transmit something so it wasn't crowded out entirely. But this amount would be *half* the nominal rate, or perhaps less. Not twice. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 19:46:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26184 for ; Tue, 2 Dec 2003 19:46:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARL9Y-0003ZL-Ds for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 19:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30k4Os013679 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 19:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARL9V-0003Y1-Pj; Tue, 02 Dec 2003 19:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARL8W-0003WO-Nz for avt@optimus.ietf.org; Tue, 02 Dec 2003 19:45:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26154 for ; Tue, 2 Dec 2003 19:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARL8U-0006bQ-00 for avt@ietf.org; Tue, 02 Dec 2003 19:44:58 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARL8U-0006ap-00 for avt@ietf.org; Tue, 02 Dec 2003 19:44:58 -0500 Date: Tue, 2 Dec 2003 16:43:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <6677B3346233B94EBB11C0609351012002615C4E@vtg-um-e2k1.sj21ad.cisco.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Trunk unavailable event in 2833bis Thread-Index: AcO5L9l4lSKKBgeqQ/eR0JvEdNWWtwAAZypQ From: "Rajesh Kumar" To: "Tom Taylor" , Content-Transfer-Encoding: quoted-printable Subject: [AVT] RE: Trunk unavailable event in 2833bis Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This was at the recommendation of the AVT folks that on/off state signaling was out of the scope of RFC 2833.The trunk available acts like a per-DS0 AIS. In North America, you do not need it because you can use the signaling path to take individual DS0s out of service. In the ETSI countries, this is done by sending special patterns in the bearer path. Now you could use RTP to send those patterns but that would be less efficient since you would need to send the bit pattern continuously without using VAD. We concluded that an RFC 2833 event message with periodic, albeit longer, refresh was more efficient. Rajesh Kumar > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, December 02, 2003 1:03 PM > To: Rajesh Kumar; avt@ietf.org > Subject: Trunk unavailable event in 2833bis >=20 > What was the reasoning for not defining "trunk unavailable" as a state > in 2833bis? It would seem natural to do so, and to say that if the > duration expires without a refresh, the receiver assumes that the state > has expired. (That is, you don't have to define and keep sending "trunk > available" events.) >=20 > Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 19:49:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26307 for ; Tue, 2 Dec 2003 19:49:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLCP-0003o0-7s for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 19:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30n1aD014586 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 19:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLCO-0003mi-Ki; Tue, 02 Dec 2003 19:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLBR-0003hc-6Z for avt@optimus.ietf.org; Tue, 02 Dec 2003 19:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26234; Tue, 2 Dec 2003 19:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLBP-0006eP-00; Tue, 02 Dec 2003 19:47:59 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARLBO-0006eM-00; Tue, 02 Dec 2003 19:47:58 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB30lwsD009345; Tue, 2 Dec 2003 16:47:58 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030047.hB30lwsD009345@coyote.icir.org> To: avt@ietf.org cc: dccp@ietf.org Date: Tue, 02 Dec 2003 16:47:58 -0800 From: Eddie Kohler Subject: [AVT] Is dropping flows enough to avoid congestion collapse? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , There have been suggestions that dropping flows is enough to avoid congestion collapse, and that RTP-over-UDP already does this. Well, sort of. Currently, *users* may drop flows when they see high levels of loss. On the other hand they may not. Certainly we can't count on it, and we can't count on users watching for any particular loss rate. 1%? 30%? 40%? Depends on the codec and the user. Carrying through the IAB's suggestion would mean endpoint operating systems, or perhaps routers or middleboxes, terminating UDP flows, or treating UDP as less than best effort, when there is congestion. That would seem a deeply nonsatisfying result, and probably far worse for user experience than DCCP. (I'm also not sure DCCP will be that bad -- there are several misunderstandings floating around, as well as some real issues.) Of course, UDP-penalization might not ever happen, but some "people working on the stability of the network" want it to. (I'm thinking of Sally Floyd.) Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 19:51:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26376 for ; Tue, 2 Dec 2003 19:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLEO-0003xO-2A for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 19:51:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30p3rO015164 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 19:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLEN-0003vy-6b; Tue, 02 Dec 2003 19:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLDT-0003vG-2x for avt@optimus.ietf.org; Tue, 02 Dec 2003 19:50:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26360 for ; Tue, 2 Dec 2003 19:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLDR-0006hZ-00 for avt@ietf.org; Tue, 02 Dec 2003 19:50:05 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ARLDQ-0006gl-00 for avt@ietf.org; Tue, 02 Dec 2003 19:50:04 -0500 Subject: RE: [AVT] RE: Trunk unavailable event in 2833bis MIME-Version: 1.0 Date: Tue, 2 Dec 2003 16:48:18 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <6677B3346233B94EBB11C0609351012002615C52@vtg-um-e2k1.sj21ad.cisco.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [AVT] RE: Trunk unavailable event in 2833bis Thread-Index: AcO5L9l4lSKKBgeqQ/eR0JvEdNWWtwAAZypQAAFpa4A= From: "Rajesh Kumar" To: "Rajesh Kumar" , "Tom Taylor" , Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Another point: I need to correct an unintentional typo in both your email and mine. The event is "trunk UN-available" lest I cause unnecessary heartburn about the need to periodically refresh a trunk available event! > -----Original Message----- > From: Rajesh Kumar > Sent: Tuesday, December 02, 2003 4:43 PM > To: Tom Taylor; avt@ietf.org > Subject: [AVT] RE: Trunk unavailable event in 2833bis >=20 > This was at the recommendation of the AVT folks that on/off state > signaling was out of the scope of RFC 2833.The trunk available acts like > a per-DS0 AIS. In North America, you do not need it because you can use > the signaling path to take individual DS0s out of service. In the ETSI > countries, this is done by sending special patterns in the bearer path. > Now you could use RTP to send those patterns but that would be less > efficient since you would need to send the bit pattern continuously > without using VAD. We concluded that an RFC 2833 event message with > periodic, albeit longer, refresh was more efficient. >=20 > Rajesh Kumar >=20 > > -----Original Message----- > > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Tuesday, December 02, 2003 1:03 PM > > To: Rajesh Kumar; avt@ietf.org > > Subject: Trunk unavailable event in 2833bis > > > > What was the reasoning for not defining "trunk unavailable" as a state > > in 2833bis? It would seem natural to do so, and to say that if the > > duration expires without a refresh, the receiver assumes that the > state > > has expired. (That is, you don't have to define and keep sending > "trunk > > available" events.) > > > > Tom Taylor >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 20:09:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27048 for ; Tue, 2 Dec 2003 20:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLVo-0004z7-IF for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 20:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3194gT019133 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 20:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLVl-0004vk-GH; Tue, 02 Dec 2003 20:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLV2-0004se-Jf for avt@optimus.ietf.org; Tue, 02 Dec 2003 20:08:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27015; Tue, 2 Dec 2003 20:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLV0-0006yC-00; Tue, 02 Dec 2003 20:08:14 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARLUz-0006y9-00; Tue, 02 Dec 2003 20:08:13 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB318EsD009456; Tue, 2 Dec 2003 17:08:14 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030108.hB318EsD009456@coyote.icir.org> To: avt@ietf.org cc: dccp@ietf.org Date: Tue, 02 Dec 2003 17:08:14 -0800 From: Eddie Kohler Subject: [AVT] Is TCP broken? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , There was a discussion earlier about whether "it is TCP that is broken", meaning does TCP behave particularly badly when paired with real-time media. TCP is, of course, pretty stupid in many ways, but I didn't quite understand *how* TCP was broken here...? Was it this? (the most likely possibility) * TCP is broken because it probes for available bandwidth during real-time media's quiet periods. Guilty as charged, but it might not matter. If the congested link has a large level of statistical multiplexing, or if the TCP flow is short-lived, it'll all come out in the wash. On the other hand, if the congested link has a small level of statmux, then the congested router or media could just punish TCP a bit to get it back in line. Without a bandwidth reservation, it's hard to know how to do better. Now, if the real-time media flow was using TFRC, it could preserve its bandwidth allocation essentially indefinitely by sending probe traffic at *half* its full-speed rate during silent periods (NOT twice). Other possibilities: * TCP is broken because it probes for available bandwidth, period. I don't think TCP's bandwidth probes will punish TFRC unduly. Simulations have been done showing that TCP and TFRC achieve pretty fair allocations. * TCP is broken because it reacts so violently to loss, which constrains real-time media unduly. Guilty. TCP does halve its rate in response to each congestion event. And yes, that should, up to a point, constrain application designers who want to run over the best-effort Internet. But I'm not yet convinced that real-time media won't work. Many of the constraints don't seem that onerous. (A later mail.) Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 20:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27845 for ; Tue, 2 Dec 2003 20:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLt4-0005uy-Nc for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 20:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB31X6rm022672 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 20:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLsz-0005pz-0B; Tue, 02 Dec 2003 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLsP-0005pY-Kf for avt@optimus.ietf.org; Tue, 02 Dec 2003 20:32:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27791; Tue, 2 Dec 2003 20:32:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLsN-0007Ei-00; Tue, 02 Dec 2003 20:32:23 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARLsM-0007EO-00; Tue, 02 Dec 2003 20:32:22 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB31Vr1m005297; Tue, 2 Dec 2003 20:31:53 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 2 Dec 2003 20:31:40 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 20:31:40 -0500 Message-ID: From: "Phelan, Tom" To: "'Eddie Kohler'" , avt@ietf.org Cc: dccp@ietf.org Date: Tue, 2 Dec 2003 20:31:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Eddie, See inline ... Tom Phelan > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Tuesday, December 02, 2003 7:36 PM > To: avt@ietf.org > Cc: dccp@ietf.org > Subject: [dccp] Would a DCCP flow need to send 2x its preferred rate? > > > (To protect itself from "greedy TCP flows" gobbling up available > bandwidth?) > > No. > > TFRC exists to smooth out responses to congestion. A single > loss (such as > that caused by TCP probing) does not halve the TFRC transmit > rate. In many > cases it will cause only small changes (which, as we've discussed, the > application might be able to ignore). In many cases it will > not change the > rate at all. > > If the congested link has high levels of statistical > multiplexing, the TCP > flows won't likely gobble up the available bandwidth anyway > -- even during > a silent period. Huh? You seem to be saying that if you have a lot of TCP streams on a link they won't use all of the available bandwidth. I thought just the opposite. With a low level of multiplexing there's more chance of synchronizing losses and cutbacks, and not fully utilizing the link. But with a large number of flows enough of them will be blasting away while others are cut back. > If the congested link has low levels of statmux -- like one > DCCP flow and > one TCP flow -- then yes, the TCP would try for the available > bandwidth. > And during a silent period, the TFRC flow would have to > transmit something > so it wasn't crowded out entirely. But this amount would be > *half* the > nominal rate, or perhaps less. Not twice. So this relates to our previous conversation? When you're transmitting at less than the TFRC allowed rate, your allowed rate could be twice what you're transmitting. If a loss event happens, your allowed rate is cut back, but since it was twice what you were actually transmitting, no effect. This gives you the effective "protection" of transmitting at twice your necessary rate, without actually doing it. Great if it works. A simulation would be nice :-). _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 20:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28079 for ; Tue, 2 Dec 2003 20:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLxr-0006Xe-6P for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 20:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB31c2DE025114 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 20:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLxp-0006W8-96; Tue, 02 Dec 2003 20:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLxP-0006OV-Gj for avt@optimus.ietf.org; Tue, 02 Dec 2003 20:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28052 for ; Tue, 2 Dec 2003 20:37:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLxN-0007K9-00 for avt@ietf.org; Tue, 02 Dec 2003 20:37:33 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARLxM-0007K6-00 for avt@ietf.org; Tue, 02 Dec 2003 20:37:32 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB31bWsD009666; Tue, 2 Dec 2003 17:37:32 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030137.hB31bWsD009666@coyote.icir.org> To: "Phelan, Tom" cc: avt@ietf.org, floyd@icir.org In-Reply-To: Message from "Phelan, Tom" of "Tue, 02 Dec 2003 20:31:39 EST." Date: Tue, 02 Dec 2003 17:37:32 -0800 From: Eddie Kohler Subject: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > > If the congested link has high levels of statistical multiplexing, the > > TCP flows won't likely gobble up the available bandwidth anyway -- even > > during a silent period. > > Huh? You seem to be saying that if you have a lot of TCP streams on a link > they won't use all of the available bandwidth. I thought just the opposite. > With a low level of multiplexing there's more chance of synchronizing losses > and cutbacks, and not fully utilizing the link. But with a large number of > flows enough of them will be blasting away while others are cut back. Most links nowadays with high levels of statmux have lots of TCP flows coming and going all the time. Yes, long-lived flows would take up all the available bandwidth, and they might be hard to beat back. But that's not a realistic scenario in most parts of the Internet. > So this relates to our previous conversation? When you're transmitting at > less than the TFRC allowed rate, your allowed rate could be twice what > you're transmitting. If a loss event happens, your allowed rate is cut > back, but since it was twice what you were actually transmitting, no effect. > This gives you the effective "protection" of transmitting at twice your > necessary rate, without actually doing it. Yep. Also note that your allowed rate wouldn't be cut back by half right away -- that's the power of TFRC. It would drop slowly if at all. > A simulation would be nice :-). Yep. :) Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 21:19:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27846 for ; Tue, 2 Dec 2003 20:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLt4-0005uI-LG for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 20:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB31X6Ve022670 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 20:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLt0-0005s4-Qf; Tue, 02 Dec 2003 20:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARLsf-0005ph-ER for avt@optimus.ietf.org; Tue, 02 Dec 2003 20:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27794; Tue, 2 Dec 2003 20:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARLsd-0007Eo-00; Tue, 02 Dec 2003 20:32:39 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARLsc-0007El-00; Tue, 02 Dec 2003 20:32:38 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB31WcsD009613; Tue, 2 Dec 2003 17:32:38 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030132.hB31WcsD009613@coyote.icir.org> To: avt@ietf.org cc: dccp@ietf.org Date: Tue, 02 Dec 2003 17:32:38 -0800 From: Eddie Kohler Subject: [AVT] Would DCCP kill Internet real-time media distribution? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , By "real-time media", I mean "current more-or-less-CBR real-time media". To summarize the problems that a best-effort media stream might suffer: (Please correct me if I'm wrong or have left anything out!) Axiom 1: Loss sucks. ("a 3% loss rate means a 30% reduction in quality") Axiom 2: Rate changes suck. ("Have you ever actually listened ... stream with varying rate? ... It sucks, to put it mildly.") So, following this through: * Say there's no loss. If there's no loss, DCCP and UDP are equivalent, except that DCCP enforces slow-start. Slow-start will not matter for low-rate flows like most VoIP flows. It will for higher-rate flows like the 4 Mb/s video flow Brian Rosen has mentioned. A TFRC/DCCP flow could probably slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the absence of loss. You might also have to slow-start after a quiet period, but this could be addressed by the application by sending some probe traffic. NOT 2x the nominal rate; 1/2 the nominal rate, or perhaps some more clever scheme. If the DCCP authors need to solve the quiet-period problem, then we will try to solve it. But the current choice -- either send 1/2 the nominal rate during the quiet period, or slow-start after the quiet period -- doesn't seem like a killer for all real-time media distribution. * Say there's loss. Well, performance already sucks by Axiom 1 :) UDP would have suffered the same loss. The problem is whether or not DCCP reduces its rate, violating Axiom 2. TFRC by design reduces its rate far more slowly than TCP would. A single loss will not greatly affect the rate. TFRC seems well-protected against probing TCP flows and/or a low background loss rate. We will allow applications to send at slightly above the TFRC rate as well. So probably the situation is not that bad. Despite this, though, TFRC may reduce the allowed sending rate to below the application's nominal rate. The application can react to this however it would like. For instance, it could stop sending, which I think is the only other best-effort alternative on the table. But if the application *wanted* to, it could try to do better. So, I think No, DCCP would not kill Internet real-time media distribution. If these arguments aren't sound, we'd really like to hear it. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 21:34:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29317 for ; Tue, 2 Dec 2003 21:34:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMpn-0000AQ-BQ for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 21:33:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB32Xl0a000636 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 21:33:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMp3-0008Nk-0B; Tue, 02 Dec 2003 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMoh-0008NM-6G for avt@optimus.ietf.org; Tue, 02 Dec 2003 21:32:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29271; Tue, 2 Dec 2003 21:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARMoe-00001O-00; Tue, 02 Dec 2003 21:32:36 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARMod-00001K-00; Tue, 02 Dec 2003 21:32:35 -0500 Received: from [68.100.124.243] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 2064542; Tue, 02 Dec 2003 21:32:00 -0500 From: "Marshall Eubanks" Subject: Re: [AVT] Would DCCP kill Internet real-time media distribution? To: Eddie Kohler , avt@ietf.org Cc: dccp@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Tue, 02 Dec 2003 21:32:00 -0500 Message-ID: In-Reply-To: <200312030132.hB31WcsD009613@coyote.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Tue, 02 Dec 2003 17:32:38 -0800 Eddie Kohler wrote: > By "real-time media", I mean "current more-or-less-CBR real-time media". > > To summarize the problems that a best-effort media stream might suffer: > (Please correct me if I'm wrong or have left anything out!) > > Axiom 1: Loss sucks. ("a 3% loss rate means a 30% reduction in quality") > Axiom 2: Rate changes suck. ("Have you ever actually listened ... stream > with varying rate? ... It sucks, to put it mildly.") > > So, following this through: > > * Say there's no loss. > > If there's no loss, DCCP and UDP are equivalent, except that DCCP > enforces slow-start. Slow-start will not matter for low-rate flows like > most VoIP flows. It will for higher-rate flows like the 4 Mb/s video > flow Brian Rosen has mentioned. A TFRC/DCCP flow could probably > slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the absence of > loss. > > You might also have to slow-start after a quiet period, but this could be > addressed by the application by sending some probe traffic. NOT 2x the > nominal rate; 1/2 the nominal rate, or perhaps some more clever scheme. > > If the DCCP authors need to solve the quiet-period problem, then we will > try to solve it. But the current choice -- either send 1/2 the nominal > rate during the quiet period, or slow-start after the quiet period -- > doesn't seem like a killer for all real-time media distribution. > > * Say there's loss. > > Well, performance already sucks by Axiom 1 :) UDP would have suffered the > same loss. The problem is whether or not DCCP reduces its rate, > violating Axiom 2. > > TFRC by design reduces its rate far more slowly than TCP would. A single > loss will not greatly affect the rate. TFRC seems well-protected against > probing TCP flows and/or a low background loss rate. We will allow > applications to send at slightly above the TFRC rate as well. So > probably the situation is not that bad. > > Despite this, though, TFRC may reduce the allowed sending rate to below > the application's nominal rate. The application can react to this > however it would like. For instance, it could stop sending, which I > think is the only other best-effort alternative on the table. But if the > application *wanted* to, it could try to do better. > > So, I think No, DCCP would not kill Internet real-time media distribution. > > If these arguments aren't sound, we'd really like to hear it. > On the Internet2, I would estimate that a substantial fraction of the loss that I see in multicast UDP streaming is not due to congestion, in many cases > 50%. How would DCCP respond to such false congestion signals ? Is there a CETEN like mechanism to deal with this ? Regards Marshall Eubanks > Eddie > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 21:38:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29458 for ; Tue, 2 Dec 2003 21:38:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMtv-0000WK-LU for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 21:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB32c3wV001903 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 21:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMtu-0000Td-9i; Tue, 02 Dec 2003 21:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARMtJ-0000Hk-W4 for avt@optimus.ietf.org; Tue, 02 Dec 2003 21:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29424; Tue, 2 Dec 2003 21:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARMtG-00005s-00; Tue, 02 Dec 2003 21:37:22 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARMtG-00005m-00; Tue, 02 Dec 2003 21:37:22 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB32bMsD010123; Tue, 2 Dec 2003 18:37:22 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030237.hB32bMsD010123@coyote.icir.org> To: "Marshall Eubanks" cc: avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] Would DCCP kill Internet real-time media distribution? In-Reply-To: Message from "Marshall Eubanks" of "Tue, 02 Dec 2003 21:32:00 EST." Date: Tue, 02 Dec 2003 18:37:22 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > On the Internet2, I would estimate that a substantial fraction of the > loss that I see in multicast UDP streaming is not due to congestion, in > many cases > 50%. How would DCCP respond to such false congestion signals > ? Is there a CETEN like mechanism to deal with this ? NB: DCCP is unicast. But DCCP does in fact have a mechanism, called Data Dropped, for differentiating congestion losses from non-congestion losses (such as receive-buffer or corruption losses). Non-congestion losses aren't treated as congestion, as long as we _know_ they weren't due to congestion. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 22:04:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00037 for ; Tue, 2 Dec 2003 22:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNJ5-0001gB-Mi for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 22:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3343eo006420 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 22:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNJ3-0001di-41; Tue, 02 Dec 2003 22:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNIW-0001dC-Jf for avt@optimus.ietf.org; Tue, 02 Dec 2003 22:03:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00011; Tue, 2 Dec 2003 22:03:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNIT-0000MZ-00; Tue, 02 Dec 2003 22:03:25 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1ARNIS-0000MW-00; Tue, 02 Dec 2003 22:03:24 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id hB333F6A021590; Tue, 2 Dec 2003 20:03:15 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hB331wGS014844; Tue, 2 Dec 2003 21:01:59 -0600 Message-ID: <3FCD527D.E43C0825@motorola.com> Date: Tue, 02 Dec 2003 21:03:25 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eddie Kohler CC: avt@ietf.org, dccp@ietf.org References: <200312030035.hB30ZWsD009262@coyote.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > .... > And during a silent period, the TFRC flow would have to transmit something > so it wasn't crowded out entirely. But this amount would be *half* the > nominal rate, or perhaps less. Not twice. This may be an encouragement to the codec folks in the future to stop doing silence detection since it would be better to always have something to send. But, if people suddenly realize that turning off their encoder silence detection immediately gives them better voice quality and start to do so in a large scale, what good it would do to the network? Would IAB have the power to tell people not to do so? regards, -Qiaobing > > > Eddie > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 22:12:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00263 for ; Tue, 2 Dec 2003 22:12:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNQp-0002IL-0c for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 22:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33C22u008772 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 22:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNQn-0002G1-GS; Tue, 02 Dec 2003 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARNQ1-0002FI-Qf for avt@optimus.ietf.org; Tue, 02 Dec 2003 22:11:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00215; Tue, 2 Dec 2003 22:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARNPy-0000S3-00; Tue, 02 Dec 2003 22:11:10 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARNPx-0000S0-00; Tue, 02 Dec 2003 22:11:10 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB33BAsD010423; Tue, 2 Dec 2003 19:11:10 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312030311.hB33BAsD010423@coyote.icir.org> To: Qiaobing Xie cc: avt@ietf.org, dccp@ietf.org In-Reply-To: Message from Qiaobing Xie of "Tue, 02 Dec 2003 21:03:25 CST." <3FCD527D.E43C0825@motorola.com> Date: Tue, 02 Dec 2003 19:11:10 -0800 From: Eddie Kohler Subject: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > But, if people suddenly realize that turning off their encoder silence > detection immediately gives them better voice quality and start to do so in a > large scale, what good it would do to the network? Would IAB have the power to > tell people not to do so? TCP-friendliness without silence suppression is probably better for the best-effort Internet than non-TCP-friendliness with silence suppression. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 2 22:54:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01769 for ; Tue, 2 Dec 2003 22:54:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARO5e-0004XW-KN for avt-archive@odin.ietf.org; Tue, 02 Dec 2003 22:54:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB33sESn017402 for avt-archive@odin.ietf.org; Tue, 2 Dec 2003 22:54:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARO5R-0004W2-IT; Tue, 02 Dec 2003 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARO51-0004Vr-Io for avt@optimus.ietf.org; Tue, 02 Dec 2003 22:53:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01766 for ; Tue, 2 Dec 2003 22:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARO4x-00014f-00 for avt@ietf.org; Tue, 02 Dec 2003 22:53:31 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1ARO4x-00014b-00 for avt@ietf.org; Tue, 02 Dec 2003 22:53:31 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hB33rVTA009989 for ; Tue, 2 Dec 2003 19:53:31 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hB33rVJi009988 for avt@ietf.org; Tue, 2 Dec 2003 19:53:31 -0800 (PST) Date: Tue, 2 Dec 2003 19:53:31 -0800 (PST) From: John Lazzaro Message-Id: <200312030353.hB33rVJi009988@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: Is dropping flows enough to avoid congestion collapse? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Eddie Kohler writes: > > Of course, UDP-penalization might not ever happen, but some "people > working on the stability of the network" want it to. I found the November 2003 Communications ACM article on TransLight to be very illuminating on this point (no pun intended). So much comes for free if everyone gets (at least) two lamdbas to their endpoint, one regulated QoS lamdba for media flows, and one legacy lambda for TCP and other best-effort uses. If you peek under Layer 2 to Layer 1, such separation is often there physically -- the wire-pairs of modern Ethernet, the channels of cable TV plant, the lambdas of PONS. Of course, the TransLight folks have it even better -- unrouted, point-to-point, knowable latency lambdas ... --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 03:55:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06525 for ; Wed, 3 Dec 2003 03:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSmx-00018p-Qj for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 03:55:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38tFbg004368 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 03:55:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSmp-00016w-6a; Wed, 03 Dec 2003 03:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARRiw-0006YQ-11 for avt@optimus.ietf.org; Wed, 03 Dec 2003 02:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04394; Wed, 3 Dec 2003 02:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARRir-0003id-00; Wed, 03 Dec 2003 02:46:57 -0500 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[koVZNeyjoi1s0UXg0EFh6LvTrQlqOlBv]) by ietf-mx with esmtp (Exim 4.12) id 1ARRiq-0003ia-00; Wed, 03 Dec 2003 02:46:57 -0500 Received: from nidd.cl.cam.ac.uk ([128.232.8.175] helo=cl.cam.ac.uk ident=[BHfOIDd9iCUb6FS22rj8NI48xEyD0ovx]) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1ARRio-0008HU-00; Wed, 03 Dec 2003 07:46:54 +0000 To: "Marshall Eubanks" cc: Eddie Kohler , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media distribution? In-Reply-To: Message from "Marshall Eubanks" of "Tue, 02 Dec 2003 21:32:00 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5651.1070437613.1@cl.cam.ac.uk> Date: Wed, 03 Dec 2003 07:46:53 +0000 From: Jon Crowcroft Message-Id: Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , In missive , "Marshall Eubanks" typed: >>On the Internet2, I would estimate that a substantial fraction of the loss that I >>see in multicast UDP streaming is not due to congestion, in many cases > 50%. How >>would DCCP respond to such false congestion signals ? Is there a CETEN like mechanism >>to deal with this ? 1/ do you mean half the time that you see loss, or that you see 50% loss? i'venever seen any loss level like that except on a severaly broken network, where no amount of dumb CBR streamed UDP or clever adaptive dccp will be any use nor will TCP btw 2/ deploy ECN. that will let you cope with non congestive loss through other means - hey, >10% loss is the Internet's way of just telling you "NO" [its called CALL BLOCKING in phone nets, but people just dont seem to get that:-) btw the comment on adaptive rate sucks - its correct - the usertrials folks at UCL did certainly show that there is little point increasing the quality of video/audio if you are going to have to decrease it , within a session, as the user experiecne contains a lot of hysteresis - i.e. they habituate, but the user reports the worst rate they see, and variation (up from that and down to it) degrade the overall experience more (even though the average rate may be better).... i think this points the way (sorry to say it) to a model where we do admission control for streaming based on large aggregate measurements and ECN, and not to rate adaption but i know this is heretical technically, one can estimate a rate over the multiple RTT time scale via TFRC but the question is what do do about large scale fluctuation in the load at a bottlenect ...and it seems to me that we dont have a story here yet, even though we've been muckng about with this stuff for about 15 years... cheers j _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 03:55:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06541 for ; Wed, 3 Dec 2003 03:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSmx-00018q-R2 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 03:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38tFQ5004371 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 03:55:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSmm-00016W-Q3; Wed, 03 Dec 2003 03:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARJVO-0007E6-Va for avt@optimus.ietf.org; Tue, 02 Dec 2003 18:00:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20343 for ; Tue, 2 Dec 2003 18:00:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARJVM-0004jG-00 for avt@ietf.org; Tue, 02 Dec 2003 18:00:28 -0500 Received: from [81.171.101.3] (helo=smtp.eweka.nl) by ietf-mx with esmtp (Exim 4.12) id 1ARJVK-0004iw-00 for avt@ietf.org; Tue, 02 Dec 2003 18:00:26 -0500 Received: from solstice (ew-dsl-81-171-0-31.eweka.nl [81.171.0.31]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id hB2NDxtR008123; Tue, 2 Dec 2003 23:14:10 GMT (envelope-from a.vwijk@viataal.nl) From: "Arnoud van Wijk" To: "'Gunnar Hellstrom'" , , , , Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833 Date: Tue, 2 Dec 2003 23:59:49 +0100 Message-ID: <000d01c3b928$01db8560$0300a8c0@solstice> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Gunnar, Yes. I agree. I will give RFC 2833 a read to see what has been changed. And we should make it clear that RFC 2833 will not mention text = telephony except: " For text telephony, please read RFC 2793 and the Text over IP draft (RFC # something in the future)". Or something like that. Greetz Arnoud Drs. Arnoud A. T. van Wijk=20 Viataal=20 Research & Development=20 Afdeling RDS=20 Theerestraat 42=20 5271 GD Sint-Michielsgestel=20 The Netherlands.=20 Mobile: +31651921948=20 International text telephone: +31735588408=20 -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: dinsdag 2 december 2003 20:48 To: A vWijk; avt@ietf.org; paulej@packetizer.com; toip@snowshore.com; gv@trace.wisc.edu Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833 Arnoud and all, I do not think it is desirable to try to patch up RFC2833 to transport = all kinds of textphone data events. In my view it is likely to be complex, unreliable and against the efforts to create mainstream conversational services for all with high functionality in the IP network. But I wanted to expose this question from Tom to the text conversation interested people to get your view, and give som good advice back to = Tom, who is just now cleaning up RFC2833. You are rtight that RFC2833 started as a mechanism for DTMF transport = and that is what it is most famous for. But have a look in it, and you will = find that many other signals that are likely to appear in PSTN connections = can be coded with RFC2833. If we had any wish to recreate the same tones at exit as was input, = there could be a case for patching up RFC2833 to (detect and) transport all textphone data properly. Now, the case is the opposite, we want to disconnect the technologies in = the both ends as much as possible, and have a pure text code in between. Therefore, complete V.18 in the PSTN edge and RFC2793 transport is the solution I see have a future. Agree? Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: A vWijk [mailto:A.vWijk@viataal.nl] Sent: Tuesday, December 02, 2003 1:45 PM To: avt@ietf.org; gunnar.hellstrom@omnitor.se; paulej@packetizer.com; toip@snowshore.com; gv@trace.wisc.edu Subject: Betr.: FW: [AVT] Missing events in RFC 2833 Gunnar, why is this desirable? We will have T.140 over RTP and in some cases over TCP/IP. Why the tones? Or am I mixing things up again? RFC2833 is for DTMF signalling? greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> "Gunnar Hellstrom" 01-12-03 23:20 >>> Below, Tom Taylor asks if there is any interest to complete the = textphone related tone events in RFC2833 so that all V.18 submodes can be = transported with RFC2833. We have to verify that we have satisfying detection and transport = methods in RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we = can leave RFC2833 half done for text transport. I would like to do so, but then the market forces must be strong enough = to make RFC2793 and textphone detection commonplace. Using RFC2833 will place a task similar to V.18 logic on the IP = endpoint, but with less exact information than the native V.18 has. We have no analysis if that task is realistic, nor if it is likely to be = implemented by IP endpoint developers. ( The missing events for complete text transport are probably: V.21 data in lo channel at 110 bits/s Bell 103 hi channel data at 300 bits/s Bell 103 lo channel data at 300 bits/s V.23 data at 1200 bits/s V.23 data at 75 bits/s Baudot data at 45.45 bits/s Baudot data at 50 bits/s (assuming that V.8 signals and V.21 at 300 bits/s in both directions and DTMF are covered ) Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Monday, December 01, 2003 5:37 PM To: avt@ietf.org Subject: [AVT] Missing events in RFC 2833 I'm finding it a little difficult to see how some of the applications supported by RFC 2833 work without a few more events. Here are some examples: 1. V.18 text telephones interwork with a number of other text telephone types. The only event defined specifically for V.18 operation seems rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. There don't seem to be any events for Baudot or V.23 or for Bell 103 in calling mode. 2. Signalling System No. 5 has two sets of signals: line signals, which are tones controlling trunk state, and register signals, which convey digits with some supporting information. There is a timing constraint that register signalling must begin within 80 +/- 20 ms of the end of the "seize" line signal. Yet no event is defined for "seize", only for the register signals. It's a little hard to see how the receiving gateway can propagate KPx (the initial register signal) on time if it doesn't know that "seize" was playing, even if the sending end can recognize and report the start of KPx within the 20 ms tolerance. As I see it, the present set of events is useful only to transfer the register events from one gateway to another which will report them to call control rather than propagating them as tones. These missing events raise the issue of whether proposals to add events to RFC 2833 should be backed up by requirements documents describing their use. I have been adding brief application descriptions in my rewrite of 2833bis, as justification for the normative text which I have also been adding. (Basically just obvious stuff, missing the first time around and highlighted by Flemming's comments earlier this year.) I am hoping that this additional information prompts a critical review of the current set of 2833/2833bis events, with a view to rounding them out as necessary to make applications work well. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt - This list is maintained by Snowshore Networks - http://www.snowshore.com All comments on this list are the comments of the message originators = and Snowshore is not to be held responsible for any actions or comments = found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 04:44:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06540 for ; Wed, 3 Dec 2003 03:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSmx-00018o-QQ for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 03:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB38tFwT004372 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 03:55:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARSml-00016G-7P; Wed, 03 Dec 2003 03:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9vD-0005iq-Vu for avt@optimus.ietf.org; Tue, 02 Dec 2003 07:46:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14745 for ; Tue, 2 Dec 2003 07:46:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR9vC-0006d6-00 for avt@ietf.org; Tue, 02 Dec 2003 07:46:30 -0500 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 1AR9vB-0006cw-00 for avt@ietf.org; Tue, 02 Dec 2003 07:46:30 -0500 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA05094 for ; Tue, 2 Dec 2003 13:49:22 +0100 (CET) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma004752; Tue, 2 Dec 03 13:48:19 +0100 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Tue, 02 Dec 2003 13:45:28 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Tue, 02 Dec 2003 13:45:09 +0100 From: "A vWijk" To: , , , , Subject: Betr.: FW: [AVT] Missing events in RFC 2833 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Gunnar, why is this desirable? We will have T.140 over RTP and in some cases over TCP/IP. Why the tones? Or am I mixing things up again? RFC2833 is for DTMF signalling? greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 >>> "Gunnar Hellstrom" 01-12-03 23:20 >>> Below, Tom Taylor asks if there is any interest to complete the textphone related tone events in RFC2833 so that all V.18 submodes can be transported= with RFC2833. We have to verify that we have satisfying detection and transport methods = in RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can leave RFC2833 half done for text transport. I would like to do so, but then the market forces must be strong enough to make RFC2793 and textphone detection commonplace. Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, but with less exact information than the native V.18 has. We have no analysis if that task is realistic, nor if it is likely to be implemented = by IP endpoint developers. ( The missing events for complete text transport are probably: V.21 data in lo channel at 110 bits/s Bell 103 hi channel data at 300 bits/s Bell 103 lo channel data at 300 bits/s V.23 data at 1200 bits/s V.23 data at 75 bits/s Baudot data at 45.45 bits/s Baudot data at 50 bits/s (assuming that V.8 signals and V.21 at 300 bits/s in both directions and DTMF are covered ) Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se=20 Gunnar.Hellstrom@Omnitor.se=20 -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom Taylor Sent: Monday, December 01, 2003 5:37 PM To: avt@ietf.org=20 Subject: [AVT] Missing events in RFC 2833 I'm finding it a little difficult to see how some of the applications supported by RFC 2833 work without a few more events. Here are some examples: 1. V.18 text telephones interwork with a number of other text telephone types. The only event defined specifically for V.18 operation seems rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. There don't seem to be any events for Baudot or V.23 or for Bell 103 in calling mode. 2. Signalling System No. 5 has two sets of signals: line signals, which are tones controlling trunk state, and register signals, which convey digits with some supporting information. There is a timing constraint that register signalling must begin within 80 +/- 20 ms of the end of the "seize" line signal. Yet no event is defined for "seize", only for the register signals. It's a little hard to see how the receiving gateway can propagate KPx (the initial register signal) on time if it doesn't know that "seize" was playing, even if the sending end can recognize and report the start of KPx within the 20 ms tolerance. As I see it, the present set of events is useful only to transfer the register events from one gateway to another which will report them to call control rather than propagating them as tones. These missing events raise the issue of whether proposals to add events to RFC 2833 should be backed up by requirements documents describing their use. I have been adding brief application descriptions in my rewrite of 2833bis, as justification for the normative text which I have also been adding. (Basically just obvious stuff, missing the first time around and highlighted by Flemming's comments earlier this year.) I am hoping that this additional information prompts a critical review of the current set of 2833/2833bis events, with a view to rounding them out as necessary to make applications work well. Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org=20 https://www1.ietf.org/mailman/listinfo/avt=20 - This list is maintained by Snowshore Networks - http://www.snowshore.com=20= All comments on this list are the comments of the message originators and Snowshore is not to be held responsible for any actions or comments found on this list. The archives for this list can be found at http://flyingfox.snowshore.com/toip_archive/maillist.html _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 08:31:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14312 for ; Wed, 3 Dec 2003 08:31:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX60-0004xS-18 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 08:31:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3DVBdk019010 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 08:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX5q-0004un-TO; Wed, 03 Dec 2003 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARX5k-0004uA-4w for avt@optimus.ietf.org; Wed, 03 Dec 2003 08:30:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14284; Wed, 3 Dec 2003 08:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARX5i-0000mx-00; Wed, 03 Dec 2003 08:30:54 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARX5i-0000l4-00; Wed, 03 Dec 2003 08:30:54 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB3DU81m005365; Wed, 3 Dec 2003 08:30:08 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 3 Dec 2003 08:29:59 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 08:29:59 -0500 Message-ID: From: "Phelan, Tom" To: "'Marshall Eubanks'" , Eddie Kohler , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [AVT] Would DCCP kill Internet real-time media distribution? Date: Wed, 3 Dec 2003 08:29:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Marshall, > On the Internet2, I would estimate that a substantial fraction of the loss > that I see in multicast UDP streaming is not due to congestion, in > many cases > 50%. How would DCCP respond to such false congestion signals ? > Is there a CETEN like mechanism to deal with this ? What are the causes of these non-congestion losses? Tom Phelan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 08:53:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15000 for ; Wed, 3 Dec 2003 08:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXR9-0005ri-NA for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 08:53:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Dr3St022545 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 08:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXR7-0005r5-FV; Wed, 03 Dec 2003 08:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXQn-0005qm-U8 for avt@optimus.ietf.org; Wed, 03 Dec 2003 08:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14982 for ; Wed, 3 Dec 2003 08:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXQm-0001HR-00 for avt@ietf.org; Wed, 03 Dec 2003 08:52:40 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ARXQh-0001G6-00 for avt@ietf.org; Wed, 03 Dec 2003 08:52:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB3Dplo04749; Wed, 3 Dec 2003 08:51:48 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLST1S49; Wed, 3 Dec 2003 08:51:48 -0500 Received: from nortelnetworks.com (acart1c0.ca.nortel.com [47.129.129.43]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM89S; Wed, 3 Dec 2003 08:51:47 -0500 Message-ID: <3FCDEA6D.9050701@nortelnetworks.com> Date: Wed, 03 Dec 2003 08:51:41 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnoud van Wijk CC: "'Gunnar Hellstrom'" , avt@ietf.org, paulej@packetizer.com, toip@snowshore.com, gv@trace.wisc.edu Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 References: <000d01c3b928$01db8560$0300a8c0@solstice> In-Reply-To: <000d01c3b928$01db8560$0300a8c0@solstice> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Does this mean you also deprecate any use of V.150.1 for carrying text telephony? Arnoud van Wijk wrote: > Hello Gunnar, > Yes. I agree. > > I will give RFC 2833 a read to see what has been changed. > And we should make it clear that RFC 2833 will not mention text telephony > except: " For text telephony, please read RFC 2793 and the Text over IP > draft (RFC # something in the future)". Or something like that. > > Greetz > > Arnoud > > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: dinsdag 2 december 2003 20:48 > To: A vWijk; avt@ietf.org; paulej@packetizer.com; toip@snowshore.com; > gv@trace.wisc.edu > Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833 > > Arnoud and all, > > I do not think it is desirable to try to patch up RFC2833 to transport all > kinds of textphone data events. In my view it is likely to be complex, > unreliable and against the efforts to create mainstream conversational > services for all with high functionality in the IP network. > > But I wanted to expose this question from Tom to the text conversation > interested people to get your view, and give som good advice back to Tom, > who is just now cleaning up RFC2833. > > You are rtight that RFC2833 started as a mechanism for DTMF transport and > that is what it is most famous for. But have a look in it, and you will find > that many other signals that are likely to appear in PSTN connections can be > coded with RFC2833. > > If we had any wish to recreate the same tones at exit as was input, there > could be a case for patching up RFC2833 to (detect and) transport all > textphone data properly. > > Now, the case is the opposite, we want to disconnect the technologies in the > both ends as much as possible, and have a pure text code in between. > Therefore, complete V.18 in the PSTN edge and RFC2793 transport is the > solution I see have a future. > > Agree? > > Gunnar > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: A vWijk [mailto:A.vWijk@viataal.nl] > Sent: Tuesday, December 02, 2003 1:45 PM > To: avt@ietf.org; gunnar.hellstrom@omnitor.se; paulej@packetizer.com; > toip@snowshore.com; gv@trace.wisc.edu > Subject: Betr.: FW: [AVT] Missing events in RFC 2833 > > > Gunnar, > why is this desirable? > > We will have T.140 over RTP and in some cases over TCP/IP. > Why the tones? > > Or am I mixing things up again? RFC2833 is for DTMF signalling? > > greetz > > Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 > > >>>>"Gunnar Hellstrom" 01-12-03 23:20 >>> > > Below, Tom Taylor asks if there is any interest to complete the textphone > related tone events in RFC2833 so that all V.18 submodes can be transported > with RFC2833. > > We have to verify that we have satisfying detection and transport methods in > RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can > leave RFC2833 half done for text transport. > > I would like to do so, but then the market forces must be strong enough to > make RFC2793 and textphone detection commonplace. > > Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, > but with less exact information than the native V.18 has. We have no > analysis if that task is realistic, nor if it is likely to be implemented by > IP endpoint developers. > > ( The missing events for complete text transport are probably: > V.21 data in lo channel at 110 bits/s > Bell 103 hi channel data at 300 bits/s > Bell 103 lo channel data at 300 bits/s > V.23 data at 1200 bits/s > V.23 data at 75 bits/s > Baudot data at 45.45 bits/s > Baudot data at 50 bits/s > > (assuming that V.8 signals and V.21 at 300 bits/s in both directions and > DTMF are covered ) > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom > Omnitor AB > Renathvagen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom > Taylor > Sent: Monday, December 01, 2003 5:37 PM > To: avt@ietf.org > Subject: [AVT] Missing events in RFC 2833 > > > I'm finding it a little difficult to see how some of the applications > supported by RFC 2833 work without a few more events. Here are some > examples: > > 1. V.18 text telephones interwork with a number of other text telephone > types. The only event defined specifically for V.18 operation seems > rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. > There don't seem to be any events for Baudot or V.23 or for Bell 103 in > calling mode. > > 2. Signalling System No. 5 has two sets of signals: line signals, which > are tones controlling trunk state, and register signals, which convey > digits with some supporting information. There is a timing constraint > that register signalling must begin within 80 +/- 20 ms of the end of > the "seize" line signal. Yet no event is defined for "seize", only for > the register signals. It's a little hard to see how the receiving > gateway can propagate KPx (the initial register signal) on time if it > doesn't know that "seize" was playing, even if the sending end can > recognize and report the start of KPx within the 20 ms tolerance. As I > see it, the present set of events is useful only to transfer the > register events from one gateway to another which will report them to > call control rather than propagating them as tones. > > These missing events raise the issue of whether proposals to add events > to RFC 2833 should be backed up by requirements documents describing > their use. I have been adding brief application descriptions in my > rewrite of 2833bis, as justification for the normative text which I have > also been adding. (Basically just obvious stuff, missing the first time > around and highlighted by Flemming's comments earlier this year.) I am > hoping that this additional information prompts a critical review of the > current set of 2833/2833bis events, with a view to rounding them out as > necessary to make applications work well. > > Tom Taylor > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > > > - > This list is maintained by Snowshore Networks - http://www.snowshore.com > All comments on this list are the comments of the message originators and > Snowshore is not to be held responsible for any actions or comments found > on this list. The archives for this list can be found at > http://flyingfox.snowshore.com/toip_archive/maillist.html > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 09:12:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15730 for ; Wed, 3 Dec 2003 09:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXjZ-0006bJ-Q7 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 09:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3EC5R8025367 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 09:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXjU-0006Zb-NV; Wed, 03 Dec 2003 09:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXj6-0006Z6-Tr for avt@optimus.ietf.org; Wed, 03 Dec 2003 09:11:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15619; Wed, 3 Dec 2003 09:11:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXj4-0001ah-00; Wed, 03 Dec 2003 09:11:34 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARXj3-0001aG-00; Wed, 03 Dec 2003 09:11:34 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08859; Wed, 3 Dec 2003 09:10:21 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18156; Wed, 3 Dec 2003 09:10:19 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 09:10:18 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6162@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [AVT] Is TCP broken? Date: Wed, 3 Dec 2003 09:10:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Eddie > * TCP is broken because it probes for available bandwidth > during real-time > media's quiet periods. > > Guilty as charged, but it might not matter. If the > congested link has a > large level of statistical multiplexing, or if the TCP flow is > short-lived, it'll all come out in the wash. On the other > hand, if the > congested link has a small level of statmux, then the > congested router or > media could just punish TCP a bit to get it back in line. I don't think there exists mechanisms to do this, because you need immediate response when the stream starts, and nothing in TCP does immediate - it's designed to react slowly. > > Without a bandwidth reservation, it's hard to know how to do better. I don't believe this. I think it's possible to do some relatively simple things to TCP that would help media streams quite a bit. > > Now, if the real-time media flow was using TFRC, it could > preserve its > bandwidth allocation essentially indefinitely by sending > probe traffic at > *half* its full-speed rate during silent periods (NOT twice). This is not tenable. No application would do this; they would simply turn off the Voice Activity Detection. It's also wrong. It illustrates that indeed TCP is broken. TCP needs a mechanism to determine it's "fair" share and use extra bandwidth opportunistically, returning to "fair" immediately when asked. > > Other possibilities: > > * TCP is broken because it probes for available bandwidth, period. > > I don't think TCP's bandwidth probes will punish TFRC unduly. > Simulations have been done showing that TCP and TFRC > achieve pretty fair > allocations. TRFC, as I understand it, does not work for media flows, which are on/off constant rate. It is not interesting to look at steady state; you have to include startup/shutdown. All the simulations I've seen either show that TRFC won't start cleanly for CBR-like flows, or don't show how start/stop works at all. The problem here is "rate control"; media streams don't rate control, except as we have discussed, rather crudely, and only downward. > > * TCP is broken because it reacts so violently to loss, which > constrains > real-time media unduly. > > Guilty. TCP does halve its rate in response to each > congestion event. > And yes, that should, up to a point, constrain application > designers who > want to run over the best-effort Internet. But I'm not yet > convinced > that real-time media won't work. Many of the constraints > don't seem that > onerous. (A later mail.) Well, I'd say this was an example where TCP is broken in that it does not use available bandwidth appropriately, but in this case, it is TCP that loses. I don't want to promote solutions that break TCP, or, as in this case, not use available bandwidth efficiently. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 09:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16543 for ; Wed, 3 Dec 2003 09:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY4t-0007g4-K2 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 09:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3EY774029482 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 09:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY4n-0007cp-RI; Wed, 03 Dec 2003 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY3r-0007aa-Om for avt@optimus.ietf.org; Wed, 03 Dec 2003 09:33:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16399; Wed, 3 Dec 2003 09:32:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARY3p-000249-00; Wed, 03 Dec 2003 09:33:02 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARY3p-000245-00; Wed, 03 Dec 2003 09:33:01 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09827; Wed, 3 Dec 2003 09:31:51 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21296; Wed, 3 Dec 2003 09:28:53 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 09:28:52 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6163@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [AVT] Would DCCP kill Internet real-time media distribution? Date: Wed, 3 Dec 2003 09:28:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > * Say there's no loss. > > If there's no loss, DCCP and UDP are equivalent, except that DCCP > enforces slow-start. Slow-start will not matter for > low-rate flows like > most VoIP flows. It will for higher-rate flows like the 4 > Mb/s video > flow Brian Rosen has mentioned. A TFRC/DCCP flow could probably > slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the > absence of > loss. A typical RTT on the internet these days is 50-100 ms. If you experience 30% loss in the first 3 RTTs of voice, you will clip the "hello" pretty badly. If it's 7-8 RTTs, you will definitely have a very poor experience. I think you can pretty safely say that slow start is a very big no-no for interactive media. For non-interactive media, it only annoys you a little bit, and while not desirable, isn't fatal. Are you really proposing that we create a new protocol that only works for small bit rate media? I think that's a really poor idea. Better to work harder and fix the problem for all, or nearly all media streams now, and in the foreseeable future. The foreseeable future will have multimegabit media streams. > > You might also have to slow-start after a quiet period, but > this could be > addressed by the application by sending some probe traffic. > NOT 2x the > nominal rate; 1/2 the nominal rate, or perhaps some more > clever scheme. Slow start is not acceptable, as above. A more clever scheme might work. 1/2 nominal is not realistic, as has been pointed out. I suspect that "more clever" means fixing TCP. > > If the DCCP authors need to solve the quiet-period problem, > then we will > try to solve it. But the current choice -- either send 1/2 > the nominal > rate during the quiet period, or slow-start after the quiet > period -- > doesn't seem like a killer for all real-time media distribution. Maybe not, but probably enough that it isn't interesting to deploy. > > * Say there's loss. > > Well, performance already sucks by Axiom 1 :) UDP would > have suffered the > same loss. The problem is whether or not DCCP reduces its rate, > violating Axiom 2. > > TFRC by design reduces its rate far more slowly than TCP > would. A single > loss will not greatly affect the rate. TFRC seems > well-protected against > probing TCP flows and/or a low background loss rate. We will allow > applications to send at slightly above the TFRC rate as well. So > probably the situation is not that bad. This is gobbledy-gook to me. We already have tried to point out that you don't change the rate, except grossly, downward only, and only once or twice. You do that when your loss rate exceeds some threshold. You don't need any new mechanism to do this. So "reducing its rate far more slowly" is not possible for the media streams. There is no "send at slightly above the TRFC rate". The rate is fixed; TRFC can't tell the media stream anything interesting. > > Despite this, though, TFRC may reduce the allowed sending > rate to below > the application's nominal rate. The application can react to this > however it would like. For instance, it could stop sending, which I > think is the only other best-effort alternative on the > table. But if the > application *wanted* to, it could try to do better. Same issues. There is no "nominal rate" there is only the fixed rate. > > So, I think No, DCCP would not kill Internet real-time media > distribution. > > If these arguments aren't sound, we'd really like to hear it. I don't think they are sound: Slow start is not acceptable TRFC is not useful/acceptable There is only very limited rate change, we already have the mechanisms to do it DCCP isn't solving any problem that UDP has for media streams. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 09:59:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17537 for ; Wed, 3 Dec 2003 09:59:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYT1-00018K-CQ for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 09:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ex3NL004320 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 09:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYSz-00016g-If; Wed, 03 Dec 2003 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYS1-0000zk-GP for avt@optimus.ietf.org; Wed, 03 Dec 2003 09:58:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17457; Wed, 3 Dec 2003 09:57:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYRz-0002Ww-00; Wed, 03 Dec 2003 09:57:59 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARYRy-0002W5-00; Wed, 03 Dec 2003 09:57:58 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB3EvR1m010434; Wed, 3 Dec 2003 09:57:27 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 3 Dec 2003 09:57:11 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 09:57:11 -0500 Message-ID: From: "Phelan, Tom" To: "'Rosen, Brian'" , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Wed, 3 Dec 2003 09:57:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Brian, >> * Say there's no loss. >> >> If there's no loss, DCCP and UDP are equivalent, except that DCCP >> enforces slow-start. Slow-start will not matter for >> low-rate flows like >> most VoIP flows. It will for higher-rate flows like the 4 >> Mb/s video >> flow Brian Rosen has mentioned. A TFRC/DCCP flow could probably >> slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the >> absence of >> loss. > A typical RTT on the internet these days is 50-100 ms. > If you experience 30% loss in the first 3 RTTs of voice, you will clip > the "hello" pretty badly. If it's 7-8 RTTs, you will definitely have > a very poor experience. Are you saying that an interactive video session can't afford a pre-connection training period? It seems to me that all such systems that I've used have a several second delay at the start of the connection during which several things are negotiated. Voice-only connections have a stricter expectation of post-dial delay, but the four packets per RTT at the beginning of slow start is almost always enough for telephony-quality voice, so there is in practice no slow start. Are you also saying that you expect an app that sends at 4M bps to immediately change from 0 bps to 4M bps? Tom Phelan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 10:19:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16545 for ; Wed, 3 Dec 2003 09:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY4t-0007gP-LS for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 09:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3EY73E029487 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 09:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY4p-0007d5-1C; Wed, 03 Dec 2003 09:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARY49-0007al-MH for avt@optimus.ietf.org; Wed, 03 Dec 2003 09:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16413; Wed, 3 Dec 2003 09:33:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARY47-00024U-00; Wed, 03 Dec 2003 09:33:19 -0500 Received: from english-breakfast.cloud9.net ([168.100.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1ARY46-000246-00; Wed, 03 Dec 2003 09:33:18 -0500 Received: from localhost (localhost [127.0.0.1]) by english-breakfast.cloud9.net (Postfix) with ESMTP id DC869AAC4; Wed, 3 Dec 2003 09:32:42 -0500 (EST) Received: from english-breakfast.cloud9.net (localhost [127.0.0.1]) by localhost (VaMailArmor-2.0.1.7) id 39502-5DDC5055; Wed, 03 Dec 2003 09:32:42 -0500 Received: from COLLICULUS (248-223.customer.cloud9.net [168.100.248.223]) by english-breakfast.cloud9.net (Postfix) with ESMTP id AA7B6ACE1; Wed, 3 Dec 2003 09:32:42 -0500 (EST) Reply-To: From: "Qiong Li" To: Cc: Subject: RE: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate? Date: Wed, 3 Dec 2003 09:32:40 -0500 Organization: BrainMedia Message-ID: <86C0B7B413918E45A4B0A97F95657A0A152586@ceruleus.brainmediaco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <86C0B7B413918E45A4B0A97F95657A0A170A5A@ceruleus.brainmediaco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.7; VAE: 6.22.0.1; VDF: 6.22.0.54; host: english-breakfast.cloud9.net) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Huh? You seem to be saying that if you have a lot of TCP streams on a link they won't use all of the available bandwidth. I thought just the opposite. With a low level of multiplexing there's more chance of synchronizing losses and cutbacks, and not fully utilizing the link. But with a large number of flows enough of them will be blasting away while others are cut back. > If the congested link has low levels of statmux -- like one > DCCP flow and > one TCP flow -- then yes, the TCP would try for the available > bandwidth. > And during a silent period, the TFRC flow would have to > transmit something > so it wasn't crowded out entirely. But this amount would be > *half* the > nominal rate, or perhaps less. Not twice. So this relates to our previous conversation? When you're transmitting at less than the TFRC allowed rate, your allowed rate could be twice what you're transmitting. If a loss event happens, your allowed rate is cut back, but since it was twice what you were actually transmitting, no effect. This gives you the effective "protection" of transmitting at twice your necessary rate, without actually doing it. Great if it works. A simulation would be nice :-). _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 10:35:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20204 for ; Wed, 3 Dec 2003 10:35:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZ1z-000393-NQ for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 10:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FZBU4012088 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 10:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZ1p-000387-Dr; Wed, 03 Dec 2003 10:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZ1X-00037R-8E for avt@optimus.ietf.org; Wed, 03 Dec 2003 10:34:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20162; Wed, 3 Dec 2003 10:34:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZ1U-000358-00; Wed, 03 Dec 2003 10:34:40 -0500 Received: from english-breakfast.cloud9.net ([168.100.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1ARZ1T-000351-00; Wed, 03 Dec 2003 10:34:40 -0500 Received: from localhost (localhost [127.0.0.1]) by english-breakfast.cloud9.net (Postfix) with ESMTP id 1C9C4AD22; Wed, 3 Dec 2003 10:34:39 -0500 (EST) Received: from english-breakfast.cloud9.net (localhost [127.0.0.1]) by localhost (VaMailArmor-2.0.1.7) id 79859-1E0BAF4D; Wed, 03 Dec 2003 10:34:36 -0500 Received: from COLLICULUS (248-223.customer.cloud9.net [168.100.248.223]) by english-breakfast.cloud9.net (Postfix) with ESMTP id B213EAAE5; Wed, 3 Dec 2003 10:34:10 -0500 (EST) Reply-To: From: "Qiong Li" To: Cc: Subject: RE: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate? Date: Wed, 3 Dec 2003 10:34:07 -0500 Organization: BrainMedia Message-ID: <86C0B7B413918E45A4B0A97F95657A0A152587@ceruleus.brainmediaco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <86C0B7B413918E45A4B0A97F95657A0A170A5A@ceruleus.brainmediaco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.7; VAE: 6.22.0.1; VDF: 6.22.0.54; host: english-breakfast.cloud9.net) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry for the previous message. I was intending to make comments on the following posting regarding "TFRC allowed rate". -------------------------------------------------------------- ...... When you're transmitting at less than the TFRC allowed rate, your allowed rate could be twice what you're transmitting. If a loss event happens, your allowed rate is cut back, but since it was twice what you were actually transmitting, no effect. This gives you the effective "protection" of transmitting at twice your necessary rate, without actually doing it. ....... ---------------------------------------------------- Since TRFC allowed rate (R0) is estimated from observed loss rate (L) by the DCCP flow, and the two are positively correlated, R0 may be interpreted and used in different ways: - If the DCCP flow can tolerate a loss rate > L, it can consider to increase its sending rate. As long as its sending rate R < R0, it will not be considered to be unfair to other TCP flows. It does not necessarily means that when R < R0, it is always good to increase R. Doing that could result higher loss rate when the end-to-end path is lightly multiplexed with TCP flows. - If the estimated R0 is reduced, even that it is still higher than R, keeping the current sending rate for the DCCP flow may imply the flow will experience higher loss rate. The point: the adaptation of DCCP flow rate may need to combine the considerations of both R0 and L, depending on the codec characteristics. When the decoder can only perform error concealment under certain pre-designed loss rate, then the L should dominate the adaptation, assuming scalable media content is used, which may imply that R0 could become irrelevant under some circumstances. Qiong Li _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 10:56:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20753 for ; Wed, 3 Dec 2003 10:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZMF-00045F-Uh for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 10:56:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Fu7EI015696 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 10:56:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZMA-00043E-KC; Wed, 03 Dec 2003 10:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZLa-00042d-1L for avt@optimus.ietf.org; Wed, 03 Dec 2003 10:55:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20700; Wed, 3 Dec 2003 10:55:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZLV-0003Iw-00; Wed, 03 Dec 2003 10:55:21 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARZLV-0003Ie-00; Wed, 03 Dec 2003 10:55:21 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13667; Wed, 3 Dec 2003 10:54:00 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07175; Wed, 3 Dec 2003 10:53:55 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 10:53:55 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6166@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Wed, 3 Dec 2003 10:53:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Are you saying that an interactive video session can't afford a > pre-connection training period? It seems to me that all such > systems that > I've used have a several second delay at the start of the > connection during > which several things are negotiated. There are indeed a couple of RTTs for signalling and codec negotiation. There could be some ms of codec initialization, then data starts full steam. In most video codecs, it's actually worse, because you usually start with an I frame, that has the least compression. You end up buffering this away often to force the data to be more CBR like. We don't have this problem. Our video codec has an 8 frame (~250 ms) start time. That's around 2-5 RTTs. The data is flying at the CBR rate right away, but we don't display the video until we get around 8 frames into the sequence. If you delay the arrival of the 8 frame @ 4Mbit data, we'll have to delay the start of video. It's already annoying, because it's slower than the voice. > > Voice-only connections have a stricter expectation of > post-dial delay, but > the four packets per RTT at the beginning of slow start is > almost always > enough for telephony-quality voice, so there is in practice > no slow start. What I said was that if you have 30% loss for 4 RTTs and you listen to that, you will clip the "hello". Normally, you send RTP at the negotiated rate, and you play what you get. You could force more buffering before playback, which only increases PDD. Increases in PDD are measured in seconds. At 100ms, you need 10 RTTs to get an extra second. That would only be interesting if you don't experience loss during this period. However, there is a hard upper limit. You can't delay the voice more than 150 ms mouth to ear. The codec packetization period eats up a lot of that (40 ms), and the network eats up a lot (25-50ms typ one way, but usually you engineer for more). You don't get 4 RTTs of jitter buffering, that's for sure. If you are filling and emptying a buffer at a fixed rate (less jitter on the network), you can't build some buffer into the beginning of the stream and expect to bleed it off later. Once you have buffered up bits, you are stuck with that buffer +/- jitter. I don't have a lot of experience using TCP on media streams, so I'm not really sure what happens in practice. In UDP, the transmitter starts up sending at the fixed, negotiated rate. The receiver starts by filling the jitter buffer. When the buffer is "half" full, it starts playing at the fixed, negotiated rate. Filling the buffer is part of PDD, and it can cover some ugliness in actual arrival rate, but I don't think it covers what slow start actually does. Again, I really don't have enough experience to know for sure. > > Are you also saying that you expect an app that sends at 4M bps to > immediately change from 0 bps to 4M bps? Yep; bang! 0 to 4Mbit in two packets. Actually, there is some buffering at both ends in our system, but much less than you expect. We spent a LOT of time getting rid of buffering to make it work well. The entire video chain has less than 90 ms delay (flash a led in the camera, measure it on the screen) including camera and screen sync, encode/decode and all buffering. The video delay determines the audio delay in order to get lip sync. This is a very important characteristic it turns out, because it allows you to argue :) Not every system works like ours, for sure. Every video codec I know either has a burst at the beginning at higher than nominal rate, or has immediate CBR. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 10:59:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20844 for ; Wed, 3 Dec 2003 10:59:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZP5-0004JX-Ef for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 10:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Fx2vP016481 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 10:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZP3-0004H7-PX; Wed, 03 Dec 2003 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZOf-0004Gf-Fk for avt@optimus.ietf.org; Wed, 03 Dec 2003 10:58:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20824; Wed, 3 Dec 2003 10:58:20 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZOc-0003M3-00; Wed, 03 Dec 2003 10:58:34 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ARZOc-0003M0-00; Wed, 03 Dec 2003 10:58:34 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 291746A027; Wed, 3 Dec 2003 16:58:33 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 87FB519C46; Wed, 3 Dec 2003 16:58:32 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 05F3319C45; Wed, 3 Dec 2003 16:58:31 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id QAA01308; Wed, 3 Dec 2003 16:58:31 +0100 (MET) Subject: RE: [AVT] Would DCCP kill Internet real-time media distribution? To: "Rosen, Brian" Cc: avt@ietf.org, dccp@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 3 Dec 2003 16:55:36 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 03/12/2003 17:00:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Rosen you wrote: >So "reducing its rate far more slowly" is not possible for the media >streams. There is no "send at slightly above the TRFC rate". The >rate is fixed; TRFC can't tell the media stream anything interesting. I though this was already resolved ? case A: you have recent codecs and you *can* change the rate, (only of course not drastically due to the quality differences already mentioned, but again systems with moderate rate changes have been deployed and running for years in MPEG-2 DTV ) case B: your codec is strict CBR and then you need to tweak something so that this CBR stream is transmitted with some variable amount of garbage (this seems like an horrible shame to me but it seems also it would work) Is that correct ? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 10:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20860 for ; Wed, 3 Dec 2003 10:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZP6-0004Km-6I for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 10:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Fx4i2016639 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 10:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZP5-0004JZ-GQ; Wed, 03 Dec 2003 10:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZOb-0004Ge-L4 for avt@optimus.ietf.org; Wed, 03 Dec 2003 10:58:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20820 for ; Wed, 3 Dec 2003 10:58:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZOZ-0003Lx-00 for avt@ietf.org; Wed, 03 Dec 2003 10:58:31 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1ARZOY-0003Lh-00 for avt@ietf.org; Wed, 03 Dec 2003 10:58:30 -0500 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB3FvjH20131; Wed, 3 Dec 2003 10:57:45 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLY22Y97; Wed, 3 Dec 2003 10:57:45 -0500 Received: from nortelnetworks.com (acart1c0.ca.nortel.com [47.129.129.43]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM9BK; Wed, 3 Dec 2003 10:57:45 -0500 Message-ID: <3FCE07F7.7040007@nortelnetworks.com> Date: Wed, 03 Dec 2003 10:57:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: A vWijk , avt@ietf.org, gunnar.hellstrom@omnitor.se, toip@snowshore.com, gv@trace.wisc.edu Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 References: <00c801c3b8f5$40ed2ed0$0401a8c0@berlin> In-Reply-To: <00c801c3b8f5$40ed2ed0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The existing events in 2833 have to do primarily with startup. I have to ask how the TOIP people see startup negotiation working without 2833 support. You still have to deal with V.8 or V.8bis in the more advanced terminals. There is the fact that two V.18 terminals in conversation phase use V.21, and V.21 events are included in the 2833 repertoire. This means that telephone events could be used during conversation phase in some cases. However, the basic discussion is over the set of events needed to achieve transition to conversation phase successfully. Turning to the conversational phase, I do not see how the use of RFC 2793 between gateways in place of the various alternatives (G.711 VBD, V.150.1 modem relay, the tones payload type, V.21 or other events) will affect the user experience. I assume the reason this is desired is to simplify the transition to packet-mode terminals. The problem here is that gateways have to handle a wide variety of traffic, not just text. This makes more generic approaches like V.150.1 for voice-band data simpler to implement, so I see some vendors making that choice. Obviously, if packet terminals require RFC 2793 and gateways cannot handle it, deployment of these gateways is limited to bridging of PSTN segments. Given that this application still represents a substantial market segment, we should probably add the 2833 events needed to handle it properly. Paul E. Jones wrote: > Arnoud, > > RFC 2833 can be used to convey tone information (frequencies and durations), > as well as tone events. It's not restricted to DTMF. > > RFC 2833 could potentially be used as an alternative to RFC 2793. A gateway > or IP phone, for example, could simply examine the tones and convey those as > "descriptions" (either frequency and duration information or event codes) > over an IP network. The other end could then receive those descriptions and > reproduce the tones. They would not have to understand the underlying > textphone protocol. > > The problem with RFC 2833, as I see it, is that it stands at odds with the > desire of folks on the ToIP mailing list to try to remove textphone > signaling from the IP network. There has been a strong desire expressed to > terminate that textphone signaling at the gateway and only use text on the > IP network. Doing that, arguably, would make interfacing with IP-based IVR > systems, IP-based voice/text-mail systems, or other IP-based systems much > easier. I say "arguably" because some have suggested to me that it's very > simple to write software that understand the textphone signals received in > RFC 2833 packets... though I personally think it puts an unfortunate burden > on a Pocket PC, for example. > > To this point, neither the ITU nor the IETF has considered RFC 2833 as an > option or alternative to RFC 2793. I think this is probably an important > topic that we should take up immediately, as both bodies are forging ahead > with plans based on RFC 2793 only. > > Paul > > ----- Original Message ----- > From: "A vWijk" > To: ; ; ; > ; > Sent: Tuesday, December 02, 2003 7:45 AM > Subject: Betr.: FW: [AVT] Missing events in RFC 2833 > > > >>Gunnar, >>why is this desirable? >> >>We will have T.140 over RTP and in some cases over TCP/IP. >>Why the tones? >> >>Or am I mixing things up again? RFC2833 is for DTMF signalling? >> >>greetz >> >>Arnoud >> >>Drs. Arnoud A. T. van Wijk >>Viataal >>Research & Development >>Afdeling RDS >>Theerestraat 42 >>5271 GD Sint-Michielsgestel >>The Netherlands. >>Mobile: +31651921948 >>International text telephone: +31735588408 >> >> >>>>>"Gunnar Hellstrom" 01-12-03 23:20 >>> >> >>Below, Tom Taylor asks if there is any interest to complete the textphone >>related tone events in RFC2833 so that all V.18 submodes can be > > transported > >>with RFC2833. >> >>We have to verify that we have satisfying detection and transport methods > > in > >>RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can >>leave RFC2833 half done for text transport. >> >>I would like to do so, but then the market forces must be strong enough to >>make RFC2793 and textphone detection commonplace. >> >>Using RFC2833 will place a task similar to V.18 logic on the IP endpoint, >>but with less exact information than the native V.18 has. We have no >>analysis if that task is realistic, nor if it is likely to be implemented > > by > >>IP endpoint developers. >> >>( The missing events for complete text transport are probably: >>V.21 data in lo channel at 110 bits/s >>Bell 103 hi channel data at 300 bits/s >>Bell 103 lo channel data at 300 bits/s >>V.23 data at 1200 bits/s >>V.23 data at 75 bits/s >>Baudot data at 45.45 bits/s >>Baudot data at 50 bits/s >> >>(assuming that V.8 signals and V.21 at 300 bits/s in both directions and >>DTMF are covered ) >> >>Gunnar >> >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Original Message----- >>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom >>Taylor >>Sent: Monday, December 01, 2003 5:37 PM >>To: avt@ietf.org >>Subject: [AVT] Missing events in RFC 2833 >> >> >>I'm finding it a little difficult to see how some of the applications >>supported by RFC 2833 work without a few more events. Here are some >>examples: >> >>1. V.18 text telephones interwork with a number of other text telephone >>types. The only event defined specifically for V.18 operation seems >>rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. >>There don't seem to be any events for Baudot or V.23 or for Bell 103 in >>calling mode. >> >>2. Signalling System No. 5 has two sets of signals: line signals, which >>are tones controlling trunk state, and register signals, which convey >>digits with some supporting information. There is a timing constraint >>that register signalling must begin within 80 +/- 20 ms of the end of >>the "seize" line signal. Yet no event is defined for "seize", only for >>the register signals. It's a little hard to see how the receiving >>gateway can propagate KPx (the initial register signal) on time if it >>doesn't know that "seize" was playing, even if the sending end can >>recognize and report the start of KPx within the 20 ms tolerance. As I >>see it, the present set of events is useful only to transfer the >>register events from one gateway to another which will report them to >>call control rather than propagating them as tones. >> >>These missing events raise the issue of whether proposals to add events >>to RFC 2833 should be backed up by requirements documents describing >>their use. I have been adding brief application descriptions in my >>rewrite of 2833bis, as justification for the normative text which I have >>also been adding. (Basically just obvious stuff, missing the first time >>around and highlighted by Flemming's comments earlier this year.) I am >>hoping that this additional information prompts a critical review of the >>current set of 2833/2833bis events, with a view to rounding them out as >>necessary to make applications work well. >> >>Tom Taylor >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt >> >> >>- >>This list is maintained by Snowshore Networks - http://www.snowshore.com >>All comments on this list are the comments of the message originators and >>Snowshore is not to be held responsible for any actions or comments found >>on this list. The archives for this list can be found at >>http://flyingfox.snowshore.com/toip_archive/maillist.html >> > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 11:19:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21808 for ; Wed, 3 Dec 2003 11:19:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZiR-0006An-Je for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 11:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3GJ3IB023712 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 11:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZiP-00069u-I7; Wed, 03 Dec 2003 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZhz-00069E-Tn for avt@optimus.ietf.org; Wed, 03 Dec 2003 11:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21766 for ; Wed, 3 Dec 2003 11:18:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZhz-0003k7-00 for avt@ietf.org; Wed, 03 Dec 2003 11:18:35 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARZhy-0003k4-00 for avt@ietf.org; Wed, 03 Dec 2003 11:18:34 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB3GISsD015870; Wed, 3 Dec 2003 08:18:28 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312031618.hB3GISsD015870@coyote.icir.org> To: Jon Crowcroft cc: avt@ietf.org Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media distribution? In-Reply-To: Your message of "Wed, 03 Dec 2003 07:46:53 GMT." Date: Wed, 03 Dec 2003 08:18:28 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > btw the comment on adaptive rate sucks - its correct - the usertrials > folks at UCL did certainly show that there is little point increasing the > quality of video/audio if you are going to have to decrease it , within a > session, as the user experiecne contains a lot of hysteresis - i.e. they > habituate, but the user reports the worst rate they see, and variation > (up from that and down to it) degrade the overall experience more (even > though the average rate may be better).... This is surely a comment about *one* system/codec, or one family -- other people on the list have mentioned that some codecs behave better? E _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 11:36:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22569 for ; Wed, 3 Dec 2003 11:36:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZzF-00070P-Ec for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 11:36:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3GaPDk026880 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 11:36:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZys-0006vA-Ow; Wed, 03 Dec 2003 11:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZyd-0006uK-Of for avt@optimus.ietf.org; Wed, 03 Dec 2003 11:35:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22487; Wed, 3 Dec 2003 11:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZyc-00040E-00; Wed, 03 Dec 2003 11:35:46 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARZyY-00040B-00; Wed, 03 Dec 2003 11:35:43 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB3GZesD015976; Wed, 3 Dec 2003 08:35:40 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312031635.hB3GZesD015976@coyote.icir.org> To: "Rosen, Brian" cc: avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] Is TCP broken? In-Reply-To: Message from "Rosen, Brian" of "Wed, 03 Dec 2003 09:10:17 EST." <313680C9A886D511A06000204840E1CF070B6162@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 03 Dec 2003 08:35:40 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > > if the congested link has a small level of statmux, then the > > congested router or media could just punish TCP a bit to get it back > > in line. > I don't think there exists mechanisms to do this, because you > need immediate response when the stream starts, and nothing > in TCP does immediate - it's designed to react slowly. ? TCP is designed to react *quickly*. It halves its rate after a single dropped packet (after an RTT of course). > > Without a bandwidth reservation, it's hard to know how to do better. > I don't believe this. I think it's possible to do some relatively > simple things to TCP that would help media streams quite a bit. Such as? (1) I don't think the situation is that bad; (2) it seems like any modification to TCP to cause it to probe slower for excess bandwidth would cut to TCP's heart. > > Now, if the real-time media flow was using TFRC, it could preserve > > its bandwidth allocation essentially indefinitely by sending probe > > traffic at *half* its full-speed rate during silent periods (NOT > > twice). > This is not tenable. No application would do this; they would > simply turn off the Voice Activity Detection. It's also wrong. > It illustrates that indeed TCP is broken. TCP needs a mechanism > to determine it's "fair" share and use extra bandwidth opportunistically, > returning to "fair" immediately when asked. I disagree with each of these points. Would 'no' application really do this? If an application was given the choice of (1) not sending over the best-effort internet or (2) sending traffic during silence periods, why wouldn't the application choose (2)? And why wouldn't an application that sent at a reduced rate during silence periods have a competitive advantage (assuming people cared about bandwidth)? TCP has a mechanism to determine its fair share, namely bandwidth probing. It has a mechanism to adjust to the introduction of new flows, namely halving its rate after single loss periods. TFRC is robust against bandwidth probing. You want your media flow to start up from nothing, after a silent period of seconds or minutes, with no loss. That is not best effort. That is a bandwidth reservation. I don't understand how this would work even in an environment with only media streams. If the sum of the streams' non-silent bandwidth is greater than the link bandwidth, then you may end up with loss when all the streams aren't silent. What should the streams do then? Suicide? Live with high loss rates? Rely on the users to go away? If the network has been engineered so that this situation cannot happen, then it's a QoS network. > > I don't think TCP's bandwidth probes will punish TFRC unduly. > > Simulations have been done showing that TCP and TFRC achieve pretty > > fair allocations. > TRFC, as I understand it, does not work for media flows, > which are on/off constant rate. It is not interesting to look > at steady state; you have to include startup/shutdown. > All the simulations I've seen either show that TRFC won't start > cleanly for CBR-like flows, or don't show how start/stop works > at all. Not all media streams are on/off constant rate as people have brought up, but yes, slow-start exists and could be problematic for CBR users. But I don't understand why this is the complete killer it's being painted to be. Not for all media flows anyway. Is delivering media over the current Internet important enough that users could afford to wait < 1 second for slow start? (Which, incidentally, is entirely within the range application startup delay times.) If the answer is no, fine; use QoS. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 11:44:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22858 for ; Wed, 3 Dec 2003 11:44:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARa6e-0007g5-M4 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 11:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Gi4QR029495 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 11:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARa6b-0007cQ-F6; Wed, 03 Dec 2003 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARa5g-0007b3-Be for avt@optimus.ietf.org; Wed, 03 Dec 2003 11:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22768; Wed, 3 Dec 2003 11:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARa5e-00045x-00; Wed, 03 Dec 2003 11:43:02 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARa5e-00045u-00; Wed, 03 Dec 2003 11:43:02 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB3Gh1sD016017; Wed, 3 Dec 2003 08:43:01 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312031643.hB3Gh1sD016017@coyote.icir.org> To: "Rosen, Brian" cc: avt@ietf.org, dccp@ietf.org Subject: Re: [AVT] Would DCCP kill Internet real-time media distribution? In-Reply-To: Message from "Rosen, Brian" of "Wed, 03 Dec 2003 09:28:49 EST." <313680C9A886D511A06000204840E1CF070B6163@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 03 Dec 2003 08:43:01 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > A typical RTT on the internet these days is 50-100 ms. > If you experience 30% loss in the first 3 RTTs of voice, you will clip > the "hello" pretty badly. If it's 7-8 RTTs, you will definitely have > a very poor experience. Hm. I think users are pretty used to startup delays of far more than 1 second when making telephone calls. The application can mask this easily. Is the sense of the avt group really that slow start is completely unacceptable for any important media flows? > This is gobbledy-gook to me. We already have tried to point out > that you don't change the rate, except grossly, downward only, > and only once or twice. You do that when your loss rate exceeds > some threshold. You don't need any new mechanism to do this. > > So "reducing its rate far more slowly" is not possible for the media > streams. There is no "send at slightly above the TRFC rate". The > rate is fixed; TRFC can't tell the media stream anything interesting. First, not all applications cannot change the rate, as people have mentioned. Second, TFRC provides you with a reference rate. For fail-stop CBR applications, this reference rate could be taken as an indication of when the application must stop. When I said "the rate changes slowly", it was simply to point out that TFRC changes its reference rate slowly. Thus, a fail-stop CBR application would not be forced to stop after a small number of losses -- only after the loss rate really changed. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 11:56:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23257 for ; Wed, 3 Dec 2003 11:56:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaIH-0008Kf-1h for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 11:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Gu4Vg032013 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 11:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaID-0008JL-Tw; Wed, 03 Dec 2003 11:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaHK-0008Dl-Aw for avt@optimus.ietf.org; Wed, 03 Dec 2003 11:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23214 for ; Wed, 3 Dec 2003 11:54:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaHI-0004FR-00 for avt@ietf.org; Wed, 03 Dec 2003 11:55:04 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARaHI-0004FA-00 for avt@ietf.org; Wed, 03 Dec 2003 11:55:04 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16412; Wed, 3 Dec 2003 11:54:09 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18366; Wed, 3 Dec 2003 11:54:07 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 11:54:06 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6167@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" Cc: Jon Crowcroft , avt@ietf.org Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Wed, 3 Dec 2003 11:54:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I have never heard/seen a codec that can dynamically, in real time, vary its rate in response to network conditions in a way that is not objectionable to the user. I have seen/heard a lot of codecs, but clearly, not all, or most, or even a significant percentage on live networks. Your mileage may vary. I'm dimly aware of what Philippe is talking about, but I don't think it does what the first paragraph above describes today. It does hint that it might be possible to build such a thing, but I don't know what the tradeoffs are. For example, what is the effect on delay? It's certainly not in the realm of practical deployment in the near future for interactive media. I don't think it's practical for deployment in the near future for non-interactive media, but I don't know as much about that world as I do the interactive world. Brian > -----Original Message----- > From: Eddie Kohler [mailto:kohler@icir.org] > Sent: Wednesday, December 03, 2003 11:18 AM > To: Jon Crowcroft > Cc: avt@ietf.org > Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media > distribution? > > > > btw the comment on adaptive rate sucks - its correct - the > usertrials > > folks at UCL did certainly show that there is little point > increasing the > > quality of video/audio if you are going to have to decrease > it , within a > > session, as the user experiecne contains a lot of > hysteresis - i.e. they > > habituate, but the user reports the worst rate they see, > and variation > > (up from that and down to it) degrade the overall > experience more (even > > though the average rate may be better).... > > This is surely a comment about *one* system/codec, or one > family -- other > people on the list have mentioned that some codecs behave better? > > E > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 12:13:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23864 for ; Wed, 3 Dec 2003 12:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaYh-0001PZ-U0 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 12:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3HD3bS005393 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 12:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaYg-0001OO-0r; Wed, 03 Dec 2003 12:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaYU-0001Nb-Ai for avt@optimus.ietf.org; Wed, 03 Dec 2003 12:12:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23833; Wed, 3 Dec 2003 12:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaYR-0004Wo-00; Wed, 03 Dec 2003 12:12:47 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ARaYQ-0004Wl-00; Wed, 03 Dec 2003 12:12:46 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB3HCjsD016229; Wed, 3 Dec 2003 09:12:45 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312031712.hB3HCjsD016229@coyote.icir.org> To: "Rosen, Brian" , avt@ietf.org, dccp@ietf.org In-Reply-To: Message from Eddie Kohler of "Wed, 03 Dec 2003 08:43:01 PST." <200312031643.hB3Gh1sD016017@coyote.icir.org> Date: Wed, 03 Dec 2003 09:12:45 -0800 From: Eddie Kohler Subject: [AVT] Re: Would DCCP kill Internet real-time media distribution? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Is the sense of the avt group really that slow start is completely > unacceptable for any important media flows? Also, for what it's worth, I do understand and sympathize with the problems that slow start can cause a truly-CBR application. I don't think slow-start is all peaches and cream. The problem is, Best Effort Public Internet == Slow Start. There are proposals to eliminate the need for slow-start through explicit feedback from routers (XCP, QuickStart), but they're a ways off. Maybe media will be the app that pushes them through Cisco? Significant TCP changes are probably even less likely. (They're certainly less likely without any proposal on the board.) In the meantime, we really do have a situation where a media application should either do slow start or something similar, or it should stay off the public internet. Brian, I'm coming to the conclusion that your app should stay off the public internet -- or you may need to change the app so that it will work best off the public internet, when it can get a true bandwidth reservation. Maybe that's OK for how your app is used in practice? Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 12:20:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24154 for ; Wed, 3 Dec 2003 12:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARafY-0001ff-FK for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 12:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3HK8Mh006417 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 12:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARafV-0001ex-LB; Wed, 03 Dec 2003 12:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaf3-0001dk-Ts for avt@optimus.ietf.org; Wed, 03 Dec 2003 12:19:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24120 for ; Wed, 3 Dec 2003 12:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaf2-0004cv-00 for avt@ietf.org; Wed, 03 Dec 2003 12:19:36 -0500 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1ARaf1-0004cs-00 for avt@ietf.org; Wed, 03 Dec 2003 12:19:35 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hB3HJMe9022415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Dec 2003 12:19:28 -0500 (EST) Message-ID: <3FCE1B1B.3000802@cs.columbia.edu> Date: Wed, 03 Dec 2003 12:19:23 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Eddie Kohler'" , avt@ietf.org Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? References: <313680C9A886D511A06000204840E1CF070B6167@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6167@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Multi-party, non-multicast (central server) conferences should not be forgotten in this discussion. They complicate life in two ways: - The penalty of not using silence suppression gets much larger. If you have a conference with 100 participants, a modern implementation would have one or two active inbound stream and 100 outbound (mixed) streams. If applications need to keep sending data to keep their place, suddenly inbound data volume will be multiplied by a factor of between 50 (transmitting at half rate) and 100. This gets worse for the typical video-follows-audio setup. - Similarly, for a useful interactive conference, participants have to be able to interject and speak up immediately, with the video stream following instantaneously. They cannot wait multiple round-trip times as they'll never get a word in edgewise. Thus, there is no masking of ramp-up delays if you want a reasonable user experience. (Similar considerations apply to the now very popular push-to-talk services. Trying to sell a service where the user has to push, wait and then talk does not seem like a winning proposition.) Masking is also rather tricky for two-party audio. There was a long discussion in the SIP working group on this topic a few years ago, leading to fairly elaborate hand-offs between reservation and session signaling to minimize the post-pickup delay. As soon as I hit the 'accept call' button, I need to be able to say 'hello' and be heard by the other side. The only masking opportunity is to start sending audio data 'to warm up the line' while the phone is ringing, adding more bandwidth consumption for the large number of calls that don't succeed. At $4/MB for mobile voice data, this is unlikely to be popular. (Typical ring-to-answer delays are about 20 seconds; average call durations for mobile are probably three minutes, so this immediately adds about 10% overhead, not counting the 60% or so of calls that fail over to voicemail after 30 seconds.) I believe that there now is a suggested initial TCP windows size > 1. Is this correct? (If you figure a maximum acceptable network delay of 100 ms and a typical audio/video packet spacing of 50 ms, you would be sending about 4 packets per RTT.) Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 12:36:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24847 for ; Wed, 3 Dec 2003 12:36:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARauz-0002N5-47 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 12:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ha5EM009092 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 12:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARauv-0002Ir-El; Wed, 03 Dec 2003 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARau2-0002Hj-EC for avt@optimus.ietf.org; Wed, 03 Dec 2003 12:35:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24779; Wed, 3 Dec 2003 12:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARau0-0004tR-00; Wed, 03 Dec 2003 12:35:04 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARau0-0004sP-00; Wed, 03 Dec 2003 12:35:04 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB3HYX1m020631; Wed, 3 Dec 2003 12:34:33 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 3 Dec 2003 12:34:21 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 12:34:21 -0500 Message-ID: From: "Phelan, Tom" To: "'qli@brainmediaco.com'" , avt@ietf.org Cc: dccp@ietf.org Subject: RE: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its prefer red rate? Date: Wed, 3 Dec 2003 12:34:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Qiong, See inline ... Tom Phelan > -------------------------------------------------------------- > ...... When you're transmitting at > less than the TFRC allowed rate, your allowed rate could be twice what > you're transmitting. If a loss event happens, your allowed > rate is cut > back, but since it was twice what you were actually transmitting, no > effect. > This gives you the effective "protection" of transmitting at > twice your > necessary rate, without actually doing it. > > ....... > ---------------------------------------------------- > > Since TRFC allowed rate (R0) is estimated from observed loss > rate (L) by > the DCCP flow, and the two are positively correlated, R0 may be > interpreted and used in different ways: > > - If the DCCP flow can tolerate a loss rate > L, it can consider to > increase its sending rate. As long as its sending rate R < R0, it will > not be considered to be unfair to other TCP flows. It does not > necessarily means that when R < R0, it is always good to increase R. > Doing that could result higher loss rate when the end-to-end path is > lightly multiplexed with TCP flows. > > - If the estimated R0 is reduced, even that it is still higher than R, > keeping the current sending rate for the DCCP flow may imply the flow > will experience higher loss rate. If the loss rate persists, TFRC will continue to reduce R0 until it's below R. At that time the app could reduce its rate, or discard packets until the loss rate is too great. But this isn't necessarily a persistent loss situation. If the loss was induced by other congestion controlled streams probing for more capacity, then they should back off and the losses should stop. It should be persistent only when there are enough competing streams that each stream's share is less than R. > > The point: the adaptation of DCCP flow rate may need to combine the > considerations of both R0 and L, depending on the codec > characteristics. > When the decoder can only perform error concealment under certain > pre-designed loss rate, then the L should dominate the adaptation, > assuming scalable media content is used, which may imply that R0 could > become irrelevant under some circumstances. > > Qiong Li > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 12:40:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25200 for ; Wed, 3 Dec 2003 12:40:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaz4-00035a-1d for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 12:40:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3HeHXs011824 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 12:40:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARays-00030D-IG; Wed, 03 Dec 2003 12:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARay8-0002yc-8B for avt@optimus.ietf.org; Wed, 03 Dec 2003 12:39:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25039; Wed, 3 Dec 2003 12:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARay6-0004yG-00; Wed, 03 Dec 2003 12:39:18 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1ARay5-0004xy-00; Wed, 03 Dec 2003 12:39:17 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hB3HcoIW001790; Wed, 3 Dec 2003 10:38:50 -0700 (MST) Received: from motorola.com ([10.2.192.37]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hB3HbYGS026266; Wed, 3 Dec 2003 11:37:35 -0600 Message-ID: <3FCE1FB1.950C93C7@motorola.com> Date: Wed, 03 Dec 2003 11:38:58 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eddie Kohler CC: avt@ietf.org, dccp@ietf.org References: <200312030311.hB33BAsD010423@coyote.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eddie Kohler wrote: > > But, if people suddenly realize that turning off their encoder silence > > detection immediately gives them better voice quality and start to do so in a > > large scale, what good it would do to the network? Would IAB have the power to > > tell people not to do so? > > TCP-friendliness without silence suppression is probably better for the > best-effort Internet than non-TCP-friendliness with silence suppression. > Eddie, I wish I could be as optimistic as you. I wonder if anyone on the list has some numbers that can show what percentage of additional media data will be injected into the network if codecs would stop doing silence detection (motion detection for video). Fundamentally, I am concerned that this DCCP "app-who-sends-more-will-get-rewarded" feature will be taken advantage of in the wrong way (the draft that starts this discussion is the first attempt for this, but it won't be the last). If this behavior of "sending filler data when no real data to send" becomes a recommended practice for media-over-DCCP (as you and Tom seem to suggest), what would stop the same recommendation be made for app over TCP? For an app over a long lived TCP connection, the sender can also benefit from sending "filler data" to keep the pipe from collapsing, so as to avoid the penalty of going through another slow start when it has real data to send next time. But I think this is hardly something that should be recommended for TCP based apps. Why should it be more acceptable for DCCP then? regards, -Qiaobing > > Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 13:22:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27288 for ; Wed, 3 Dec 2003 13:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbdW-000563-R0 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 13:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3IM6JX019590 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 13:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbdQ-00055I-TV; Wed, 03 Dec 2003 13:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARbcl-00054g-Ut for avt@optimus.ietf.org; Wed, 03 Dec 2003 13:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27235 for ; Wed, 3 Dec 2003 13:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbcf-0005nj-00 for avt@ietf.org; Wed, 03 Dec 2003 13:21:13 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ARbce-0005lQ-00 for avt@ietf.org; Wed, 03 Dec 2003 13:21:12 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB3IJs516664; Wed, 3 Dec 2003 13:19:55 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLST15NJ; Wed, 3 Dec 2003 13:19:55 -0500 Received: from nortelnetworks.com (acart1c0.ca.nortel.com [47.129.129.43]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM9DV; Wed, 3 Dec 2003 13:19:55 -0500 Message-ID: <3FCE294A.20008@nortelnetworks.com> Date: Wed, 03 Dec 2003 13:19:54 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnoud van Wijk CC: "'Paul E. Jones'" , avt@ietf.org, gunnar.hellstrom@omnitor.se, toip@snowshore.com, gv@trace.wisc.edu Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 References: <000201c3b9bd$451e7f90$0300a8c0@solstice> In-Reply-To: <000201c3b9bd$451e7f90$0300a8c0@solstice> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK, so in North America the gateway always emulates a Baudot terminal. That means it won't be possible to negotiate alternating text and voice with a V.18 terminal. I imagine Gunnar's bitter response to that one is that nobody is making V.18 terminals anyway. Arnoud van Wijk wrote: > I think the question we need answered is: > " Do we need to transport real-timing streaming text (aka Interactive Text) > through PSTNs with RFC 2833 (a beefed up version of it)?" > > For Interactive Texting, gateways it will be necessary to allow backward > compatibility with analogue textphones. Transcoding from T.140/RTP into the > local legacy textphone protocol. For America it is then Boudot. > All that the gateway has to do is simply connect to a PSTN using Boudot over > the voice channel. Every PSTN connects with an Interactive Text gateway. And > that IT gateway does the transcoding, so that the PSTN sees it as a voice > channel as it is done today. > > There is then no RFC 2833 involved for the Interactive Texting. > > Thus when we get 2 PSTN's that are linked together over IP for a voice call, > then is it much easier to send the text as RFC 2793. > So, the only requirement is then that every PSTN must have a means to > transcode RFC 2793 into local analogue text telephony (directly or via an IT > gateway). > > I want to have clarity on this before starting to complicate matters even > more. Analogue text telephony is a dying beast. And my goal is to kill it as > fast as possible without any problems. > > Greetz > > Arnoud > > Drs. Arnoud A. T. van Wijk > Viataal > Research & Development > Afdeling RDS > Theerestraat 42 > 5271 GD Sint-Michielsgestel > The Netherlands. > Mobile: +31651921948 > International text telephone: +31735588408 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 13:46:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28790 for ; Wed, 3 Dec 2003 13:46:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1I-0006Ai-SG for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 13:46:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ikebp023718 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 13:46:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc0f-00068B-VL; Wed, 03 Dec 2003 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc0D-00067Z-EK for avt@optimus.ietf.org; Wed, 03 Dec 2003 13:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28757; Wed, 3 Dec 2003 13:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARc0B-0006OY-00; Wed, 03 Dec 2003 13:45:31 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARc0A-0006ON-00; Wed, 03 Dec 2003 13:45:30 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB3Ij01m024739; Wed, 3 Dec 2003 13:45:00 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 3 Dec 2003 13:44:52 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 13:44:52 -0500 Message-ID: From: "Phelan, Tom" To: "'Qiaobing Xie'" , Eddie Kohler Cc: avt@ietf.org, dccp@ietf.org Date: Wed, 3 Dec 2003 13:44:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Qiaobing, It appears that it isn't necessary to send extra data to get the "protection" I was seeking. I was erroneously assuming that when TFRC reduced the send rate, it reduced from what you were actually sending, not from what you were allowed to send. Given this I think that the recommendation in my draft was unnecessary, and I'll be modifying it. If DCCP can do it why can't TCP? In the particular case I was talking about, the DCCP app was sending less than it was "allowed" to. It seemed reasonable to put some (but not necessarily all) of that excess allowance to good use. Most TCP apps always send at the maximum allowed rate, so padding wouldn't be possible. If a TCP app was satisfied with less than the allowed rate, I suppose it could "pad" to preserve that rate. But it's difficult to imagine such a restrained app using TCP with its abrupt rate variations and in-order delivery. It seems to me that these types of apps are better served by DCCP/TFRC (or they just ignore congestion issues and use UDP). Tom Phelan > -----Original Message----- > From: Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com] > Sent: Wednesday, December 03, 2003 12:39 PM > To: Eddie Kohler > Cc: avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] Would a DCCP flow need to send 2x its preferred > rate? > > > Eddie Kohler wrote: > > > > But, if people suddenly realize that turning off their > encoder silence > > > detection immediately gives them better voice quality and > start to do so in a > > > large scale, what good it would do to the network? Would > IAB have the power to > > > tell people not to do so? > > > > TCP-friendliness without silence suppression is probably > better for the > > best-effort Internet than non-TCP-friendliness with silence > suppression. > > > > Eddie, > > I wish I could be as optimistic as you. I wonder if anyone on > the list has some > numbers that can show what percentage of additional media > data will be injected into > the network if codecs would stop doing silence detection > (motion detection for > video). > > Fundamentally, I am concerned that this DCCP > "app-who-sends-more-will-get-rewarded" > feature will be taken advantage of in the wrong way (the > draft that starts this > discussion is the first attempt for this, but it won't be the last). > > If this behavior of "sending filler data when no real data to > send" becomes a > recommended practice for media-over-DCCP (as you and Tom seem > to suggest), what > would stop the same recommendation be made for app over TCP? > For an app over a long > lived TCP connection, the sender can also benefit from > sending "filler data" to keep > the pipe from collapsing, so as to avoid the penalty of going > through another slow > start when it has real data to send next time. But I think > this is hardly something > that should be recommended for TCP based apps. Why should it > be more acceptable for > DCCP then? > > regards, > -Qiaobing > > > > > > Eddie > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 14:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00663 for ; Wed, 3 Dec 2003 14:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcq3-0008U5-Dn for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 14:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Jd7be032607 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 14:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcpw-0008Qv-Un; Wed, 03 Dec 2003 14:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcpG-0008QQ-I9 for avt@optimus.ietf.org; Wed, 03 Dec 2003 14:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00579; Wed, 3 Dec 2003 14:38:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcpD-00074y-00; Wed, 03 Dec 2003 14:38:15 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARcpD-00074M-00; Wed, 03 Dec 2003 14:38:15 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22872; Wed, 3 Dec 2003 14:37:39 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16436; Wed, 3 Dec 2003 14:37:39 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 14:37:38 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B616C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Date: Wed, 3 Dec 2003 14:37:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: Would DCCP kill Internet real-time media distribution? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > > Is the sense of the avt group really that slow start is completely > > unacceptable for any important media flows? > > Also, for what it's worth, I do understand and sympathize > with the problems > that slow start can cause a truly-CBR application. I don't think > slow-start is all peaches and cream. > > The problem is, Best Effort Public Internet == Slow Start. Where does it say that? Right now, we send UDP. It actually works pretty well, but it clearly doesn't work if you have a bunch of TCP sources gobbling up the bandwidth. DCCP is not going to change the effect of TCP on the media, it's going to change the effect of the media on TCP. We don't need no DCCP. "Fair" to media is all or nothing, Philippe's ideas notwithstanding. Nothing is fair if the alternative is garbage. If your goal is to prevent what is today mythical congestion collapse, then we would be much better served by talking about how signalling can get loss rates so that it can shut down flows. That's simple, and it won't screw anything up. Brian > > There are proposals to eliminate the need for slow-start > through explicit > feedback from routers (XCP, QuickStart), but they're a ways > off. Maybe > media will be the app that pushes them through Cisco? Significant TCP > changes are probably even less likely. (They're certainly less likely > without any proposal on the board.) I'll agree with this, although I'm also willing to work on solutions. > > In the meantime, we really do have a situation where a media > application > should either do slow start or something similar, or it > should stay off the > public internet. Brian, I'm coming to the conclusion that > your app should > stay off the public internet -- or you may need to change the > app so that > it will work best off the public internet, when it can get a > true bandwidth > reservation. Maybe that's OK for how your app is used in practice? Sorry, but as you might imagine, I don't agree. See the note from Henning. We use 4M, while other systems might use 768K. That's no reason to have any difference in protocols. Slow start is not a practical thing for interactive use, sorry. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 15:25:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03413 for ; Wed, 3 Dec 2003 15:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdYi-0001aA-75 for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 15:25:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KPGox006076 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 15:25:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdYT-0001Z3-Lu; Wed, 03 Dec 2003 15:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdY5-0001Yl-Mc for avt@optimus.ietf.org; Wed, 03 Dec 2003 15:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03390 for ; Wed, 3 Dec 2003 15:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARdY2-0007ae-00 for avt@ietf.org; Wed, 03 Dec 2003 15:24:34 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARdY1-0007aW-00 for avt@ietf.org; Wed, 03 Dec 2003 15:24:33 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24811; Wed, 3 Dec 2003 15:23:59 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25436; Wed, 3 Dec 2003 15:24:00 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Dec 2003 15:24:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B616F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Eddie Kohler'" , avt@ietf.org Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Wed, 3 Dec 2003 15:23:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Yes yes. Another example is Push-To-Talk Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, December 03, 2003 12:19 PM > To: Rosen, Brian > Cc: 'Eddie Kohler'; avt@ietf.org > Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > Multi-party, non-multicast (central server) conferences should not be > forgotten in this discussion. They complicate life in two ways: > > - The penalty of not using silence suppression gets much > larger. If you > have a conference with 100 participants, a modern > implementation would > have one or two active inbound stream and 100 outbound > (mixed) streams. > If applications need to keep sending data to keep their > place, suddenly > inbound data volume will be multiplied by a factor of between 50 > (transmitting at half rate) and 100. > > This gets worse for the typical video-follows-audio setup. > > - Similarly, for a useful interactive conference, > participants have to > be able to interject and speak up immediately, with the video stream > following instantaneously. They cannot wait multiple > round-trip times as > they'll never get a word in edgewise. Thus, there is no masking of > ramp-up delays if you want a reasonable user experience. > > (Similar considerations apply to the now very popular push-to-talk > services. Trying to sell a service where the user has to > push, wait and > then talk does not seem like a winning proposition.) > > Masking is also rather tricky for two-party audio. There was a long > discussion in the SIP working group on this topic a few years ago, > leading to fairly elaborate hand-offs between reservation and session > signaling to minimize the post-pickup delay. As soon as I hit the > 'accept call' button, I need to be able to say 'hello' and be > heard by > the other side. The only masking opportunity is to start > sending audio > data 'to warm up the line' while the phone is ringing, adding more > bandwidth consumption for the large number of calls that > don't succeed. > At $4/MB for mobile voice data, this is unlikely to be > popular. (Typical > ring-to-answer delays are about 20 seconds; average call > durations for > mobile are probably three minutes, so this immediately adds about 10% > overhead, not counting the 60% or so of calls that fail over to > voicemail after 30 seconds.) > > I believe that there now is a suggested initial TCP windows > size > 1. Is > this correct? (If you figure a maximum acceptable network > delay of 100 > ms and a typical audio/video packet spacing of 50 ms, you would be > sending about 4 packets per RTT.) > > > Henning > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 15:28:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03735 for ; Wed, 3 Dec 2003 15:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdbO-0001lv-Hp for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 15:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KS21j006809 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 15:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdbN-0001kv-4K; Wed, 03 Dec 2003 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdaV-0001iX-9F for avt@optimus.ietf.org; Wed, 03 Dec 2003 15:27:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03481; Wed, 3 Dec 2003 15:26:51 -0500 (EST) Message-Id: <200312032026.PAA03481@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Dec 2003 15:26:51 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-ilbc-codec-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --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 : Internet Low Bit Rate Codec Author(s) : S. Andersen Filename : draft-ietf-avt-ilbc-codec-04.txt Pages : 175 Date : 2003-12-3 This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ilbc-codec-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-ilbc-codec-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: <2003-12-3152450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ilbc-codec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ilbc-codec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3152450.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 3 16:03:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06364 for ; Wed, 3 Dec 2003 16:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe9P-0004Jm-2z for avt-archive@odin.ietf.org; Wed, 03 Dec 2003 16:03:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3L3B5G016597 for avt-archive@odin.ietf.org; Wed, 3 Dec 2003 16:03:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe9F-0004Iz-73; Wed, 03 Dec 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe8H-0004Hl-DM for avt@optimus.ietf.org; Wed, 03 Dec 2003 16:02:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06216 for ; Wed, 3 Dec 2003 16:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARe8F-0000bg-00 for avt@ietf.org; Wed, 03 Dec 2003 16:01:59 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1ARe8E-0000bZ-00 for avt@ietf.org; Wed, 03 Dec 2003 16:01:58 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hB3L1qBQ012161; Wed, 3 Dec 2003 16:01:52 -0500 Message-ID: <011901c3b9e0$af81ad30$0401a8c0@berlin> From: "Paul E. Jones" To: "Tom Taylor" , "Arnoud van Wijk" Cc: , , , References: <000201c3b9bd$451e7f90$0300a8c0@solstice> <3FCE294A.20008@nortelnetworks.com> Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 Date: Wed, 3 Dec 2003 16:01:52 -0500 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom, I don't think we can say that North American GWs only speak Baudot. We must allow a V.21 user to call home to England, for example. Your point about the use of RFC 2833 for start-up messages is valid and is likely to occur between two gateways, as they would have negotiated the use of certain RFC 2833 tones and event messages. Such description falls into the scope of ITU-T V.ToIP. However, if a gateway happened to terminate to a Pocket PC, for example, no such tones would be negotiated or used. The gateway could either "eat" those tones or assume it's a textphone device. The behavior needs to be specified somewhere... perhaps also in V.ToIP? In any case, I think we're in agreement that RFC 2833 should not be used as a text transport mechanism. It might be used as part of start-up exchanges before it can be determined that the calling/called device is a modem, fax, or TTY device. GW-GW calls have slightly special requirements that IP phones do not have. Paul ----- Original Message ----- From: "Tom Taylor" To: "Arnoud van Wijk" Cc: "'Paul E. Jones'" ; ; ; ; Sent: Wednesday, December 03, 2003 1:19 PM Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 > OK, so in North America the gateway always emulates a Baudot terminal. > That means it won't be possible to negotiate alternating text and voice > with a V.18 terminal. I imagine Gunnar's bitter response to that one is > that nobody is making V.18 terminals anyway. > > Arnoud van Wijk wrote: > > > I think the question we need answered is: > > " Do we need to transport real-timing streaming text (aka Interactive Text) > > through PSTNs with RFC 2833 (a beefed up version of it)?" > > > > For Interactive Texting, gateways it will be necessary to allow backward > > compatibility with analogue textphones. Transcoding from T.140/RTP into the > > local legacy textphone protocol. For America it is then Boudot. > > All that the gateway has to do is simply connect to a PSTN using Boudot over > > the voice channel. Every PSTN connects with an Interactive Text gateway. And > > that IT gateway does the transcoding, so that the PSTN sees it as a voice > > channel as it is done today. > > > > There is then no RFC 2833 involved for the Interactive Texting. > > > > Thus when we get 2 PSTN's that are linked together over IP for a voice call, > > then is it much easier to send the text as RFC 2793. > > So, the only requirement is then that every PSTN must have a means to > > transcode RFC 2793 into local analogue text telephony (directly or via an IT > > gateway). > > > > I want to have clarity on this before starting to complicate matters even > > more. Analogue text telephony is a dying beast. And my goal is to kill it as > > fast as possible without any problems. > > > > Greetz > > > > Arnoud > > > > Drs. Arnoud A. T. van Wijk > > Viataal > > Research & Development > > Afdeling RDS > > Theerestraat 42 > > 5271 GD Sint-Michielsgestel > > The Netherlands. > > Mobile: +31651921948 > > International text telephone: +31735588408 > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 03:49:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16385 for ; Thu, 4 Dec 2003 03:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpAc-0008WA-Un for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 03:49:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB48nARM032733 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 03:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpAU-0008Ut-Tt; Thu, 04 Dec 2003 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARlkn-00076r-TW for avt@optimus.ietf.org; Thu, 04 Dec 2003 00:10:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28261 for ; Thu, 4 Dec 2003 00:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARlkl-000239-00 for avt@ietf.org; Thu, 04 Dec 2003 00:10:15 -0500 Received: from mail.ureach.com ([63.150.151.36] helo=ureach.com) by ietf-mx with esmtp (Exim 4.12) id 1ARlkk-000236-00 for avt@ietf.org; Thu, 04 Dec 2003 00:10:14 -0500 Received: from www20.ureach.com (www20.ureach.com [172.16.2.48]) by ureach.com (8.12.9/8.12.9) with ESMTP id hB45AGqV019448 for ; Thu, 4 Dec 2003 00:10:16 -0500 Received: (from nobody@localhost) by www20.ureach.com (8.9.1/8.9.1) id AAA19311; Thu, 4 Dec 2003 00:10:15 -0500 Date: Thu, 4 Dec 2003 00:10:15 -0500 Message-Id: <200312040510.AAA19311@www20.ureach.com> Received: from [129.107.37.181] by www20.ureach.com via HTTP; Thu, 04 Dec 2003 05:10:15 GMT To: avt@ietf.org From: Badri Natarajan Reply-to: Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-vsuite-type: e Content-Transfer-Encoding: 7bit Subject: [AVT] Mixers, and echo cancellation Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, Have a query about RTP mixing, and echo cancellation/prevention in the mixed stream during playback. Am currently considering a problem of payload identification/separation in conferences, where multiple speakers are active at an instant of time. To elaborate, the output of a mixer generally does not have any input stream specific information(apart from the SSRC that it carries as the CSRC).It appears to me that the only means of preventing an echo during playback would be: a.) The input stream(s) are buffered at the mixer and subtracted out from the mixed stream, thereby creating N+1 streams, where N is the number of active speakers. b.) The input streams are buffered at the endpoints (or at a different mixer in the case of cascaded mixers) and are subtracted out from the mixed stream that comes back.In the event of using cascaded mixers, we "might" generate lesser number of streams than option (a). However,in case (b), it would be necessary to know which stream, from the set of mixed streams that comes back for playback is to be used for the subtraction. Again it appears to me that, the only way it could be done, is by tagging a header extension to the stream, buffering it at the endpoint, create a mixed stream with the same header extension and then subtracting it out before playback, by comparing the extensions. Needless to say, the scheme is complex and has slim chances of working , considering network delays, the fact that all endpoints (or mixers in the case of cascaded mixers )might need to be sync'ed, and that the header extension would have a high overhead. Just wanted to know if anybody else has considered this problem, and if you would you be aware of any other mechanism that would identify a stream in a mixed stream? (--- Or is it that I am missing something ??) Also this brings me to my next question -- is it possible that in some fashion, a set of cascaded mixers could be synchronized so that there would be just one timing trigger that could signal the start of mixing operation at all mixers? Would be glad if someone could comment on my queries, Thanks in advance, B. ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 03:49:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16400 for ; Thu, 4 Dec 2003 03:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpAc-0008WB-V1 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 03:49:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB48nAjM032732 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 03:49:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARpAT-0008Uc-PG; Thu, 04 Dec 2003 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaAy-0007se-Kd for avt@optimus.ietf.org; Wed, 03 Dec 2003 11:48:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23033 for ; Wed, 3 Dec 2003 11:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARaAx-0004Bh-00 for avt@ietf.org; Wed, 03 Dec 2003 11:48:31 -0500 Received: from [81.171.101.3] (helo=smtp.eweka.nl) by ietf-mx with esmtp (Exim 4.12) id 1ARaAw-0004Bd-00 for avt@ietf.org; Wed, 03 Dec 2003 11:48:30 -0500 Received: from solstice (ew-dsl-81-171-0-31.eweka.nl [81.171.0.31]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id hB3H2wtR020911; Wed, 3 Dec 2003 17:03:03 GMT (envelope-from a.vwijk@viataal.nl) From: "Arnoud van Wijk" To: "'Tom Taylor'" , "'Paul E. Jones'" Cc: , , , Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833 Date: Wed, 3 Dec 2003 17:48:23 +0100 Message-ID: <000201c3b9bd$451e7f90$0300a8c0@solstice> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3FCE07F7.7040007@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think the question we need answered is: " Do we need to transport real-timing streaming text (aka Interactive = Text) through PSTNs with RFC 2833 (a beefed up version of it)?" For Interactive Texting, gateways it will be necessary to allow backward compatibility with analogue textphones. Transcoding from T.140/RTP into = the local legacy textphone protocol. For America it is then Boudot. All that the gateway has to do is simply connect to a PSTN using Boudot = over the voice channel. Every PSTN connects with an Interactive Text gateway. = And that IT gateway does the transcoding, so that the PSTN sees it as a = voice channel as it is done today. There is then no RFC 2833 involved for the Interactive Texting. Thus when we get 2 PSTN's that are linked together over IP for a voice = call, then is it much easier to send the text as RFC 2793. So, the only requirement is then that every PSTN must have a means to transcode RFC 2793 into local analogue text telephony (directly or via = an IT gateway). I want to have clarity on this before starting to complicate matters = even more. Analogue text telephony is a dying beast. And my goal is to kill = it as fast as possible without any problems. Greetz Arnoud Drs. Arnoud A. T. van Wijk=20 Viataal=20 Research & Development=20 Afdeling RDS=20 Theerestraat 42=20 5271 GD Sint-Michielsgestel=20 The Netherlands.=20 Mobile: +31651921948=20 International text telephone: +31735588408=20 -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com]=20 Sent: woensdag 3 december 2003 16:58 To: Paul E. Jones Cc: A vWijk; avt@ietf.org; gunnar.hellstrom@omnitor.se; = toip@snowshore.com; gv@trace.wisc.edu Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 The existing events in 2833 have to do primarily with startup. I have=20 to ask how the TOIP people see startup negotiation working without 2833=20 support. You still have to deal with V.8 or V.8bis in the more advanced = terminals. There is the fact that two V.18 terminals in conversation phase use=20 V.21, and V.21 events are included in the 2833 repertoire. This means=20 that telephone events could be used during conversation phase in some=20 cases. However, the basic discussion is over the set of events needed=20 to achieve transition to conversation phase successfully. Turning to the conversational phase, I do not see how the use of RFC=20 2793 between gateways in place of the various alternatives (G.711 VBD,=20 V.150.1 modem relay, the tones payload type, V.21 or other events) will=20 affect the user experience. I assume the reason this is desired is to=20 simplify the transition to packet-mode terminals. The problem here is that gateways have to handle a wide variety of=20 traffic, not just text. This makes more generic approaches like V.150.1 = for voice-band data simpler to implement, so I see some vendors making=20 that choice. Obviously, if packet terminals require RFC 2793 and=20 gateways cannot handle it, deployment of these gateways is limited to=20 bridging of PSTN segments. Given that this application still represents = a substantial market segment, we should probably add the 2833 events=20 needed to handle it properly. Paul E. Jones wrote: > Arnoud, >=20 > RFC 2833 can be used to convey tone information (frequencies and durations), > as well as tone events. It's not restricted to DTMF. >=20 > RFC 2833 could potentially be used as an alternative to RFC 2793. A gateway > or IP phone, for example, could simply examine the tones and convey = those as > "descriptions" (either frequency and duration information or event = codes) > over an IP network. The other end could then receive those = descriptions and > reproduce the tones. They would not have to understand the underlying > textphone protocol. >=20 > The problem with RFC 2833, as I see it, is that it stands at odds with = the > desire of folks on the ToIP mailing list to try to remove textphone > signaling from the IP network. There has been a strong desire = expressed to > terminate that textphone signaling at the gateway and only use text on = the > IP network. Doing that, arguably, would make interfacing with = IP-based IVR > systems, IP-based voice/text-mail systems, or other IP-based systems = much > easier. I say "arguably" because some have suggested to me that it's = very > simple to write software that understand the textphone signals = received in > RFC 2833 packets... though I personally think it puts an unfortunate burden > on a Pocket PC, for example. >=20 > To this point, neither the ITU nor the IETF has considered RFC 2833 as = an > option or alternative to RFC 2793. I think this is probably an = important > topic that we should take up immediately, as both bodies are forging = ahead > with plans based on RFC 2793 only. >=20 > Paul >=20 > ----- Original Message -----=20 > From: "A vWijk" > To: ; ; ; > ; > Sent: Tuesday, December 02, 2003 7:45 AM > Subject: Betr.: FW: [AVT] Missing events in RFC 2833 >=20 >=20 >=20 >>Gunnar, >>why is this desirable? >> >>We will have T.140 over RTP and in some cases over TCP/IP. >>Why the tones? >> >>Or am I mixing things up again? RFC2833 is for DTMF signalling? >> >>greetz >> >>Arnoud >> >>Drs. Arnoud A. T. van Wijk >>Viataal >>Research & Development >>Afdeling RDS >>Theerestraat 42 >>5271 GD Sint-Michielsgestel >>The Netherlands. >>Mobile: +31651921948 >>International text telephone: +31735588408 >> >> >>>>>"Gunnar Hellstrom" 01-12-03 23:20 >>> >> >>Below, Tom Taylor asks if there is any interest to complete the = textphone >>related tone events in RFC2833 so that all V.18 submodes can be >=20 > transported >=20 >>with RFC2833. >> >>We have to verify that we have satisfying detection and transport = methods >=20 > in >=20 >>RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we = can >>leave RFC2833 half done for text transport. >> >>I would like to do so, but then the market forces must be strong = enough to >>make RFC2793 and textphone detection commonplace. >> >>Using RFC2833 will place a task similar to V.18 logic on the IP = endpoint, >>but with less exact information than the native V.18 has. We have no >>analysis if that task is realistic, nor if it is likely to be = implemented >=20 > by >=20 >>IP endpoint developers. >> >>( The missing events for complete text transport are probably: >>V.21 data in lo channel at 110 bits/s >>Bell 103 hi channel data at 300 bits/s >>Bell 103 lo channel data at 300 bits/s >>V.23 data at 1200 bits/s >>V.23 data at 75 bits/s >>Baudot data at 45.45 bits/s >>Baudot data at 50 bits/s >> >>(assuming that V.8 signals and V.21 at 300 bits/s in both directions = and >>DTMF are covered ) >> >>Gunnar >> >>------------------------------------------- >>Gunnar Hellstrom >>Omnitor AB >>Renathvagen 2 >>SE 121 37 Johanneshov >>SWEDEN >>+46 8 556 002 03 >>Mob: +46 708 204 288 >>www.omnitor.se >>Gunnar.Hellstrom@Omnitor.se >>-------------------------------------------- >> >> >>-----Original Message----- >>From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Tom >>Taylor >>Sent: Monday, December 01, 2003 5:37 PM >>To: avt@ietf.org >>Subject: [AVT] Missing events in RFC 2833 >> >> >>I'm finding it a little difficult to see how some of the applications >>supported by RFC 2833 work without a few more events. Here are some >>examples: >> >>1. V.18 text telephones interwork with a number of other text = telephone >>types. The only event defined specifically for V.18 operation seems >>rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone. >>There don't seem to be any events for Baudot or V.23 or for Bell 103 = in >>calling mode. >> >>2. Signalling System No. 5 has two sets of signals: line signals, = which >>are tones controlling trunk state, and register signals, which convey >>digits with some supporting information. There is a timing constraint >>that register signalling must begin within 80 +/- 20 ms of the end of >>the "seize" line signal. Yet no event is defined for "seize", only = for >>the register signals. It's a little hard to see how the receiving >>gateway can propagate KPx (the initial register signal) on time if it >>doesn't know that "seize" was playing, even if the sending end can >>recognize and report the start of KPx within the 20 ms tolerance. As = I >>see it, the present set of events is useful only to transfer the >>register events from one gateway to another which will report them to >>call control rather than propagating them as tones. >> >>These missing events raise the issue of whether proposals to add = events >>to RFC 2833 should be backed up by requirements documents describing >>their use. I have been adding brief application descriptions in my >>rewrite of 2833bis, as justification for the normative text which I = have >>also been adding. (Basically just obvious stuff, missing the first = time >>around and highlighted by Flemming's comments earlier this year.) I = am >>hoping that this additional information prompts a critical review of = the >>current set of 2833/2833bis events, with a view to rounding them out = as >>necessary to make applications work well. >> >>Tom Taylor >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt >> >> >>- >>This list is maintained by Snowshore Networks - = http://www.snowshore.com >>All comments on this list are the comments of the message originators = and >>Snowshore is not to be held responsible for any actions or comments = found >>on this list. The archives for this list can be found at >>http://flyingfox.snowshore.com/toip_archive/maillist.html >> >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 05:02:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18203 for ; Thu, 4 Dec 2003 05:02:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqJH-0002sk-F9 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 05:02:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4A2Bdw011035 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 05:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqJ9-0002oq-DA; Thu, 04 Dec 2003 05:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARqIX-0002oN-VT for avt@optimus.ietf.org; Thu, 04 Dec 2003 05:01:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18174 for ; Thu, 4 Dec 2003 05:01:09 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARqIU-0005VC-00 for avt@ietf.org; Thu, 04 Dec 2003 05:01:22 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ARqIU-0005V8-00 for avt@ietf.org; Thu, 04 Dec 2003 05:01:22 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id CBEC86AFA8; Thu, 4 Dec 2003 11:01:17 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 89E3219C4D; Thu, 4 Dec 2003 11:01:16 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 79E8819C46; Thu, 4 Dec 2003 11:01:15 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id LAA07111; Thu, 4 Dec 2003 11:01:14 +0100 (MET) Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? To: "Rosen, Brian" Cc: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 4 Dec 2003 10:58:19 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 04/12/2003 11:02:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Rosan you wrote: >I'm dimly aware of what Philippe is talking about, but I don't >think it does what the first paragraph above describes today. have a look at things like: http://www.nextream-online.com/nextream/documents/pdf/WP%20FLEXTREAM.pdf the type of rate change these things do is pretty flexible, they actually change the rate several times *inside one video frame* and the range of changes can be pretty large. quality is "tunable" and .... well just switch on your TV and look ! regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 08:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24748 for ; Thu, 4 Dec 2003 08:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARteI-0007cQ-Uz for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 08:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Da6N8029285 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 08:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARteD-0007bV-Kt; Thu, 04 Dec 2003 08:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARtdZ-0007Tj-Ft for avt@optimus.ietf.org; Thu, 04 Dec 2003 08:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24711 for ; Thu, 4 Dec 2003 08:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARtdY-0001DN-00 for avt@ietf.org; Thu, 04 Dec 2003 08:35:20 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1ARtdX-0001DK-00 for avt@ietf.org; Thu, 04 Dec 2003 08:35:19 -0500 Received: from mcomreyj1 ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 14:34:58 +0100 Reply-To: From: =?iso-8859-1?Q?Jos=E9_Rey?= To: Cc: "Colin Perkins \(E-mail\)" , "David Leon \(E-mail\)" , "Viktor Varsa \(E-mail\)" , "Magnus Westerlund \(E-mail\)" , Subject: RE: [AVT] Retransmission draft Date: Thu, 4 Dec 2003 14:34:56 +0100 Message-ID: <00a301c3ba6b$691c5f80$05640a0a@panasonic.de> 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 CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-OriginalArrivalTime: 04 Dec 2003 13:34:58.0690 (UTC) FILETIME=[6944F620:01C3BA6B] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Colin, all, in the past weeks I had some intensive internal discussions on the matter of the potential IPRs on the RTP retransmission draft. As a WG participant I perfectly understand and respect the comments and interests expressed by you and others of the AVT group. In order to keep the good working spirit in AVT it is my strong intention to adress these comments in the best possible way by taking the interests of all parties involved in this work into account. Matsushita has published an IPR statement that it is prepared to grant a license on reasonable, nondiscriminatory terms and conditions (in accordance with paragraph 10.3.3 of the RFC 2026) on any part that is included into the RTP retransmission standard and that Matsushita possibly holds IPRs on. Providing a royality-free license to open-source developers will unfortunately lead to a situation where Matsushita will lose any rights on their IPRs in most cases. Taking into account the work and effort (we started with the retransmission draft in AVT more than 2.5 years ago) we spent into this draft, this is not acceptable for Matsushita. On the other hand, we believe that the situation for open-source developers is quite easy to solve by other means. First of all they are not in any way 'forced' to implement RTP retransmission. It is just an optional repair mechanism for the RTP protocol, as described in RFC2354. In order to solve the problems that RTP retransmission tries to solve, there are other solutions available from the AVT group which are not encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This makes the implementation of the RTP retransmission solution purely optional and easily avoidable to everyone. In order to make this situation clear to anybody who reads the RTP retransmission draft, we suggest to add a paragraph at the very beginning of the draft. This paragraph will make implementors aware of the situation that the solution described in this draft is possibly encumbered by IPRs. Furthermore it will point implementors to non-IPR-encumbered solutions as above, which may perfectly be used instead of RTP retransmission. Finally and FYI: 3GPP is aware of the IPR situation of the RTP retransmission draft and has accepted the solution provided in draft-ietf-avt-rtp-retransmission-09.txt as working assumption in their packet based streaming service (PSS). The acceptance is conditional on the fact that the draft will proceed on standards track and an RFC is available before the release of the PSS specifications, (expected for March 2004). Looking forward to your comments, Jose > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > Perkins > Sent: Tuesday, October 21, 2003 6:58 PM > To: rey@panasonic.de > Cc: avt@ietf.org; 'Magnus Westerlund' > Subject: Re: [AVT] Retransmission draft > > > On Tuesday, Oct 21, 2003, at 12:54 Europe/London, Jose Rey wrote: > ... > > In previous emails we have been asked to explain our patent > > application and > > we > > informed AVT that the patent application itself specifies a transport > > method > > using the RTP protocol where two sequence numbers are used: one to > > specifiy > > the transmission order (=RTP SN) and the other one defining the > > reprodution > > order, which in the draft corresponds with the OSN (original sequence > > number). We also stated that it is not possible to implement the > > protocol > > without infringing on the patent. > > So far we have not received any more questions on the patent, but are > > happy > > to provide them in case needed. > > > > On the issue of how to proceed with this RTP retransmission draft some > > opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson and > > John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it as > > Informational if the patent rights are held while Magnus and > > Lars-Erik have suggested to proceed with the document as a Proposed > > Standard (as we understand from the emails on from 22.09.03 and > > 09.09.03). > > > > Taking all the above into account and considering that > > independent of the patent situation this work is intended to be > > included in > > the next release of 3GPP, we would like to ask the group to proceed > > with the > > draft on standards track. > > > > cheers, > > Jose > > [takes working group chair hat off] > > 3GPP is only one forum which uses IETF standards, and one where dealing > with IPR issues is commonplace. Having patented standards is more of an > issue for open source developers, who are often excluded by the > licensing terms. Would Matsushita be willing to clarify if the > "reasonable, nondiscriminatory" terms allow open source implementations > to use the retransmission format (this will probably require a > Royalty-Free license)? > > [puts working group chair hat on again] > > -- > Colin Perkins > http://csperkins.org/ > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 09:13:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26293 for ; Thu, 4 Dec 2003 09:13:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuE6-0001SG-BJ for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 09:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4ED6C5005593 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 09:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuE1-0001Rb-52; Thu, 04 Dec 2003 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuD8-0001NP-QS for avt@optimus.ietf.org; Thu, 04 Dec 2003 09:12:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26267 for ; Thu, 4 Dec 2003 09:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuD7-0001t2-00 for avt@ietf.org; Thu, 04 Dec 2003 09:12:05 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ARuD6-0001sC-00 for avt@ietf.org; Thu, 04 Dec 2003 09:12:04 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14446; Thu, 4 Dec 2003 09:09:47 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13875; Thu, 4 Dec 2003 09:08:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 09:08:59 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6176@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'philippe.gentric@philips.com'" Cc: avt@ietf.org Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Thu, 4 Dec 2003 09:08:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I think this proves my point. >I have never heard/seen a codec that can dynamically, in real time, >vary its rate in response to network conditions in a way that >is not objectionable to the user. This product cannot dynamically vary its rate in response to network conditions. It appears to vary rates of multiple streams to keep the aggregate within a fixed rate, which indeed, as you say, may portend the possibility of dynamically varying the rate in response to network conditions. The algorithm, as described, probably is not suitable for interactive streams, because of delay considerations, as I suggested might be a concern. If we had a reasonable amount of experience using techniques such as this one in real networks, then I might have to change my opinion. As it stands, this is pretty far from what I would need to change our product, or to get me to believe that any substantial part of the VoIP market would deploy such algorithms any time soon. If you and Eddie want to keep slogging on DCCP for this kind of codec, please continue, but I'm still in the skeptical stage. Brian > -----Original Message----- > From: philippe.gentric@philips.com > [mailto:philippe.gentric@philips.com] > Sent: Thursday, December 04, 2003 4:58 AM > To: Rosen, Brian > Cc: avt@ietf.org > Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > > Rosan you wrote: > > >I'm dimly aware of what Philippe is talking about, but I don't > >think it does what the first paragraph above describes today. > > have a look at things like: > > http://www.nextream-online.com/nextream/documents/pdf/WP%20FLE XTREAM.pdf the type of rate change these things do is pretty flexible, they actually change the rate several times *inside one video frame* and the range of changes can be pretty large. quality is "tunable" and .... well just switch on your TV and look ! regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 09:47:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27624 for ; Thu, 4 Dec 2003 09:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARul7-0003BR-Gf for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 09:47:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4ElD9j012189 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 09:47:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuku-00033X-Qg; Thu, 04 Dec 2003 09:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARukj-000333-3b for avt@optimus.ietf.org; Thu, 04 Dec 2003 09:46:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27578 for ; Thu, 4 Dec 2003 09:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARukh-0002MG-00 for avt@ietf.org; Thu, 04 Dec 2003 09:46:47 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1ARukg-0002Ks-00 for avt@ietf.org; Thu, 04 Dec 2003 09:46:46 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB4EkDI04297 for ; Thu, 4 Dec 2003 09:46:13 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLSTF2V0; Thu, 4 Dec 2003 09:46:13 -0500 Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM9NZ; Thu, 4 Dec 2003 09:46:13 -0500 Message-ID: <3FCF48B3.5070604@nortelnetworks.com> Date: Thu, 04 Dec 2003 09:46:11 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] RFC 2833 tones payload and modulation Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The RFC 2833 tones payload type provides for both summation of frequencies and modulation by another frequency. However, the modulation is missing a piece of information, because modulation of tones in practice isn't just a matter of multiplication. My particular example is the V.8 ANSam tone. This is modulated by a 15 Hz envelope. However, the specification of that envelope says that the amplitude of the total ANSam waveform varies from a minimum of 80% of the nominal value to 120%. Obviously the payload description has been long established and it would be difficult to add the missing information now. I see two alternatives: -- Recommend that modulation be applied the way it is for ANSam (i.e. with precisely the same 80% and 120% limits). I'd justify this on the grounds that ANSam will be the most common case. The other cases are tones intended for human consumption, so my second justifying argument is that using the ANSam boundaries might be close enough to what the tones have to sound like. -- Alternatively, recommend that the receiving gateway be aware of the nature of any tone presented with modulation, so it can construct the right envelope. Any opinions, or is this something no one has implemented anyway? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 10:01:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28345 for ; Thu, 4 Dec 2003 10:01:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuyY-0003wG-68 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 10:01:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4F166m015138 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 10:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuyU-0003ry-6j; Thu, 04 Dec 2003 10:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuxj-0003hx-Un for avt@optimus.ietf.org; Thu, 04 Dec 2003 10:00:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28261 for ; Thu, 4 Dec 2003 09:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuxh-0002b5-00 for avt@ietf.org; Thu, 04 Dec 2003 10:00:13 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ARuxg-0002aT-00 for avt@ietf.org; Thu, 04 Dec 2003 10:00:12 -0500 Received: from spaatz ([130.209.242.185]:2008 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ARuwm-0002S5-00; Thu, 04 Dec 2003 14:59:16 +0000 Date: Thu, 4 Dec 2003 14:59:24 +0000 From: Colin Perkins To: Cc: avt@ietf.org Subject: Re: [AVT] Retransmission draft Message-Id: <20031204145924.23d2dc61.csp@csperkins.org> In-Reply-To: <00a301c3ba6b$691c5f80$05640a0a@panasonic.de> References: <00a301c3ba6b$691c5f80$05640a0a@panasonic.de> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jos=E9, [cc list trimmed] --> Jos=E9 Rey writes: > in the past weeks I had some intensive internal discussions on the matter > of the potential IPRs on the RTP retransmission draft. As a WG > participant I perfectly understand and respect the comments and interests > expressed by you and others of the AVT group. In order to keep the good > working spirit in AVT it is my strong intention to adress these comments > in the best possible way by taking the interests of all parties involved > in this work into account. >=20 > Matsushita has published an IPR statement that it is prepared to grant a > license on reasonable, nondiscriminatory terms and conditions (in > accordance with paragraph 10.3.3 of the RFC 2026) on any part that is > included into the RTP retransmission standard and that Matsushita > possibly holds IPRs on. Providing a royality-free license to open-source > developers will unfortunately lead to a situation where Matsushita will > lose any rights on their IPRs in most cases. Taking into account the work > and effort (we started with the retransmission draft in AVT more than 2.5 > years ago) we spent into this draft, this is not acceptable for > Matsushita. >=20 > On the other hand, we believe that the situation for open-source > developers is quite easy to solve by other means. First of all they are > not in any way'forced' to implement RTP retransmission. It is just an > optional repair mechanism for the RTP protocol, as described in RFC2354. > In order to solve the problems that RTP retransmission tries to solve, > there are other solutions available from the AVT group which are not > encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This > makes the implementation of the RTP retransmission solution purely > optional and easily avoidable to everyone. Provided it is clear that the mechanism is encumbered, yes. > In order to make this situation clear to anybody who reads the RTP > retransmission draft, we suggest to add a paragraph at the very beginning > of the draft. This paragraph will make implementors aware of the > situation that the solution described in this draft is possibly > encumbered by IPRs. Furthermore it will point implementors to > non-IPR-encumbered solutions as above, which may perfectly be used > instead of RTP retransmission. Without seeing the wording of this paragraph, I can't give a definitive answer, but that would largely address my concerns. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 10:21:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00289 for ; Thu, 4 Dec 2003 10:21:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvHs-0005S3-4x for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 10:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4FL4B4020949 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 10:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvHp-0005RH-Cp; Thu, 04 Dec 2003 10:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARvHT-0005QR-Fm for avt@optimus.ietf.org; Thu, 04 Dec 2003 10:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00282 for ; Thu, 4 Dec 2003 10:20:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARvHR-0002uy-00 for avt@ietf.org; Thu, 04 Dec 2003 10:20:37 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ARvHQ-0002uC-00 for avt@ietf.org; Thu, 04 Dec 2003 10:20:36 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB4FJrj00152; Thu, 4 Dec 2003 10:19:53 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLSTFJYZ; Thu, 4 Dec 2003 10:19:53 -0500 Received: from nortelnetworks.com (acart1hf.ca.nortel.com [47.129.129.223]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWM93P; Thu, 4 Dec 2003 10:19:53 -0500 Message-ID: <3FCF5098.6040902@nortelnetworks.com> Date: Thu, 04 Dec 2003 10:19:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Paul E. Jones" CC: Arnoud van Wijk , avt@ietf.org, gunnar.hellstrom@omnitor.se, toip@snowshore.com, gv@trace.wisc.edu Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 References: <000201c3b9bd$451e7f90$0300a8c0@solstice> <3FCE294A.20008@nortelnetworks.com> <011901c3b9e0$af81ad30$0401a8c0@berlin> In-Reply-To: <011901c3b9e0$af81ad30$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Based on this intervention, I would propose to add the list of events given by Gunnar to those already given in RFC 2833. Paul E. Jones wrote: > Tom, > > I don't think we can say that North American GWs only speak Baudot. We must > allow a V.21 user to call home to England, for example. Your point about > the use of RFC 2833 for start-up messages is valid and is likely to occur > between two gateways, as they would have negotiated the use of certain RFC > 2833 tones and event messages. Such description falls into the scope of > ITU-T V.ToIP. > > However, if a gateway happened to terminate to a Pocket PC, for example, no > such tones would be negotiated or used. The gateway could either "eat" > those tones or assume it's a textphone device. The behavior needs to be > specified somewhere... perhaps also in V.ToIP? > > In any case, I think we're in agreement that RFC 2833 should not be used as > a text transport mechanism. It might be used as part of start-up exchanges > before it can be determined that the calling/called device is a modem, fax, > or TTY device. GW-GW calls have slightly special requirements that IP > phones do not have. > > Paul > > ----- Original Message ----- > From: "Tom Taylor" > To: "Arnoud van Wijk" > Cc: "'Paul E. Jones'" ; ; > ; ; > Sent: Wednesday, December 03, 2003 1:19 PM > Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833 > > > >>OK, so in North America the gateway always emulates a Baudot terminal. >>That means it won't be possible to negotiate alternating text and voice >>with a V.18 terminal. I imagine Gunnar's bitter response to that one is >>that nobody is making V.18 terminals anyway. >> >>Arnoud van Wijk wrote: >> >> >>>I think the question we need answered is: >>>" Do we need to transport real-timing streaming text (aka Interactive > > Text) > >>>through PSTNs with RFC 2833 (a beefed up version of it)?" >>> >>>For Interactive Texting, gateways it will be necessary to allow backward >>>compatibility with analogue textphones. Transcoding from T.140/RTP into > > the > >>>local legacy textphone protocol. For America it is then Boudot. >>>All that the gateway has to do is simply connect to a PSTN using Boudot > > over > >>>the voice channel. Every PSTN connects with an Interactive Text gateway. > > And > >>>that IT gateway does the transcoding, so that the PSTN sees it as a > > voice > >>>channel as it is done today. >>> >>>There is then no RFC 2833 involved for the Interactive Texting. >>> >>>Thus when we get 2 PSTN's that are linked together over IP for a voice > > call, > >>>then is it much easier to send the text as RFC 2793. >>>So, the only requirement is then that every PSTN must have a means to >>>transcode RFC 2793 into local analogue text telephony (directly or via > > an IT > >>>gateway). >>> >>>I want to have clarity on this before starting to complicate matters > > even > >>>more. Analogue text telephony is a dying beast. And my goal is to kill > > it as > >>>fast as possible without any problems. >>> >>>Greetz >>> >>>Arnoud >>> >>>Drs. Arnoud A. T. van Wijk >>>Viataal >>>Research & Development >>>Afdeling RDS >>>Theerestraat 42 >>>5271 GD Sint-Michielsgestel >>>The Netherlands. >>>Mobile: +31651921948 >>>International text telephone: +31735588408 >> >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt >> > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 11:30:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03567 for ; Thu, 4 Dec 2003 11:30:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwMk-0000QR-BE for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 11:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4GUAh3001587 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 11:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwMc-0000Ob-Fs; Thu, 04 Dec 2003 11:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwMP-0000OD-CF for avt@optimus.ietf.org; Thu, 04 Dec 2003 11:29:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03528 for ; Thu, 4 Dec 2003 11:29:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARwMO-0004Ji-00 for avt@ietf.org; Thu, 04 Dec 2003 11:29:48 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ARwMN-0004JN-00 for avt@ietf.org; Thu, 04 Dec 2003 11:29:47 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB4GSv1m000309 for ; Thu, 4 Dec 2003 11:29:17 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 4 Dec 2003 11:28:47 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Dec 2003 11:28:47 -0500 Message-ID: From: "Phelan, Tom" To: "'Henning Schulzrinne'" Cc: avt@ietf.org Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Thu, 4 Dec 2003 11:28:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Henning, > I believe that there now is a suggested initial TCP windows > size > 1. Is > this correct? (If you figure a maximum acceptable network > delay of 100 > ms and a typical audio/video packet spacing of 50 ms, you would be > sending about 4 packets per RTT.) The current CCID3 draft (TFRC for DCCP) says the initial rate is 4 packets per RTT. This should pretty much eliminate slow start for speech audio. Your points about the value of silence suppression for non-multicast conferencing seem bang on target. I'll remember to keep that in mind. Tom Phelan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 11:53:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04164 for ; Thu, 4 Dec 2003 11:53:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwiu-0001eJ-4B for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 11:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Gr4Le006317 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 11:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwir-0001dF-2v; Thu, 04 Dec 2003 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARwie-0001ct-TA for avt@optimus.ietf.org; Thu, 04 Dec 2003 11:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04150 for ; Thu, 4 Dec 2003 11:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARwid-0004aP-00 for avt@ietf.org; Thu, 04 Dec 2003 11:52:47 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1ARwid-0004aM-00 for avt@ietf.org; Thu, 04 Dec 2003 11:52:47 -0500 Received: from mcomreyj1 ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 17:52:26 +0100 Reply-To: From: =?iso-8859-1?Q?Jos=E9_Rey?= To: "'Colin Perkins'" Cc: Subject: RE: [AVT] Retransmission draft Date: Thu, 4 Dec 2003 17:52:25 +0100 Message-ID: <00af01c3ba86$ff0a1260$05640a0a@panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20031204145924.23d2dc61.csp@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-OriginalArrivalTime: 04 Dec 2003 16:52:26.0626 (UTC) FILETIME=[FF308620:01C3BA86] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA04151 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, December 04, 2003 3:59 PM > To: rey@panasonic.de > Cc: avt@ietf.org > Subject: Re: [AVT] Retransmission draft > > > Jos=E9, > > [cc list trimmed] > > --> Jos=E9 Rey writes: > > in the past weeks I had some intensive internal discussions > on the matter > > of the potential IPRs on the RTP retransmission draft. As a WG > > participant I perfectly understand and respect the comments > and interests > > expressed by you and others of the AVT group. In order to > keep the good > > working spirit in AVT it is my strong intention to adress > these comments > > in the best possible way by taking the interests of all > parties involved > > in this work into account. > > > > Matsushita has published an IPR statement that it is > prepared to grant a > > license on reasonable, nondiscriminatory terms and conditions (in > > accordance with paragraph 10.3.3 of the RFC 2026) on any > part that is > > included into the RTP retransmission standard and that Matsushita > > possibly holds IPRs on. Providing a royality-free license > to open-source > > developers will unfortunately lead to a situation where > Matsushita will > > lose any rights on their IPRs in most cases. Taking into > account the work > > and effort (we started with the retransmission draft in AVT > more than 2.5 > > years ago) we spent into this draft, this is not acceptable for > > Matsushita. > > > > On the other hand, we believe that the situation for open-source > > developers is quite easy to solve by other means. First of > all they are > > not in any way'forced' to implement RTP retransmission. It > is just an > > optional repair mechanism for the RTP protocol, as > described in RFC2354. > > In order to solve the problems that RTP retransmission > tries to solve, > > there are other solutions available from the AVT group which are not > > encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This > > makes the implementation of the RTP retransmission solution purely > > optional and easily avoidable to everyone. > > Provided it is clear that the mechanism is encumbered, yes. > > > In order to make this situation clear to anybody who reads the RTP > > retransmission draft, we suggest to add a paragraph at the > very beginning > > of the draft. This paragraph will make implementors aware of the > > situation that the solution described in this draft is possibly > > encumbered by IPRs. Furthermore it will point implementors to > > non-IPR-encumbered solutions as above, which may perfectly be used > > instead of RTP retransmission. > > Without seeing the wording of this paragraph, I can't give a > definitive > answer, but that would largely address my concerns. > right, how about this: "This document provides an RTP packet retransmission mechanism for repair= of streaming media. The purpose of this paragraph is to make the reader awa= re that the retransmission mechanism described in this document may be encumbered by patent applications filed from Matsushita. For details on = the IPR statement, please visit the IETF IPR web page http://www.ietf.org/ietf/IPR. However, packet retransmission is not the only means for streaming client= s and servers to cope with packet losses. A detailed description of option= s for repair of streaming media is given in RFC2354. Therefore, implemente= rs of this protocol shall take into account that there are in fact other mechanisms, such as forward error correction (FEC) or packet interleaving that represent an alternative to solve the problems packet retransmission tries to solve. In particular RFC2733 and RFC2198 present FEC and redundant packet transmission schemes that might well fit to the needs of the implementer. " Jos=E9 > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 14:22:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09776 for ; Thu, 4 Dec 2003 14:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARz3M-0004II-79 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 14:22:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4JMKv8016502 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 14:22:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARz34-0004CE-Sq; Thu, 04 Dec 2003 14:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARyJg-0000xx-Es for avt@optimus.ietf.org; Thu, 04 Dec 2003 13:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06249 for ; Thu, 4 Dec 2003 12:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARxcG-0005XO-00 for avt@ietf.org; Thu, 04 Dec 2003 12:50:16 -0500 Received: from relay1.softcomca.com ([168.144.1.67]) by ietf-mx with esmtp (Exim 4.12) id 1ARxcF-0005WN-00 for avt@ietf.org; Thu, 04 Dec 2003 12:50:16 -0500 Received: from M2W071.mail2web.com ([168.144.251.180]) by relay1.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 12:49:31 -0500 Message-ID: <184670-220031244174931954@M2W071.mail2web.com> X-Priority: 3 Reply-To: vsathe@san.rr.com X-Originating-IP: 66.185.162.194 X-URL: http://mail2web.com/ From: "vsathe@san.rr.com" To: avt@ietf.org Subject: RE: [AVT] Retransmission draft Date: Thu, 4 Dec 2003 12:49:31 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 04 Dec 2003 17:49:31.0792 (UTC) FILETIME=[F8BF6100:01C3BA8E] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable With this disclaimer, I am now confused about the prespective with which I= should read this draft as a (potential) implementator=2E I understand that= Matsushita may have some IPR in this submission=2E But now are you saying that you really don't know why anyone should use this scheme? Would it be possible to give a scenario or two where the proposed mechanism may be superior to follow? What is the point in sending this off to IETF RFC track?=20 Thanks in advance for your explanation=2E=20 Vinay Sathe Multirate Systems right, how about this: "This document provides an RTP packet retransmission mechanism for repair = of streaming media=2E The purpose of this paragraph is to make the reader aw= are that the retransmission mechanism described in this document may be encumbered by patent applications filed from Matsushita=2E For details on= the IPR statement, please visit the IETF IPR web page http://www=2Eietf=2Eorg/ietf/IPR=2E However, packet retransmission is not the only means for streaming clients= and servers to cope with packet losses=2E A detailed description of optio= ns for repair of streaming media is given in RFC2354=2E Therefore, implement= ers of this protocol shall take into account that there are in fact other mechanisms, such as forward error correction (FEC) or packet interleaving that represent an alternative to solve the problems packet retransmission tries to solve=2E In particular RFC2733 and RFC2198 present FEC and redundant packet transmission schemes that might well fit to the needs of the implementer=2E " Jos=E9 -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 14:31:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10019 for ; Thu, 4 Dec 2003 14:31:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzBp-0004q6-WD for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 14:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4JV5sx018576 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 14:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzBm-0004oc-Cz; Thu, 04 Dec 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARzAw-0004nC-6I for avt@optimus.ietf.org; Thu, 04 Dec 2003 14:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09980 for ; Thu, 4 Dec 2003 14:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARzAt-00071U-00 for avt@ietf.org; Thu, 04 Dec 2003 14:30:07 -0500 Received: from ip72.usw232.dsl-acs2.sea.iinet.com ([209.20.232.72] helo=bels002.mediator.com) by ietf-mx with esmtp (Exim 4.12) id 1ARzAs-00071A-00 for avt@ietf.org; Thu, 04 Dec 2003 14:30:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Retransmission draft Date: Thu, 4 Dec 2003 11:29:33 -0800 Message-ID: <787ED0EC136B854DB341E7662D666CD66137E8@bels002.mediator.com> Thread-Topic: [AVT] Retransmission draft Thread-Index: AcO6a6ZTzAji8JnHQemfmg+OL7R9xAAML/yw From: "Gamze Seckin" To: , Cc: "Colin Perkins (E-mail)" , "David Leon (E-mail)" , "Viktor Varsa (E-mail)" , "Magnus Westerlund (E-mail)" , Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, A quick note on the comment with regards to 3GPP's decision on this = draft: It has not been yet accepted yet within 3gpp. It is still under = discussion. In the last 3gpp sa4 meeting various delegates raised a = concern about server complexity and delay issues with regards to the = protocol. It was said that the acceptance is conditional on concerns = being addressed in the next meeting.=20 thanks best regards, gamze seckin -----Original Message----- From: Jos=E9 Rey [mailto:rey@panasonic.de] Sent: Thursday, December 04, 2003 5:35 AM To: avt@ietf.org Cc: Colin Perkins (E-mail); David Leon (E-mail); Viktor Varsa (E-mail); Magnus Westerlund (E-mail); hakenberg@panasonic.de Subject: RE: [AVT] Retransmission draft Hi Colin, all, in the past weeks I had some intensive internal discussions on the = matter of the potential IPRs on the RTP retransmission draft. As a WG participant = I perfectly understand and respect the comments and interests expressed by = you and others of the AVT group. In order to keep the good working spirit in = AVT it is my strong intention to adress these comments in the best possible = way by taking the interests of all parties involved in this work into = account. Matsushita has published an IPR statement that it is prepared to grant a license on reasonable, nondiscriminatory terms and conditions (in = accordance with paragraph 10.3.3 of the RFC 2026) on any part that is included into the RTP retransmission standard and that Matsushita possibly holds IPRs = on. Providing a royality-free license to open-source developers will unfortunately lead to a situation where Matsushita will lose any rights = on their IPRs in most cases. Taking into account the work and effort (we started with the retransmission draft in AVT more than 2.5 years ago) we spent into this draft, this is not acceptable for Matsushita. On the other hand, we believe that the situation for open-source = developers is quite easy to solve by other means. First of all they are not in any = way 'forced' to implement RTP retransmission. It is just an optional repair mechanism for the RTP protocol, as described in RFC2354. In order to = solve the problems that RTP retransmission tries to solve, there are other solutions available from the AVT group which are not encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This makes the = implementation of the RTP retransmission solution purely optional and easily avoidable = to everyone. In order to make this situation clear to anybody who reads the RTP retransmission draft, we suggest to add a paragraph at the very = beginning of the draft. This paragraph will make implementors aware of the situation = that the solution described in this draft is possibly encumbered by IPRs. Furthermore it will point implementors to non-IPR-encumbered solutions = as above, which may perfectly be used instead of RTP retransmission. Finally and FYI: 3GPP is aware of the IPR situation of the RTP retransmission draft and has accepted the solution provided in draft-ietf-avt-rtp-retransmission-09.txt as working assumption in their packet based streaming service (PSS). The acceptance is conditional on = the fact that the draft will proceed on standards track and an RFC is = available before the release of the PSS specifications, (expected for March 2004). Looking forward to your comments, Jose > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin > Perkins > Sent: Tuesday, October 21, 2003 6:58 PM > To: rey@panasonic.de > Cc: avt@ietf.org; 'Magnus Westerlund' > Subject: Re: [AVT] Retransmission draft > > > On Tuesday, Oct 21, 2003, at 12:54 Europe/London, Jose Rey wrote: > ... > > In previous emails we have been asked to explain our patent > > application and > > we > > informed AVT that the patent application itself specifies a transport > > method > > using the RTP protocol where two sequence numbers are used: one to > > specifiy > > the transmission order (=3DRTP SN) and the other one defining the > > reprodution > > order, which in the draft corresponds with the OSN (original sequence > > number). We also stated that it is not possible to implement the > > protocol > > without infringing on the patent. > > So far we have not received any more questions on the patent, but are > > happy > > to provide them in case needed. > > > > On the issue of how to proceed with this RTP retransmission draft some > > opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson and > > John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it as > > Informational if the patent rights are held while Magnus and > > Lars-Erik have suggested to proceed with the document as a Proposed > > Standard (as we understand from the emails on from 22.09.03 and > > 09.09.03). > > > > Taking all the above into account and considering that > > independent of the patent situation this work is intended to be > > included in > > the next release of 3GPP, we would like to ask the group to proceed > > with the > > draft on standards track. > > > > cheers, > > Jose > > [takes working group chair hat off] > > 3GPP is only one forum which uses IETF standards, and one where dealing > with IPR issues is commonplace. Having patented standards is more of an > issue for open source developers, who are often excluded by the > licensing terms. Would Matsushita be willing to clarify if the > "reasonable, nondiscriminatory" terms allow open source implementations > to use the retransmission format (this will probably require a > Royalty-Free license)? > > [puts working group chair hat on again] > > -- > Colin Perkins > http://csperkins.org/ > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 22:16:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03340 for ; Thu, 4 Dec 2003 22:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS6Rz-0006nX-Gq for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 22:16:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB53GFUI026125 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 22:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS6Rl-0006li-ND; Thu, 04 Dec 2003 22:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS6RN-0006ku-KS for avt@optimus.ietf.org; Thu, 04 Dec 2003 22:15:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03299; Thu, 4 Dec 2003 22:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS6RK-0000DK-00; Thu, 04 Dec 2003 22:15:34 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1AS6RJ-0000DH-00; Thu, 04 Dec 2003 22:15:33 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB53FWsD034999; Thu, 4 Dec 2003 19:15:33 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312050315.hB53FWsD034999@coyote.icir.org> To: Qiaobing Xie cc: avt@ietf.org, dccp@ietf.org In-Reply-To: Message from Qiaobing Xie of "Wed, 03 Dec 2003 11:38:58 CST." <3FCE1FB1.950C93C7@motorola.com> Date: Thu, 04 Dec 2003 19:15:32 -0800 From: Eddie Kohler Subject: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I wish I could be as optimistic as you. I wonder if anyone on the list > has some numbers that can show what percentage of additional media data > will be injected into the network if codecs would stop doing silence > detection (motion detection for video). For the app Henning mentioned (multi-party, non-multicast conferencing), silence suppression is a huge win. (With 100 participants and silence suppression, you have 1-2 inbound streams' worth of data and 100 outbound streams' worth; without it, you have 50-100 inbound streams and 100 outbound streams.) On the other hand, say you have: - 100 Kb/s uplink - 100 person-to-person multimedia connections on the link - Each of which uses 2 Kb/s when not silent - and is silent 50% of the time - and 100 TCP flows on the link (which are coming and going). A back of the envelope analysis: (Comments welcome) 1. If the media flows use silence suppression but not congestion control, they will fit in the link on average, but crowd out the TCP flows. Useful work getting done: 100. (1 "Work" unit == 1 TCP flow achieving >= 500 b/s, OR one media flow achieving its preferred nonsilent rate [2 Kb/s].) 2. If the media flows use congestion control but not silence suppression, media and TCP will share the link, but each media flow is limited to approximately 1/4 its preferred nonsilent bandwidth. Useful work getting done: 125. 3. If the media flows use congestion control and send 1/2 rate filler data during silent periods, media and TCP will share the link, but each media flow is limited to approximately 1/3 its preferred nonsilent bandwidth. Useful work getting done: 133. *None* of these results are particularly attractive. What you really want is 150 units of work or something like it. But the first result is worst. The easiest way to get 150 work units is through bandwidth reservations, and thus QoS. QoS is also the only reasonable way to privilege the media traffic above TCP. Note that "all-or-nothing" media apps, which would either send at their preferred rate or not at all, get a tough break; given the TCP flows, the fair rate is < 1 Kb/s, too low for any media apps to send. (And thus leading to 100 work units.) I'm not sure what the right solution is. There might not be a solution apart from QoS/bandwidth reservations. > Fundamentally, I am concerned that this DCCP > "app-who-sends-more-will-get-rewarded" feature will be taken advantage of > in the wrong way (the draft that starts this discussion is the first > attempt for this, but it won't be the last). > > If this behavior of "sending filler data when no real data to send" > becomes a recommended practice for media-over-DCCP (as you and Tom seem > to suggest), what would stop the same recommendation be made for app over > TCP? For an app over a long lived TCP connection, the sender can also > benefit from sending "filler data" to keep the pipe from collapsing, so > as to avoid the penalty of going through another slow start when it has > real data to send next time. But I think this is hardly something that > should be recommended for TCP based apps. Why should it be more > acceptable for DCCP then? It is a tough tradeoff. * Sending filler data is clearly bad. * On the other hand, the Internet works not because we judge whether the *contents* of a data stream are worthwhile, but because we ensure that data streams are friendly to one another. They do not continue transmitting at high rates in the face of congestion. They do not cause congestion collapse. Sending filler data *limited by congestion control* won't cause congestion collapse. The app will not send *more* filler data after a loss event; it will send less. My feeling has therefore been that filler data *limited by congestion control* is better for the Internet than non-congestion-controlled media traffic. But it is tough. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 4 23:19:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05079 for ; Thu, 4 Dec 2003 23:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS7R0-0000L8-U8 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 23:19:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB54JIaY001251 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 23:19:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS7Qj-0000JY-WD; Thu, 04 Dec 2003 23:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS7Q5-0000JJ-SA for avt@optimus.ietf.org; Thu, 04 Dec 2003 23:18:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05070 for ; Thu, 4 Dec 2003 23:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS7Q4-00015e-00 for avt@ietf.org; Thu, 04 Dec 2003 23:18:20 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AS7Q3-00015b-00 for avt@ietf.org; Thu, 04 Dec 2003 23:18:19 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hB54IJTA022057 for ; Thu, 4 Dec 2003 20:18:19 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hB54IJC7022056 for avt@ietf.org; Thu, 4 Dec 2003 20:18:19 -0800 (PST) Date: Thu, 4 Dec 2003 20:18:19 -0800 (PST) From: John Lazzaro Message-Id: <200312050418.hB54IJC7022056@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: Retransmission draft Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Jose Rey writes: > > Providing a royality-free license to open-source developers will > unfortunately lead to a situation where Matsushita will lose any > rights on their IPRs in most cases. Taking into account the work and > effort (we started with the retransmission draft in AVT more than 2.5 > years ago) we spent into this draft, this is not acceptable for > Matsushita. And likewise, an AVT standards-track RFC that is not open for free software implementation is not acceptable to me. So, let the record show that there was not a unanimous consensus on this document going to Last Call on the standards track, unless Matsushita changes its stance and offers a royalty-free license to open-source developers. --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 01:50:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09880 for ; Fri, 5 Dec 2003 01:50:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS9my-0004ay-9T for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 01:50:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB56o8X5017654 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 01:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS9ms-0004Zk-4T; Fri, 05 Dec 2003 01:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS9mA-0004Z1-9O for avt@optimus.ietf.org; Fri, 05 Dec 2003 01:49:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09840; Fri, 5 Dec 2003 01:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS9m7-0003Ij-00; Fri, 05 Dec 2003 01:49:15 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AS9m6-0003IU-00; Fri, 05 Dec 2003 01:49:14 -0500 Received: from [68.100.124.243] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 2070880; Fri, 05 Dec 2003 01:48:56 -0500 From: "Marshall Eubanks" Subject: Re: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate? To: Eddie Kohler , Qiaobing Xie Cc: avt@ietf.org, dccp@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Fri, 05 Dec 2003 01:48:56 -0500 Message-ID: In-Reply-To: <200312050315.hB53FWsD034999@coyote.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Thu, 04 Dec 2003 19:15:32 -0800 Eddie Kohler wrote: > > I wish I could be as optimistic as you. I wonder if anyone on the list > > has some numbers that can show what percentage of additional media data > > will be injected into the network if codecs would stop doing silence > > detection (motion detection for video). > Hello; (Just got back from the airport, and am working backwards in e-mails) From Stanislaw's indispensible netflows : http://netflow.internet2.edu/weekly/20031124/ Reports on traffic on all Abilene routers Table 7 (for the most recent week). Http : 10.6 % of all octets for the week https : 0.52 % IPSEC + SSH : 2.68 % Multicast : 1.79% (for fan-in, not fan-out) "Subset of VOIP" : 0.01 % File Sharing : Between 15.21 and 52.08% (depending on how much of the "unknown" traffic is f.s.) Oh, just for reference : Table 8 TCP 92.22 % UDP 5.16 % So, my answer to your question is of order 0.01% (as I do not believe that at present the majority of VOIP is encrypted). Regards Marshall Eubanks > For the app Henning mentioned (multi-party, non-multicast conferencing), > silence suppression is a huge win. (With 100 participants and silence > suppression, you have 1-2 inbound streams' worth of data and 100 outbound > streams' worth; without it, you have 50-100 inbound streams and 100 > outbound streams.) > > On the other hand, say you have: > - 100 Kb/s uplink > - 100 person-to-person multimedia connections on the link > - Each of which uses 2 Kb/s when not silent > - and is silent 50% of the time > - and 100 TCP flows on the link (which are coming and going). > > A back of the envelope analysis: (Comments welcome) > > 1. If the media flows use silence suppression but not congestion control, > they will fit in the link on average, but crowd out the TCP flows. > Useful work getting done: 100. (1 "Work" unit == 1 TCP flow achieving > >= 500 b/s, OR one media flow achieving its preferred nonsilent rate > [2 Kb/s].) > > 2. If the media flows use congestion control but not silence suppression, > media and TCP will share the link, but each media flow is limited to > approximately 1/4 its preferred nonsilent bandwidth. Useful work > getting done: 125. > > 3. If the media flows use congestion control and send 1/2 rate filler data > during silent periods, media and TCP will share the link, but each media > flow is limited to approximately 1/3 its preferred nonsilent bandwidth. > Useful work getting done: 133. > > *None* of these results are particularly attractive. What you really want > is 150 units of work or something like it. But the first result is worst. > > The easiest way to get 150 work units is through bandwidth reservations, > and thus QoS. QoS is also the only reasonable way to privilege the media > traffic above TCP. > > Note that "all-or-nothing" media apps, which would either send at their > preferred rate or not at all, get a tough break; given the TCP flows, the > fair rate is < 1 Kb/s, too low for any media apps to send. (And thus > leading to 100 work units.) I'm not sure what the right solution is. > There might not be a solution apart from QoS/bandwidth reservations. > > > Fundamentally, I am concerned that this DCCP > > "app-who-sends-more-will-get-rewarded" feature will be taken advantage of > > in the wrong way (the draft that starts this discussion is the first > > attempt for this, but it won't be the last). > > > > If this behavior of "sending filler data when no real data to send" > > becomes a recommended practice for media-over-DCCP (as you and Tom seem > > to suggest), what would stop the same recommendation be made for app over > > TCP? For an app over a long lived TCP connection, the sender can also > > benefit from sending "filler data" to keep the pipe from collapsing, so > > as to avoid the penalty of going through another slow start when it has > > real data to send next time. But I think this is hardly something that > > should be recommended for TCP based apps. Why should it be more > > acceptable for DCCP then? > > It is a tough tradeoff. > > * Sending filler data is clearly bad. > > * On the other hand, the Internet works not because we judge whether the > *contents* of a data stream are worthwhile, but because we ensure that > data streams are friendly to one another. They do not continue > transmitting at high rates in the face of congestion. They do not cause > congestion collapse. > > Sending filler data *limited by congestion control* won't cause > congestion collapse. The app will not send *more* filler data after a > loss event; it will send less. > > My feeling has therefore been that filler data *limited by congestion > control* is better for the Internet than non-congestion-controlled media > traffic. But it is tough. > > Eddie > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 04:00:13 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26634 for ; Fri, 5 Dec 2003 04:00:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBoa-0002h8-IF for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 03:59:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB58xuFS010358 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 03:59:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBnh-0002Zr-CQ; Fri, 05 Dec 2003 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBnM-0002Zc-0B for avt@optimus.ietf.org; Fri, 05 Dec 2003 03:58:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26579 for ; Fri, 5 Dec 2003 03:58:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASBnJ-0005Dk-00 for avt@ietf.org; Fri, 05 Dec 2003 03:58:37 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1ASBnI-0005DZ-00 for avt@ietf.org; Fri, 05 Dec 2003 03:58:36 -0500 Received: from MCOMLAP3 ([10.10.150.80]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Dec 2003 09:57:45 +0100 From: "Rolf Hakenberg" To: "Gamze Seckin" , , Cc: "Colin Perkins \(E-mail\)" , "David Leon \(E-mail\)" , "Viktor Varsa \(E-mail\)" , "Magnus Westerlund \(E-mail\)" Subject: RE: [AVT] Retransmission draft Date: Fri, 5 Dec 2003 09:57:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <787ED0EC136B854DB341E7662D666CD66137E8@bels002.mediator.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 05 Dec 2003 08:57:45.0468 (UTC) FILETIME=[D98273C0:01C3BB0D] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA26580 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Gamze and all, Although I believe that the concerns expressed in 3GPP on server complexi= ty and delay are less relevant for our discussion on potential IPRs, please = let me clarify the agreement in 3GPP. At the last 3GPP SA4 meeting there was a consensus on to make RTP Retransmission a working assumption in PSS Rel-6, subject to the concerns= on server complexity and delay being addressed at the next meeting. Important for our current discussion on potential IPRs and how to progres= s the draft is the fact that there was no condition on the IPR issues, but = in fact conditions that the draft should move to RFC on standards track befo= re the finalisation of 3GPP Rel-6. Best Regards, Rolf. > -----Original Message----- > From: Gamze Seckin [mailto:gamze@vidiator.com] > Sent: Thursday, December 04, 2003 8:30 PM > To: rey@panasonic.de; avt@ietf.org > Cc: Colin Perkins (E-mail); David Leon (E-mail); Viktor Varsa (E-mail); > Magnus Westerlund (E-mail); hakenberg@panasonic.de > Subject: RE: [AVT] Retransmission draft > > > Hi, > > A quick note on the comment with regards to 3GPP's decision on this dra= ft: > > It has not been yet accepted yet within 3gpp. It is still under > discussion. In the last 3gpp sa4 meeting various delegates raised > a concern about server complexity and delay issues with regards > to the protocol. It was said that the acceptance is conditional > on concerns being addressed in the next meeting. > > thanks > best regards, > > gamze seckin > > -----Original Message----- > From: Jos=E9 Rey [mailto:rey@panasonic.de] > Sent: Thursday, December 04, 2003 5:35 AM > To: avt@ietf.org > Cc: Colin Perkins (E-mail); David Leon (E-mail); Viktor Varsa (E-mail); > Magnus Westerlund (E-mail); hakenberg@panasonic.de > Subject: RE: [AVT] Retransmission draft > > > Hi Colin, all, > > in the past weeks I had some intensive internal discussions on > the matter of > the potential IPRs on the RTP retransmission draft. As a WG participant= I > perfectly understand and respect the comments and interests > expressed by you > and others of the AVT group. In order to keep the good working > spirit in AVT > it is my strong intention to adress these comments in the best > possible way > by taking the interests of all parties involved in this work into accou= nt. > > Matsushita has published an IPR statement that it is prepared to grant = a > license on reasonable, nondiscriminatory terms and conditions (in > accordance > with paragraph 10.3.3 of the RFC 2026) on any part that is included int= o > the RTP retransmission standard and that Matsushita possibly > holds IPRs on. > Providing a royality-free license to open-source developers will > unfortunately lead to a situation where Matsushita will lose any rights= on > their IPRs in most cases. Taking into account the work and effort (we > started with the retransmission draft in AVT more than 2.5 years ago) w= e > spent into this draft, this is not acceptable for Matsushita. > > On the other hand, we believe that the situation for open-source > developers > is quite easy to solve by other means. First of all they are not > in any way > 'forced' to implement RTP retransmission. It is just an optional repair > mechanism for the RTP protocol, as described in RFC2354. In order to so= lve > the problems that RTP retransmission tries to solve, there are other > solutions available from the AVT group which are not encumbered by IPRs= , > e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This makes the implementati= on > of the RTP retransmission solution purely optional and easily avoidable= to > everyone. > > In order to make this situation clear to anybody who reads the RTP > retransmission draft, we suggest to add a paragraph at the very > beginning of > the draft. This paragraph will make implementors aware of the > situation that > the solution described in this draft is possibly encumbered by IPRs. > Furthermore it will point implementors to non-IPR-encumbered solutions = as > above, which may perfectly be used instead of RTP retransmission. > > Finally and FYI: 3GPP is aware of the IPR situation of the RTP > retransmission draft and has accepted the solution provided in > draft-ietf-avt-rtp-retransmission-09.txt as working assumption in their > packet based streaming service (PSS). The acceptance is conditional on = the > fact that the draft will proceed on standards track and an RFC is > available > before the release of the PSS specifications, (expected for March 2004). > > Looking forward to your comments, > > Jose > > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Coli= n > > Perkins > > Sent: Tuesday, October 21, 2003 6:58 PM > > To: rey@panasonic.de > > Cc: avt@ietf.org; 'Magnus Westerlund' > > Subject: Re: [AVT] Retransmission draft > > > > > > On Tuesday, Oct 21, 2003, at 12:54 Europe/London, Jose Rey wrote: > > ... > > > In previous emails we have been asked to explain our patent > > > application and > > > we > > > informed AVT that the patent application itself specifies a > transport > > > method > > > using the RTP protocol where two sequence numbers are used: one to > > > specifiy > > > the transmission order (=3DRTP SN) and the other one defining the > > > reprodution > > > order, which in the draft corresponds with the OSN (original > sequence > > > number). We also stated that it is not possible to implement the > > > protocol > > > without infringing on the patent. > > > So far we have not received any more questions on the patent, but > are > > > happy > > > to provide them in case needed. > > > > > > On the issue of how to proceed with this RTP retransmission draft > some > > > opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson > and > > > John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it a= s > > > Informational if the patent rights are held while Magnus and > > > Lars-Erik have suggested to proceed with the document as a Proposed > > > Standard (as we understand from the emails on from 22.09.03 and > > > 09.09.03). > > > > > > Taking all the above into account and considering that > > > independent of the patent situation this work is intended to be > > > included in > > > the next release of 3GPP, we would like to ask the group to proceed > > > with the > > > draft on standards track. > > > > > > cheers, > > > Jose > > > > [takes working group chair hat off] > > > > 3GPP is only one forum which uses IETF standards, and one where > dealing > > with IPR issues is commonplace. Having patented standards is more of > an > > issue for open source developers, who are often excluded by the > > licensing terms. Would Matsushita be willing to clarify if the > > "reasonable, nondiscriminatory" terms allow open source > implementations > > to use the retransmission format (this will probably require a > > Royalty-Free license)? > > > > [puts working group chair hat on again] > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 04:07:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26955 for ; Fri, 5 Dec 2003 04:07:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBvE-000374-Lv for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 04:06:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB596m6G011919 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 04:06:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBuU-0002zb-S5; Fri, 05 Dec 2003 04:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS45h-0001jT-Ge for avt@optimus.ietf.org; Thu, 04 Dec 2003 19:45:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28493; Thu, 4 Dec 2003 19:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS45f-0005nv-00; Thu, 04 Dec 2003 19:45:03 -0500 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1AS45d-0005nm-00; Thu, 04 Dec 2003 19:45:02 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.3) with ESMTP id hB4N2TQh003089; Thu, 4 Dec 2003 15:02:30 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200312042302.hB4N2TQh003089@cougar.icir.org> To: "Rosen, Brian" cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org From: Sally Floyd Date: Thu, 04 Dec 2003 15:02:29 -0800 Subject: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribution? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian - >Slow start is not >a practical thing for interactive use, sorry. I have not read all of the earlier email, so I might be repeating things that have already been said. Currently, slow-start for TCP allows an initial window of up to four packets. The reason that the Internet still works plausibly well even with interactive traffic that does not obey slow-start is that the vast majority of the packets in the Internet still use TCP, and still abide by slow-start and the other mechanisms of TCP congestion control. If the majority of the traffic on a congested link was interactive traffic that did not use slow-start, and that also did not use any admissions control or explicit feedback from routers allowing high initial windows, I don't think that any of the interactive users would be very happy with the results. This would particularly be true, I would conjecture, in a network with only interactive traffic, with no TCP traffic to back off and make space for the interactive traffic. For a best-effort network that includes TCP traffic, there is the additional concern of the fairness for the TCP users. There is no reason why best-effort interactive UDP traffic has a higher right to bandwidth or to low delay that does the best-effort TCP traffic (whose users are paying the same monthly fees to their service providers). Remember that the TCP traffic could easily be someone doing a web transaction that is perfectly important to them or to their business, and for which they are expecting the same prompt response times from the network that the interactive users are expecting. My own prediction is that, if there seems to be a danger of congestion in best-effort links due to best-effort UDP traffic that is not TCP-friendly, the routers at the congested links would end up preferentially dropping the UDP traffic in times of high congestion (since this is easier than more precisely-targetted forms of preferential dropping at the router). But maybe things will work out better than that, and routers will have mechanisms to precisely identify those flows that aren't using decent end-to-end congestion control in a time of high congestion, and preferentially drop packets from only those flows. No telling... - Sally http://www.icir.org/floyd/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 09:47:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07337 for ; Fri, 5 Dec 2003 09:47:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASHEY-0006Ql-TB for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 09:47:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5El6ie024715 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 09:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASHET-0006OB-TZ; Fri, 05 Dec 2003 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASHDb-0006Mu-In for avt@optimus.ietf.org; Fri, 05 Dec 2003 09:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07278; Fri, 5 Dec 2003 09:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASHDZ-0002HN-00; Fri, 05 Dec 2003 09:46:05 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ASHDY-0002HF-00; Fri, 05 Dec 2003 09:46:05 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27232; Fri, 5 Dec 2003 09:42:48 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23406; Fri, 5 Dec 2003 09:42:36 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Dec 2003 09:42:36 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B618C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sally Floyd'" Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Date: Fri, 5 Dec 2003 09:42:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] RE: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Sally I think the primary control for media streams is going to be admission control. There is a missing link to make this work, which is that there is no feedback path from the media flow to the signalling (RTP to SIP/RTSP), but fundamentally, if a media flow experiences congestion, it will be downshifted to a lower rate (once, maybe) or shut down. It's pretty reasonable to expect that such congestion control could be widely deployed. I think that is the way congestion collapse should be addressed. It's harder to deal with the relative fairness of TCP vs media flows. None of the mechanisms that I have heard proposed will work in my opinion. Work means that you get acceptable voice/video quality up to the point where congestion is bad enough that signalling shuts down the flow. Media flows can't deal with "fair" in the sense that TCP does. There is no "fair", there is only "all or nothing". One possible avenue of exploration is to look more into aggregate behavior; you CAN probably assert a more TCP friendly "rate control" if you deal with the aggregate of media traffic, even if the individual components of the traffic experience all or nothing flow control. Ultimately, however, the actual media flow can't do anything interesting with existing TCP mechanisms. It only has a very gross rate control, it can't probe, it's silly to send filler, and it can't use any form of a window. Similarly, TCP doesn't have any way to know if the media flow is present, and thus adjust it's behavior appropriately. "appropriately" means not being greedy; the biggest actual problem that exists today is that TCP destroys voice, not that voice destroys TCP. I think, naively perhaps, that it is possible to design mechanisms that would work together, but it is highly unlikely to be possible to do this from one side; TCP must change as well as UDP (or a replacement). I suspect that if a service provider is providing both a data service and a voice service over that data service, that it will drop all the TCP traffic before it drops any voice traffic, because, so far, the pricing for a voice bit is several orders of magnitude larger than a data bit. If the data service provider is not also the voice service provider, it's not clear to me why he would care which customer bits get treated differently. Conventional wisdom in carriers is that flat rate Internet service makes small profits, while voice/video makes a lot more. Don't know if that's really true, or will remain true, but I'll bet you will scream much more loudly if your voice/video sounds/looks bad than if your browser slows down. Of course, deployment of QoS mechanisms would be helpful. Brian > -----Original Message----- > From: Sally Floyd [mailto:floyd@icir.org] > Sent: Thursday, December 04, 2003 6:02 PM > To: Rosen, Brian > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] RE: Would DCCP kill Internet real-time media > distribution? > > > Brian - > > >Slow start is not > >a practical thing for interactive use, sorry. > > I have not read all of the earlier email, so I might be repeating > things that have already been said. > > Currently, slow-start for TCP allows an initial window of up to > four packets. The reason that the Internet still works plausibly > well even with interactive traffic that does not obey slow-start > is that the vast majority of the packets in the Internet still use > TCP, and still abide by slow-start and the other mechanisms of TCP > congestion control. If the majority of the traffic on a congested > link was interactive traffic that did not use slow-start, and that > also did not use any admissions control or explicit feedback from > routers allowing high initial windows, I don't think that any of > the interactive users would be very happy with the results. This > would particularly be true, I would conjecture, in a network with > only interactive traffic, with no TCP traffic to back off and make > space for the interactive traffic. > > For a best-effort network that includes TCP traffic, there is the > additional concern of the fairness for the TCP users. There is no > reason why best-effort interactive UDP traffic has a higher right > to bandwidth or to low delay that does the best-effort TCP traffic > (whose users are paying the same monthly fees to their service > providers). Remember that the TCP traffic could easily be someone > doing a web transaction that is perfectly important to them or to > their business, and for which they are expecting the same prompt > response times from the network that the interactive users are > expecting. > > My own prediction is that, if there seems to be a danger of congestion > in best-effort links due to best-effort UDP traffic that is not > TCP-friendly, the routers at the congested links would end up > preferentially dropping the UDP traffic in times of high congestion > (since this is easier than more precisely-targetted forms of > preferential dropping at the router). But maybe things will work > out better than that, and routers will have mechanisms to precisely > identify those flows that aren't using decent end-to-end congestion > control in a time of high congestion, and preferentially drop packets > from only those flows. No telling... > > - Sally > http://www.icir.org/floyd/ > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 14:36:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20160 for ; Fri, 5 Dec 2003 14:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLkT-0001d2-Ex for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 14:36:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5JaLLQ006256 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 14:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLk9-0001Yc-KY; Fri, 05 Dec 2003 14:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASLjd-0001Ui-Tq for avt@optimus.ietf.org; Fri, 05 Dec 2003 14:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20060; Fri, 5 Dec 2003 14:35:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASLja-0000WE-00; Fri, 05 Dec 2003 14:35:26 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ASLja-0000WB-00; Fri, 05 Dec 2003 14:35:26 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB5JZPsD042076; Fri, 5 Dec 2003 11:35:25 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312051935.hB5JZPsD042076@coyote.icir.org> To: "Rosen, Brian" cc: "'Sally Floyd'" , avt@ietf.org, dccp@ietf.org In-Reply-To: Message from "Rosen, Brian" of "Fri, 05 Dec 2003 09:42:35 EST." <313680C9A886D511A06000204840E1CF070B618C@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 05 Dec 2003 11:35:25 -0800 From: Eddie Kohler Subject: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > It's harder to deal with the relative fairness of TCP vs media flows. > None of the mechanisms that I have heard proposed will work in my > opinion. Work means that you get acceptable voice/video quality up > to the point where congestion is bad enough that signalling shuts > down the flow. Media flows can't deal with "fair" in the sense that > TCP does. There is no "fair", there is only "all or nothing". I think the key question for the DCCP folk is, What does it mean for congestion to be "bad enough that signalling shuts down the flow"? 1. The loss rate is greater than some fixed constant. (Independent of flow rate or RTT.) 2. Loss rate plus RTT indicate that the TCP-friendly rate has dropped below the app's transmit rate. 3. Loss rate plus RTT indicate that the TCP-friendly rate has dropped below some fraction -- say half -- of the app's preferred transmit rate. If your app wants (1), then we are not the right protocol for you. Arguably you are bad Homer and should get no donut on the public best-effort Internet. On the other hand, if (2) or (3) is the case, then we *want* to be your protocol. We provide a signalling path for the receiver to verifiably inform the sender of the loss/mark rate. We provide different mechanisms for calculating the TCP-friendly rate. The app can decide how to react to the rate; such as by reducing once, then cutting off. (DCCP does not require apps with smoothly varying rates! It provides a smoothly varying _reference_ rate; the app's rate need not smoothly vary, as long as it stays within some factor of the reference rate.) As we've discussed, the more interactive, CBR-flavored apps would find it difficult to use DCCP now. The issue seems to be slow start. ("Filler data", for example, is really about slow start: filler data is one mechanism for avoiding slow start after an idle period.) So, thought experiment for interactive, CBR-flavored apps: 1. Is slow start in fact the only problem? 2. What would these apps give up in return for avoiding slow start? (Maybe the apps would limit their transmit rate to below some absolute number, or shut off quickly if a "fast start" caused loss. In return, maybe the app would avoid *any* slow start, or maybe it'd avoid slow start after idle periods.) 3. Would any such compromise be acceptable for the DCCP folk? (Need to think more.) > "appropriately" means not being greedy; the biggest actual problem that > exists today is that TCP destroys voice, not that voice destroys TCP. I assume you see this happen. We've been throwing around assumptions about when -- do you agree? Does it happen mostly if the congested link has low statmux? Any references? Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 15:19:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22915 for ; Fri, 5 Dec 2003 15:19:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMPp-0003bI-5O for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 15:19:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KJ57B013814 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 15:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMPl-0003ZK-21; Fri, 05 Dec 2003 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMPT-0003Yo-1P for avt@optimus.ietf.org; Fri, 05 Dec 2003 15:18:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22860; Fri, 5 Dec 2003 15:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASMPR-00018n-00; Fri, 05 Dec 2003 15:18:41 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ASMPQ-00018a-00; Fri, 05 Dec 2003 15:18:40 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09023; Fri, 5 Dec 2003 15:15:19 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17770; Fri, 5 Dec 2003 15:15:11 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Dec 2003 15:15:11 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6190@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Eddie Kohler'" Cc: "'Sally Floyd'" , avt@ietf.org, dccp@ietf.org Subject: RE: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? Date: Fri, 5 Dec 2003 15:15:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I think the key question for the DCCP folk is, What does it mean for > congestion to be "bad enough that signalling shuts down the flow"? > > 1. The loss rate is greater than some fixed constant. > (Independent of flow > rate or RTT.) > 2. Loss rate plus RTT indicate that the TCP-friendly rate has > dropped below > the app's transmit rate. > 3. Loss rate plus RTT indicate that the TCP-friendly rate has > dropped below > some fraction -- say half -- of the app's preferred transmit rate. It's closest to (1). There really isn't a "fixed" constant, because what's acceptable quality is in the eye of the beholder, but probably, the signalling system would establish a fixed loss rate, below which it would take action. It would not matter what else was happening; that is, whatever the reason for the loss, the quality of the media is below the point where it should be maintained. It will then lower the rate, or drop the flow. For voice, the loss rate is something in the single digit percent range for high quality, and I don't know, maybe 10%-15% or so for low quality services. I don't think anything approaching 30% is useful, even if it's free. You get to do some averaging. > > If your app wants (1), then we are not the right protocol for you. > Arguably you are bad Homer and should get no donut on the public > best-effort Internet. Agree that DCCP is probably not useful for interactive media. For non-interactive media, there is some hope, because slow-start is probably not much of a problem. However, I still don't see how you get to maintain a fixed rate as TCP flows come and go, even with a lot of buffering. Won't TFRC in the face of congestion lower your rate? That would not work; the rate must be pretty constant (averaged over the buffer length). Disagree that media is a bad Homer. TCP is broken. Nowhere is it written that TCP=best effort. > > On the other hand, if (2) or (3) is the case, then we *want* > to be your > protocol. We provide a signalling path for the receiver to verifiably > inform the sender of the loss/mark rate. We provide > different mechanisms > for calculating the TCP-friendly rate. The app can decide > how to react to > the rate; such as by reducing once, then cutting off. (DCCP does not > require apps with smoothly varying rates! It provides a > smoothly varying > _reference_ rate; the app's rate need not smoothly vary, as long as it > stays within some factor of the reference rate.) I think this is all foolish. You have to assume that the TCP flows are coming and going, and the media flow is pretty fixed. I don't see how DCCP will maintain the original TCP-friendly rate, even if that rate was forced to be acceptable. You can say that it varies the TCP-friendly rate slowly, but not zero, right? Time scales here are minutes to hours. You need constant rate over minutes to hours. > > As we've discussed, the more interactive, CBR-flavored apps > would find it > difficult to use DCCP now. The issue seems to be slow start. > ("Filler > data", for example, is really about slow start: filler data is one > mechanism for avoiding slow start after an idle period.) Well, it's one of a couple of problems. All the current apps are CBR flavored, Philippe's suggestions notwithstanding. Slow start is a killer for interactive, for sure. > > So, thought experiment for interactive, CBR-flavored apps: > 1. Is slow start in fact the only problem? No, I think there is no way to maintain a constant rate over the time period. > 2. What would these apps give up in return for avoiding slow > start? (Maybe > the apps would limit their transmit rate to below some > absolute number, > or shut off quickly if a "fast start" caused loss. In > return, maybe the > app would avoid *any* slow start, or maybe it'd avoid slow > start after > idle periods.) It could do any form of signalling of its intentions It can limit its rate to a fixed number; it can even negotiate that number, and, if necessary, once, it can lower the number. It can react to loss by lowering the rate (once) or shutting down > 3. Would any such compromise be acceptable for the DCCP folk? > (Need to > think more.) > > > "appropriately" means not being greedy; the biggest actual > problem that > > exists today is that TCP destroys voice, not that voice > destroys TCP. > > I assume you see this happen. We've been throwing around > assumptions about > when -- do you agree? Does it happen mostly if the congested > link has low > statmux? Any references? I have no reference data. My sense is that it happens under both low and high statmux, but I'm not really sure its the same mechanism in both cases. Need more data I suspect. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 15:29:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23670 for ; Fri, 5 Dec 2003 15:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMZV-0003x3-5H for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 15:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KT5V6015185 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 15:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMZR-0003w1-PG; Fri, 05 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASMZ9-0003vQ-DL for avt@optimus.ietf.org; Fri, 05 Dec 2003 15:28:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23530; Fri, 5 Dec 2003 15:28:28 -0500 (EST) Message-Id: <200312052028.PAA23530@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 05 Dec 2003 15:28:27 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-clearmode-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --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 a 64 kbit/s transparent call Author(s) : R. Kreuter Filename : draft-ietf-avt-rtp-clearmode-04.txt Pages : 7 Date : 2003-12-5 This document describes how to carry 64 kbit/s data streams transparently in RTP packets, using a pseudo-codec called 'Clearmode'. It also serves as registration for a related MIME type called 'audio/clearmode'. 'Clearmode' is a basic feature of VoIP media gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-clearmode-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-clearmode-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: <2003-12-5150631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-clearmode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-5150631.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 5 16:24:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27295 for ; Fri, 5 Dec 2003 16:24:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNQw-0006oa-Qm for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 16:24:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LOIjI026190 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 16:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNQe-0006nf-T8; Fri, 05 Dec 2003 16:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASNQQ-0006n9-CR for avt@optimus.ietf.org; Fri, 05 Dec 2003 16:23:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27245 for ; Fri, 5 Dec 2003 16:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASNQO-0002ku-00 for avt@ietf.org; Fri, 05 Dec 2003 16:23:44 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ASNQN-0002jZ-00 for avt@ietf.org; Fri, 05 Dec 2003 16:23:43 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB5LMZsD042739; Fri, 5 Dec 2003 13:22:35 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312052122.hB5LMZsD042739@coyote.icir.org> To: "Rosen, Brian" cc: "'Sally Floyd'" , avt@ietf.org Subject: Re: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? In-Reply-To: Message from "Rosen, Brian" of "Fri, 05 Dec 2003 15:15:10 EST." <313680C9A886D511A06000204840E1CF070B6190@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 05 Dec 2003 13:22:35 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > However, I still don't see > how you get to maintain a fixed rate as TCP flows come and go, > even with a lot of buffering. Won't TFRC in the face of > congestion lower your rate? Not necessarily. The TCP equation takes in an RTT and a loss event rate, and produces a reference rate. This reference rate can be thought of as "what TCP would achieve sending full blast." If you were originally sending less than what TCP would have sent (possibly the normal case?), then slightly increased loss rates would not reduce the reference rate below your actual transmit rate. Continue sending at your preferred rate. Caveat: The reference rate *is* limited to (2 * your recent transmit rate). But the factor of 2 is pretty wide wiggle room. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 07:10:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21669 for ; Sun, 7 Dec 2003 07:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxjs-00028X-Ap for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 07:10:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7CAGS5008107 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 07:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxje-00024n-NH; Sun, 07 Dec 2003 07:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASJEl-0002Pk-7d for avt@optimus.ietf.org; Fri, 05 Dec 2003 11:55:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13497; Fri, 5 Dec 2003 11:55:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASJEi-0004iJ-00; Fri, 05 Dec 2003 11:55:24 -0500 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 1ASJEi-0004iA-00; Fri, 05 Dec 2003 11:55:24 -0500 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.9p2/8.12.8) with ESMTP id hB5GtLGg071024; Fri, 5 Dec 2003 16:55:21 GMT (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: qli cc: avt , dccp Subject: Re: [AVT] RE: [dccp] Would a DCCP flow need to send 2x its preferred rate? In-reply-to: Your message of "Wed, 03 Dec 2003 09:32:40 EST." <86C0B7B413918E45A4B0A97F95657A0A152586@ceruleus.brainmediaco.com> Date: Fri, 05 Dec 2003 16:55:21 +0000 Message-ID: <71023.1070643321@aardvark.cs.ucl.ac.uk> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >> If the congested link has low levels of statmux -- like one DCCP flow and >> one TCP flow -- then yes, the TCP would try for the available bandwidth. >> And during a silent period, the TFRC flow would have to transmit something >> so it wasn't crowded out entirely. But this amount would be *half* the >> nominal rate, or perhaps less. Not twice. >Huh? You seem to be saying that if you have a lot of TCP streams on a link >they won't use all of the available bandwidth. I thought just the opposite. >With a low level of multiplexing there's more chance of synchronizing losses >and cutbacks, and not fully utilizing the link. But with a large number >of flows enough of them will be blasting away while others are cut back. No this isn't what Eddie was saying. Say the link has capacity C. Assume every flow has the same RTT for the sake of simplicity: In the low statmux case: The TFRC flow achieves rate C because there's no other traffic. Then it pauses, and a TCP starts which achieves rate C. Then TFRC starts up again at rate C, and 50% loss briefly ensures before everything settles down. In the high statmux case (n flows): The TFRC flow achieves rate C/n, and loss rate p1. Then it pauses. The other TCP flows rapidly use up the available capacity, each averaging rate C/(n-1). Then TFRC restarts with rate C/n, and briefly sees loss rate p2. If n >> 1 then C/n ~= C/(n-1) and p1 ~= p2. Thus the *startup* of the TFRC flow doesn't significantly affect the loss rate, and it is going at approximately the correct rate. Of course the number of flows can change while the TFRC flow is idle. But the worst that can happen is that the *additional* loss caused by the TFRC restarting is bounded to p = 1/(n-1). For large n, this will likely be dominated by the loss caused by the TCPs themselves doing AIMD. Thus the restart issue is only a serious problem when there is little statmuxing at the bottleneck link (or where many TFRC restart simultaneously, synchronized by some external event). The moral of this is to use RSVP/Intserv on your 56K modem link, and ignore the problem elsewhere. Cheers, Mark _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 07:10:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21684 for ; Sun, 7 Dec 2003 07:10:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxjs-00028Y-BE for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 07:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7CAGJC008101 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 07:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxjg-000253-6f; Sun, 07 Dec 2003 07:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASh5o-0001za-D3 for avt@optimus.ietf.org; Sat, 06 Dec 2003 13:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15502; Sat, 6 Dec 2003 13:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASh5m-0004t9-00; Sat, 06 Dec 2003 13:23:46 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1ASh5l-0004sN-00; Sat, 06 Dec 2003 13:23:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 44B25513; Sat, 6 Dec 2003 13:23:17 -0500 (EST) Received: from localhost (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 1A896524; Sat, 6 Dec 2003 13:23:16 -0500 (EST) Date: Sat, 06 Dec 2003 13:23:15 -0500 From: Guy T Almes To: slow@caltech.edu, "Rosen, Brian" Cc: "'Sally Floyd'" , "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org, fast-support@cs.caltech.edu, Fred Baker , Matt Mathis , Guy T Almes Message-ID: <68360000.1070734995@localhost> In-Reply-To: <3FD0C5BC.60803@caltech.edu> References: <313680C9A886D511A06000204840E1CF070B618C@whq-msgusr-02.pit.comms .marconi.com> <3FD0C5BC.60803@caltech.edu> X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steven, What does seem clear is that, *if* using delay+loss signals together you can maintain modest-sized and stable-sized queues at the bottleneck link, then there are many positive implications for the net, both for the routers/switches and their engineering and for the applications, particularly jitter-sensitive ones, that share the bottleneck link. It would seem that the challenge is to accomplish the task of maintaining such queues in a highly dynamic environment with many and many kinds of flows. With an increasing reach of the international advanced production networks (e.g., Internet2/Abilene in the US, Geant in Europe) being made up of 10 Gb/s links, this challenge is ever more crucial. I look forward to hearing from others on the thread. Regards, -- Guy --On Friday, December 05, 2003 09:51:56 -0800 Steven Low wrote: > > Thanks everyone for the intresting discussions from various > perspectives. What are your expert opinions on the coexistence > of a delay-based TCP with (let's assume, essentially) fixed rates > of media flows? Granted that there are many challenges in filtering > out noise in delay measurements, etc, but these seem more > surmountable than the fundamental difficulty of a loss-based > scheme where TCP must periodically push the queue to overflow, > thus squeezing out other flows that are not as (or more) > aggressive than TCP. In a delay-based scheme where (e.g.) a > TCP flow will stabilize when it maintains a certain amount of queue > (instead of pushing it over the cliff), it will then coexist peacefully > with media flows, each sharing the link at a rate that's proportional > to their buffer shares, without the protocol itself producing severe > oscillations. > > Again, there are of course challenges to filter delay noise, ensure > fairness, etc, but it seems to avoid a more difficult problem of a > loss-based scheme. > > Steven > > > > Rosen, Brian wrote: > >> Sally >> >> I think the primary control for media streams is going to be >> admission control. There is a missing link to make this work, >> which is that there is no feedback path from the media flow to the >> signalling (RTP to SIP/RTSP), but fundamentally, if a media flow >> experiences congestion, it will be downshifted to a lower rate >> (once, maybe) or shut down. It's pretty reasonable to expect that >> such congestion control could be widely deployed. I think that >> is the way congestion collapse should be addressed. >> >> It's harder to deal with the relative fairness of TCP vs media flows. >> None of the mechanisms that I have heard proposed will work in my >> opinion. Work means that you get acceptable voice/video quality up >> to the point where congestion is bad enough that signalling shuts >> down the flow. Media flows can't deal with "fair" in the sense that >> TCP does. There is no "fair", there is only "all or nothing". >> >> One possible avenue of exploration is to look more into aggregate >> behavior; you CAN probably assert a more TCP friendly "rate control" >> if you deal with the aggregate of media traffic, even if the individual >> components of the traffic experience all or nothing flow control. >> >> Ultimately, however, the actual media flow can't do anything interesting >> with existing TCP mechanisms. It only has a very gross rate control, >> it can't probe, it's silly to send filler, and it can't use any form >> of a window. Similarly, TCP doesn't have any way to know if the media >> flow is present, and thus adjust it's behavior appropriately. >> "appropriately" means not being greedy; the biggest actual problem that >> exists today is that TCP destroys voice, not that voice destroys TCP. >> I think, naively perhaps, that it is possible to design mechanisms >> that would work together, but it is highly unlikely to be possible to >> do this from one side; TCP must change as well as UDP (or a replacement). >> >> I suspect that if a service provider is providing both a data service >> and a voice service over that data service, that it will drop all the >> TCP traffic before it drops any voice traffic, because, so far, the >> pricing for a voice bit is several orders of magnitude larger than >> a data bit. If the data service provider is not also the voice service >> provider, it's not clear to me why he would care which customer bits >> get treated differently. Conventional wisdom in carriers is that >> flat rate Internet service makes small profits, while voice/video >> makes a lot more. Don't know if that's really true, or will remain true, >> but I'll bet you will scream much more loudly if your voice/video >> sounds/looks bad than if your browser slows down. >> >> Of course, deployment of QoS mechanisms would be helpful. >> >> Brian >> >> >> >>> -----Original Message----- >>> From: Sally Floyd [mailto:floyd@icir.org] >>> Sent: Thursday, December 04, 2003 6:02 PM >>> To: Rosen, Brian >>> Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org >>> Subject: Re: [dccp] RE: Would DCCP kill Internet real-time media >>> distribution? >>> >>> >>> Brian - >>> >>> >>> >>>> Slow start is not >>>> a practical thing for interactive use, sorry. >>>> >>>> >>> I have not read all of the earlier email, so I might be repeating >>> things that have already been said. >>> >>> Currently, slow-start for TCP allows an initial window of up to >>> four packets. The reason that the Internet still works plausibly >>> well even with interactive traffic that does not obey slow-start >>> is that the vast majority of the packets in the Internet still use >>> TCP, and still abide by slow-start and the other mechanisms of TCP >>> congestion control. If the majority of the traffic on a congested >>> link was interactive traffic that did not use slow-start, and that >>> also did not use any admissions control or explicit feedback from >>> routers allowing high initial windows, I don't think that any of >>> the interactive users would be very happy with the results. This >>> would particularly be true, I would conjecture, in a network with >>> only interactive traffic, with no TCP traffic to back off and make >>> space for the interactive traffic. >>> >>> For a best-effort network that includes TCP traffic, there is the >>> additional concern of the fairness for the TCP users. There is no >>> reason why best-effort interactive UDP traffic has a higher right >>> to bandwidth or to low delay that does the best-effort TCP traffic >>> (whose users are paying the same monthly fees to their service >>> providers). Remember that the TCP traffic could easily be someone >>> doing a web transaction that is perfectly important to them or to >>> their business, and for which they are expecting the same prompt >>> response times from the network that the interactive users are >>> expecting. >>> >>> My own prediction is that, if there seems to be a danger of congestion >>> in best-effort links due to best-effort UDP traffic that is not >>> TCP-friendly, the routers at the congested links would end up >>> preferentially dropping the UDP traffic in times of high congestion >>> (since this is easier than more precisely-targetted forms of >>> preferential dropping at the router). But maybe things will work >>> out better than that, and routers will have mechanisms to precisely >>> identify those flows that aren't using decent end-to-end congestion >>> control in a time of high congestion, and preferentially drop packets >>> from only those flows. No telling... >>> >>> - Sally >>> http://www.icir.org/floyd/ >>> >>> >>> >>> >>> >> >> _______________________________________________ >> dccp IETF mailing list: dccp@ietf.org >> list info: https://www1.ietf.org/mailman/listinfo/dccp >> wg charter: http://www.ietf.org/html.charters/dccp-charter.html >> >> >> > > -- > _____________________________________________ > Steven Low assoc prof, cs & ee > http://netlab.caltech.edu tel: (626) 395-6767 > slow@caltech.edu fax: (626) 568-3603 > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 08:05:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21685 for ; Sun, 7 Dec 2003 07:10:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxjs-00028Z-BX for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 07:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7CAGjU008111 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 07:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASxjf-00024v-Cm; Sun, 07 Dec 2003 07:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASK8T-0005pS-JB for avt@optimus.ietf.org; Fri, 05 Dec 2003 12:53:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16089; Fri, 5 Dec 2003 12:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASK8R-0006Cb-00; Fri, 05 Dec 2003 12:52:59 -0500 Received: from swordfish.cs.caltech.edu ([131.215.44.124]) by ietf-mx with esmtp (Exim 4.12) id 1ASK8R-0006CX-00; Fri, 05 Dec 2003 12:52:59 -0500 Received: from caltech.edu (replicant.caltech.edu [131.215.220.114]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id D8114DF281; Fri, 5 Dec 2003 09:52:57 -0800 (PST) Message-ID: <3FD0C5BC.60803@caltech.edu> Date: Fri, 05 Dec 2003 09:51:56 -0800 From: Steven Low Reply-To: slow@caltech.edu Organization: Caltech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" Cc: "'Sally Floyd'" , "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org, fast-support@cs.caltech.edu, Fred Baker , Matt Mathis , guy Almes References: <313680C9A886D511A06000204840E1CF070B618C@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks everyone for the intresting discussions from various perspectives. What are your expert opinions on the coexistence of a delay-based TCP with (let's assume, essentially) fixed rates of media flows? Granted that there are many challenges in filtering out noise in delay measurements, etc, but these seem more surmountable than the fundamental difficulty of a loss-based scheme where TCP must periodically push the queue to overflow, thus squeezing out other flows that are not as (or more) aggressive than TCP. In a delay-based scheme where (e.g.) a TCP flow will stabilize when it maintains a certain amount of queue (instead of pushing it over the cliff), it will then coexist peacefully with media flows, each sharing the link at a rate that's proportional to their buffer shares, without the protocol itself producing severe oscillations. Again, there are of course challenges to filter delay noise, ensure fairness, etc, but it seems to avoid a more difficult problem of a loss-based scheme. Steven Rosen, Brian wrote: >Sally > >I think the primary control for media streams is going to be >admission control. There is a missing link to make this work, >which is that there is no feedback path from the media flow to the >signalling (RTP to SIP/RTSP), but fundamentally, if a media flow >experiences congestion, it will be downshifted to a lower rate >(once, maybe) or shut down. It's pretty reasonable to expect that >such congestion control could be widely deployed. I think that >is the way congestion collapse should be addressed. > >It's harder to deal with the relative fairness of TCP vs media flows. >None of the mechanisms that I have heard proposed will work in my >opinion. Work means that you get acceptable voice/video quality up >to the point where congestion is bad enough that signalling shuts >down the flow. Media flows can't deal with "fair" in the sense that >TCP does. There is no "fair", there is only "all or nothing". > >One possible avenue of exploration is to look more into aggregate >behavior; you CAN probably assert a more TCP friendly "rate control" >if you deal with the aggregate of media traffic, even if the individual >components of the traffic experience all or nothing flow control. > >Ultimately, however, the actual media flow can't do anything interesting >with existing TCP mechanisms. It only has a very gross rate control, >it can't probe, it's silly to send filler, and it can't use any form >of a window. Similarly, TCP doesn't have any way to know if the media >flow is present, and thus adjust it's behavior appropriately. >"appropriately" means not being greedy; the biggest actual problem that >exists today is that TCP destroys voice, not that voice destroys TCP. >I think, naively perhaps, that it is possible to design mechanisms >that would work together, but it is highly unlikely to be possible to >do this from one side; TCP must change as well as UDP (or a replacement). > >I suspect that if a service provider is providing both a data service >and a voice service over that data service, that it will drop all the >TCP traffic before it drops any voice traffic, because, so far, the >pricing for a voice bit is several orders of magnitude larger than >a data bit. If the data service provider is not also the voice service >provider, it's not clear to me why he would care which customer bits >get treated differently. Conventional wisdom in carriers is that >flat rate Internet service makes small profits, while voice/video >makes a lot more. Don't know if that's really true, or will remain true, >but I'll bet you will scream much more loudly if your voice/video >sounds/looks bad than if your browser slows down. > >Of course, deployment of QoS mechanisms would be helpful. > >Brian > > > >>-----Original Message----- >>From: Sally Floyd [mailto:floyd@icir.org] >>Sent: Thursday, December 04, 2003 6:02 PM >>To: Rosen, Brian >>Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org >>Subject: Re: [dccp] RE: Would DCCP kill Internet real-time media >>distribution? >> >> >>Brian - >> >> >> >>>Slow start is not >>>a practical thing for interactive use, sorry. >>> >>> >>I have not read all of the earlier email, so I might be repeating >>things that have already been said. >> >>Currently, slow-start for TCP allows an initial window of up to >>four packets. The reason that the Internet still works plausibly >>well even with interactive traffic that does not obey slow-start >>is that the vast majority of the packets in the Internet still use >>TCP, and still abide by slow-start and the other mechanisms of TCP >>congestion control. If the majority of the traffic on a congested >>link was interactive traffic that did not use slow-start, and that >>also did not use any admissions control or explicit feedback from >>routers allowing high initial windows, I don't think that any of >>the interactive users would be very happy with the results. This >>would particularly be true, I would conjecture, in a network with >>only interactive traffic, with no TCP traffic to back off and make >>space for the interactive traffic. >> >>For a best-effort network that includes TCP traffic, there is the >>additional concern of the fairness for the TCP users. There is no >>reason why best-effort interactive UDP traffic has a higher right >>to bandwidth or to low delay that does the best-effort TCP traffic >>(whose users are paying the same monthly fees to their service >>providers). Remember that the TCP traffic could easily be someone >>doing a web transaction that is perfectly important to them or to >>their business, and for which they are expecting the same prompt >>response times from the network that the interactive users are >>expecting. >> >>My own prediction is that, if there seems to be a danger of congestion >>in best-effort links due to best-effort UDP traffic that is not >>TCP-friendly, the routers at the congested links would end up >>preferentially dropping the UDP traffic in times of high congestion >>(since this is easier than more precisely-targetted forms of >>preferential dropping at the router). But maybe things will work >>out better than that, and routers will have mechanisms to precisely >>identify those flows that aren't using decent end-to-end congestion >>control in a time of high congestion, and preferentially drop packets >>from only those flows. No telling... >> >>- Sally >>http://www.icir.org/floyd/ >> >> >> >> >> > >_______________________________________________ >dccp IETF mailing list: dccp@ietf.org >list info: https://www1.ietf.org/mailman/listinfo/dccp >wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > -- _____________________________________________ Steven Low assoc prof, cs & ee http://netlab.caltech.edu tel: (626) 395-6767 slow@caltech.edu fax: (626) 568-3603 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 09:20:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23892 for ; Sun, 7 Dec 2003 09:20:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzla-0005Uo-GJ for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 09:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7EK9NG021075 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 09:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzlU-0005TG-Dq; Sun, 07 Dec 2003 09:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzkz-0005SR-DG for avt@optimus.ietf.org; Sun, 07 Dec 2003 09:19:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23874 for ; Sun, 7 Dec 2003 09:19:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASzkx-0001T6-00 for avt@ietf.org; Sun, 07 Dec 2003 09:19:31 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ASzkx-0001Sj-00 for avt@ietf.org; Sun, 07 Dec 2003 09:19:31 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61166 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ASzjx-0001KT-00; Sun, 07 Dec 2003 14:18:29 +0000 Date: Sun, 7 Dec 2003 14:18:39 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Message-Id: <20031207141839.46a14542.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] WG last call: iLBC payload format and codec Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is to announce a working group last call on the RTP Payload Format and codec for iLBC speech: draft-ietf-avt-rtp-ilbc-04.txt draft-ietf-avt-ilbc-codec-04.txt Please send any final comments on these drafts to the mailing list by 19th December 2003. If no substantive comments are received by that time, we will ask the IESG to publish the codec as an Experimental RFC and the RTP payload format as a Proposed Standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 09:28:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24038 for ; Sun, 7 Dec 2003 09:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASztC-0005hZ-62 for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 09:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7ES2sR021883 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 09:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASztB-0005gQ-Ko; Sun, 07 Dec 2003 09:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzsb-0005gF-O1 for avt@optimus.ietf.org; Sun, 07 Dec 2003 09:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24009 for ; Sun, 7 Dec 2003 09:27:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASzsa-0001Yc-00 for avt@ietf.org; Sun, 07 Dec 2003 09:27:24 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ASzsZ-0001Y8-00 for avt@ietf.org; Sun, 07 Dec 2003 09:27:23 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61170 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ASzs5-0001Kg-00; Sun, 07 Dec 2003 14:26:53 +0000 Date: Sun, 7 Dec 2003 14:27:02 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Message-Id: <20031207142702.41573038.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] WG last call: draft-ietf-avt-rtp-clearmode-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is to announce a working group last call on the RTP payload format for 64 kbit/s transparent calls (draft-ietf-avt-rtp-clearmode-04.txt). Please send any final comments on this draft to the mailing list by 19th December 2003. If no substantive comments are received by that time, we will ask the IESG to publish this draft as a Proposed Standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 09:37:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24347 for ; Sun, 7 Dec 2003 09:37:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT01w-0006EC-CP for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 09:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7Eb4Yt023919 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 09:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT01u-0006Co-PL; Sun, 07 Dec 2003 09:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT01N-0006Bc-Rp for avt@optimus.ietf.org; Sun, 07 Dec 2003 09:36:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24320 for ; Sun, 7 Dec 2003 09:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT01M-0001iF-00 for avt@ietf.org; Sun, 07 Dec 2003 09:36:28 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AT01L-0001hr-00 for avt@ietf.org; Sun, 07 Dec 2003 09:36:27 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61185 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AT00r-0001Kz-00; Sun, 07 Dec 2003 14:35:57 +0000 Date: Sun, 7 Dec 2003 14:36:06 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Subject: Re: [AVT] Last call for review: draft-jones-avt-audio-t38-02.txt Message-Id: <20031207143606.22e179df.csp@csperkins.org> In-Reply-To: <20031124003658.7c89050c.csp@csperkins.org> References: <20031124003658.7c89050c.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The only comments received on this draft were minor editorial issues, which are corrected in the -03 revision. Accordingly, we will recommend the IESG publish draft-jones-avt-audio-t38-03.txt as a Proposed Standard RFC, under the condition that the amended version of T.38 containing the RTP payload format is published by the ITU. Colin --> Colin Perkins writes: > This is to announce a last call for comments on the audio/t38 MIME type > registration. Please send comments to the mailing list by Friday 28th > November 2003. If no substantive comments are received by this time we > shall recommend the IESG publish this draft as a Proposed standard RFC, > conditional on the publication of the amended version of T.38 by the ITU. > > Colin > > > > ------- Forwarded message: > >Date: Wed, 19 Nov 2003 15:25:59 -0500 > >From: Internet-Drafts@ietf.org > >To: IETF-Announce: > >Cc: avt@ietf.org > >Subject: [AVT] I-D ACTION:draft-jones-avt-audio-t38-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Real-Time Facsimile (T.38) - audio/t38 MIME > > Sub-type Registration > > Author(s) : P. Jones > > Filename : draft-jones-avt-audio-t38-02.txt > > Pages : 6 > > Date : 2003-11-19 > > > > This document defines the MIME sub-type audio/t38. The packetization > > and usage of this MIME type, which is intended for use within SDP, is > > specified within ITU-T Recommendation T.38. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-02.txt > ... > ------- End of Forwarded Message > > -- > Colin Perkins > csp@csperkins.org > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 14:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29916 for ; Sun, 7 Dec 2003 14:14:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4M2-0005gN-FV for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 14:14:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7JE6x5021822 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 14:14:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4Lx-0005fR-1B; Sun, 07 Dec 2003 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4La-0005fA-Ln for avt@optimus.ietf.org; Sun, 07 Dec 2003 14:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29871 for ; Sun, 7 Dec 2003 14:13:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT4LY-00047V-00 for avt@ietf.org; Sun, 07 Dec 2003 14:13:36 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AT4LX-00047H-00 for avt@ietf.org; Sun, 07 Dec 2003 14:13:35 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62533 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AT4L2-0001aR-00; Sun, 07 Dec 2003 19:13:04 +0000 Date: Sun, 7 Dec 2003 19:13:02 +0000 From: Colin Perkins To: "Rolf Hakenberg" Cc: gamze@vidiator.com, rey@panasonic.de, avt@ietf.org, David.Leon@nokia.com, viktor.varsa@nokia.com, magnus.westerlund@era.ericsson.se Subject: Re: [AVT] Retransmission draft Message-Id: <20031207191302.665669f8.csp@csperkins.org> In-Reply-To: References: <787ED0EC136B854DB341E7662D666CD66137E8@bels002.mediator.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> "Rolf Hakenberg" writes: > Dear Gamze and all, > > Although I believe that the concerns expressed in 3GPP on server > complexity and delay are less relevant for our discussion on potential > IPRs, please let me clarify the agreement in 3GPP. > > At the last 3GPP SA4 meeting there was a consensus on to make RTP > Retransmission a working assumption in PSS Rel-6, subject to the concerns > on server complexity and delay being addressed at the next meeting. Do you expect addressing these concerns to require changes to the draft? > Important for our current discussion on potential IPRs and how to > progress the draft is the fact that there was no condition on the IPR > issues, but in fact conditions that the draft should move to RFC on > standards track before the finalisation of 3GPP Rel-6. Moving to the standards track requires resolution of the IPR issue within AVT, of course. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 14:24:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00112 for ; Sun, 7 Dec 2003 14:24:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4Vf-000652-GN for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 14:24:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7JO39A023335 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 14:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4Vd-000629-Mv; Sun, 07 Dec 2003 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT4VI-00061L-Vh for avt@optimus.ietf.org; Sun, 07 Dec 2003 14:23:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00102 for ; Sun, 7 Dec 2003 14:23:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT4VG-0004E2-00 for avt@ietf.org; Sun, 07 Dec 2003 14:23:38 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AT4VF-0004Ds-00 for avt@ietf.org; Sun, 07 Dec 2003 14:23:38 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62536 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AT4Um-0001dI-00; Sun, 07 Dec 2003 19:23:08 +0000 Date: Sun, 7 Dec 2003 19:23:06 +0000 From: Colin Perkins To: Cc: avt@ietf.org Subject: Re: [AVT] Retransmission draft Message-Id: <20031207192306.66493533.csp@csperkins.org> In-Reply-To: <00af01c3ba86$ff0a1260$05640a0a@panasonic.de> References: <20031204145924.23d2dc61.csp@csperkins.org> <00af01c3ba86$ff0a1260$05640a0a@panasonic.de> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --> Jos=E9 Rey writes: ... > > > In order to make this situation clear to anybody who reads the RTP > > > retransmission draft, we suggest to add a paragraph at the very > > > beginning of the draft. This paragraph will make implementors aware > > > of the situation that the solution described in this draft is > > > possibly encumbered by IPRs. Furthermore it will point implementors > > > to non-IPR-encumbered solutions as above, which may perfectly be used > > > instead of RTP retransmission. > > > > Without seeing the wording of this paragraph, I can't give a > > definitive answer, but that would largely address my concerns. >=20 > right, how about this: >=20 > "This document provides an RTP packet retransmission mechanism for repair > of streaming media. The purpose of this paragraph is to make the reader > aware that the retransmission mechanism described in this document may be > encumbered by patent applications filed from Matsushita. For details on > the IPR statement, please visit the IETF IPR web page > http://www.ietf.org/ietf/IPR. >=20 > However, packet retransmission is not the only means for streaming > clients and servers to cope with packet losses. A detailed description > of options for repair of streaming media is given in RFC2354. Therefore, > implementers of this protocol shall take into account that there are in > fact other mechanisms, such as forward error correction (FEC) or packet > interleaving that represent an alternative to solve the problems packet > retransmission tries to solve. In particular RFC2733 and RFC2198 > present FEC and redundant packet transmission schemes that might well fit > to the needs of the implementer. " [takes working group chair hat off] This, at least, would stop accidental infringement which is one of my main concerns. I would still strongly prefer a royalty-free license, however. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 7 18:57:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08285 for ; Sun, 7 Dec 2003 18:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT8ly-0005MZ-Un for avt-archive@odin.ietf.org; Sun, 07 Dec 2003 18:57:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7NvA6F020609 for avt-archive@odin.ietf.org; Sun, 7 Dec 2003 18:57:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT8lp-0005Lm-T1; Sun, 07 Dec 2003 18:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASyaq-0003XP-Nq for avt@optimus.ietf.org; Sun, 07 Dec 2003 08:05:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22782; Sun, 7 Dec 2003 08:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASyao-0000qC-00; Sun, 07 Dec 2003 08:04:58 -0500 Received: from orion.lrg.ufsc.br ([150.162.63.1] helo=lrg.ufsc.br) by ietf-mx with esmtp (Exim 4.12) id 1ASyan-0000q8-00; Sun, 07 Dec 2003 08:04:57 -0500 Received: from localhost (westphal@localhost) by (8.9.3+Sun/8.9.3) with ESMTP id LAA26270 Date: Sun, 7 Dec 2003 11:04:09 -0400 (WST) From: Carlos Becker Westphall To: Undisclosed recipients: ; Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [AVT] 9th Brazilian Workshop on Network & Services Operations & Management Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE * Apologies if you receive multiple copies of this announcement * WGRS - Workshop on Network & Services Operations & Management The 9th Brazilian Workshop on Network & Services Operations & Management (WGRS'2004) is an annual event that has been held since 1995. Previously known as WTMN (Workshop on Telecommunication Networks & Services Management), the event has been held either with the Brazilian Symposium on Computer Networks (SBRC) or with the Latin American Network Operations and Management Symposium (LANOMS). The main goal of WGRS is to provide a Brazilian forum in the area of network management focused on the local audience, involving networking and telecommunication companies, academic institutions, service providers and equipment vendors.=20 This year, in its 9th edition, WGRS will take place in Gramado - Rio Grande do Sul, during the 22th SBRC . Besides the presentation of papers describing research results, on-going projects and practical experience reports, a number of invited keynotes from the industry is also planned. Topics of interest include, but are not limited to: * Integrating Intrusion Detection and Network Management * Intrusion Policy Management * Web Services Security * Mobile/Wireless Network Management * Business and Service Management * Management Platforms, Interoperability, Standards and Protocols * Management of Networks and Services: VPNs, Optical Networks, CATV Networks, Mobile and Ad-Hoc Networks, Voice over IP, Transaction- Oriented Services, Electronic Commerce, Active and Programmable Networks, Sensor Networks * Management Technologies and Frameworks (Web, XML, CORBA, DEN, etc) * Management Aspects of Service Pricing, Accounting and Billing * Management of Service Level Agreements and Quality of Service * Data Warehousing and Data Mining in Management * Programmable, Mobile and Intelligent Agents in Management * Network and Systems Monitoring * Fault and Performance Management * Security Management * Configuration Management and Policy-Driven Management * Information Modeling * Traffic and Performance Management * Open-Source Management Software * Management of Grid Computing, Clusters, Peer-to-Peer Applications, and Ubiquitous Computing Environments * Operations Support Systems * Business Processes for Network and Service Management * Peer-to-peer Network Technologies for Management * Management of Distributed Systems * Case Studies and Experiences in Management Paper Submission Submitted manuscripts must be written in either English, Spanish or Portuguese and the text should not exceed 8 pages, including the abstract, figures, diagrams, references, etc (very small figures, as well as bitmap format should be avoided). The page format should be A4 (29.7 x 21.0 cm), font size 12 pts, Times, lateral margins 2.5 cm, upper margin 3.0 cm, lower margin 2.5 cm, with 12pt Times fonts, single column page with no more than 45 lines. The paper can be prepared using one of the templates avaliable in the SBC webpage (http://www.sbc.org.br). The paper must be submitted eletronically through EDAS (at http://soyuz.metropoa.tche.br/sbrc2004_wgrs). The file must be necessarily in the postscript format (use generic postscript) or PDF (Portable Document Format).

Program Committee * Ant=F4nio A. F. Loureiro (UFMG) loureiro@dcc.ufmg.br * Bruno Schulze (LNCC) schulze@lncc.br * Carlos B. Westphall (UFSC) westphal@lrg.ufsc.br * Carlos de Castro Goulart (UFV) goulart@dpi.ufv.br * Edmundo R. M. Madeira (UNICAMP) edmundo@ic.unicamp.br * Elias P. Duarte Jr. (UFPR) elias@inf.ufpr.br=20 * Elizabeth S. Specialski (UFSC) beth@inf.ufsc.br * Iara Machado (RNP) iara@rnp.br * Jos=E9 N. de Souza (UFC) neuman@ufc.br * Jos=E9 Marcos Silva Nogueira jmarcos@dcc.ufmg.br * Keiko V. O. Fonseca (CEFET/PR) keiko@cpgei.cefetpr.br * Liane M. R. Tarouco (UFRGS) liane.tarouco@ufrgs.br * Lisandro Z. Granville (UFRGS) granville@inf.ufrgs.br * Luciano P. Gaspary (UNISINOS) paschoal@exatas.unisinos.br * Luiz Nacamura Jr. (CEFET/PR) nacamura@cpgei.cefetpr.br Important Dates=20 * Paper Submission March 11 2004 * Notification April 8 2004 * Camera-Ready due April 15 2004 Workshop Chair * Elias P. Duarte Jr. (UFPR) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 05:36:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04126 for ; Mon, 8 Dec 2003 05:36:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIkU-00008Z-Rp for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 05:36:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8AaIqt000526 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 05:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIkC-00007a-TF; Mon, 08 Dec 2003 05:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIjk-000076-Oe for avt@optimus.ietf.org; Mon, 08 Dec 2003 05:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04112 for ; Mon, 8 Dec 2003 05:35:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATIjh-0000aa-00 for avt@ietf.org; Mon, 08 Dec 2003 05:35:29 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1ATIjg-0000aO-00 for avt@ietf.org; Mon, 08 Dec 2003 05:35:28 -0500 Received: from mcomreyj1 ([10.10.100.5]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Dec 2003 11:35:04 +0100 Reply-To: From: "Jose Rey" To: Cc: Subject: RE: [AVT] Retransmission draft Date: Mon, 8 Dec 2003 11:35:02 +0100 Message-ID: <00d201c3bd76$f0ea3fa0$05640a0a@panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: <184670-220031244174931954@M2W071.mail2web.com> Importance: Normal X-OriginalArrivalTime: 08 Dec 2003 10:35:04.0521 (UTC) FILETIME=[F1187B90:01C3BD76] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA04113 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Vinay, thanks for your feedback. Let me try to clarify: the statement says there are other alternatives to solve the problems the retransmission addresses. However, this doesn't mean that these other solutions are better or worse. It is a matter of trade-off between, e.g., client/server complexity, buff= er space and bit rate available. And these depend on your scenario (!). Typically, FEC and packet interleaving schemes offer less protection for = the same available bitrate, as pro-active schemes send redundant packets in advance. You also need to XOR-encode and -decode packets. FEC and packet interleaving have a fixed repetition scheme, which means that packets are repeated a fixed number of times (whether they are lost or not!) whereas retransmission is more flexible here by allowing each lost packet to be retransmitted as often as necessary within the given timing constraints. = An advantage of pro-active schemes might be that they don't require a feedba= ck channel. On the other hand, retransmission of packets will use just the bandwidth necessary to re-send lost packets. You can also incorporate packet scheduling into your retransmission server, which may enhance the quality at the client. In summary, you shall carefully address your need= s and evaluate which solution delivers the best compromise. You may want to read RFC2354 which describes how to approach such a decision. Hope this helps, Jos=E9 > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of > vsathe@san.rr.com > Sent: Thursday, December 04, 2003 6:50 PM > To: avt@ietf.org > Subject: RE: [AVT] Retransmission draft > > > With this disclaimer, I am now confused about the prespective > with which I > should read this draft as a (potential) implementator. I > understand that > Matsushita may have some IPR in this submission. But now are > you saying > that you really don't know why anyone should use this scheme? > Would it be > possible to give a scenario or two where the proposed mechanism may be > superior to follow? What is the point in sending this off to IETF RFC > track? > > Thanks in advance for your explanation. > > Vinay Sathe > Multirate Systems > > right, how about this: > > "This document provides an RTP packet retransmission > mechanism for repair of > streaming media. The purpose of this paragraph is to make > the reader aware > that the retransmission mechanism described in this document may be > encumbered by patent applications filed from Matsushita. For > details on the > IPR statement, please visit the IETF IPR web page > http://www.ietf.org/ietf/IPR. > > However, packet retransmission is not the only means for > streaming clients > and servers to cope with packet losses. A detailed > description of options > for repair of streaming media is given in RFC2354. > Therefore, implementers > of this protocol shall take into account that there are in fact other > mechanisms, such as forward error correction (FEC) or packet > interleaving > that represent an alternative to solve the problems packet > retransmission > tries to solve. In particular RFC2733 and RFC2198 present FEC and > redundant packet transmission schemes that might well fit to > the needs of > the implementer. " > > Jos=E9 > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 05:47:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04623 for ; Mon, 8 Dec 2003 05:47:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIuu-0000iq-6p for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 05:47:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Al41c002727 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 05:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIur-0000hT-4j; Mon, 08 Dec 2003 05:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATIuT-0000gt-RM for avt@optimus.ietf.org; Mon, 08 Dec 2003 05:46:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04544 for ; Mon, 8 Dec 2003 05:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATIuQ-0000lz-00 for avt@ietf.org; Mon, 08 Dec 2003 05:46:34 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ATIuP-0000kv-00 for avt@ietf.org; Mon, 08 Dec 2003 05:46:33 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63279 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ATItu-00038C-00; Mon, 08 Dec 2003 10:46:03 +0000 Date: Mon, 8 Dec 2003 10:46:01 +0000 From: Colin Perkins To: Cc: vsathe@san.rr.com, avt@ietf.org Subject: Re: [AVT] Retransmission draft Message-Id: <20031208104601.01429f16.csp@csperkins.org> In-Reply-To: <00d201c3bd76$f0ea3fa0$05640a0a@panasonic.de> References: <184670-220031244174931954@M2W071.mail2web.com> <00d201c3bd76$f0ea3fa0$05640a0a@panasonic.de> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jose, --> "Jose Rey" writes: > thanks for your feedback. Let me try to clarify: the statement says there > are other alternatives to solve the problems the retransmission > addresses. However, this doesn't mean that these other solutions are > better or worse. It is a matter of trade-off between, e.g., client/server > complexity, buffer space and bit rate available. And these depend on > your scenario (!). Typically, FEC and packet interleaving schemes offer > less protection for the same available bitrate, as pro-active schemes > send redundant packets in advance. You also need to XOR-encode and > -decode packets. FEC and packet interleaving have a fixed repetition > scheme, which means that packets are repeated a fixed number of times > (whether they are lost or not!) whereas retransmission is more flexible > here by allowing each lost packet to be retransmitted as often as > necessary within the given timing constraints. An advantage of > pro-active schemes might be that they don't require a feedback channel. Note that there's nothing in RFC 2733 that requires FEC to be sent with a fixed repetition scheme. One could imagine a scenario where the receiver used the RTCP feedback extensions to inform the sender of loss, and the sender then generated FEC packets on demand to correct that loss... Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 11:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16000 for ; Mon, 8 Dec 2003 11:07:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNug-00058D-8X for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 11:07:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8G78N2019577 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 11:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNuX-00053T-Iq; Mon, 08 Dec 2003 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATNuQ-00052z-MQ for avt@optimus.ietf.org; Mon, 08 Dec 2003 11:06:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15962; Mon, 8 Dec 2003 11:06:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATNuO-000786-00; Mon, 08 Dec 2003 11:06:52 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATNuN-000781-00; Mon, 08 Dec 2003 11:06:51 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04141; Mon, 8 Dec 2003 11:06:17 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00273; Mon, 8 Dec 2003 11:06:18 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 11:06:18 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B619F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mallman@icir.org'" Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 11:06:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is why slow start won't work. The media starts with constant rate. If you have to slow start, you have to either drop packets or you have to buffer them, and as I have pointed out, once you buffer CBR, you keep it. The delay introduced is worse than the buffer, so you will drop packets to make slow start, and clip the "hello". What you are saying, it seems to me, is that we have solved existing problems by deploying slow start. All the applications so far have judged slow start as acceptable. Along comes real time interactive media, and we say sorry, slow start is not acceptable. And you want to claim then that our applications can't be used on the Internet? I would say that you haven't a prayer of stopping us. We can address congestion collapse another way, so you can't use that as an excuse over why we need to move off of UDP. I think those of us with real time interactive media are very willing to adopt additional congestion control mechanisms that attempt to deal with "fairness" (which is not viewed the same way by TCP and real time media), so long as they don't destroy the app. However, we aren't likely to adopt anything replacing UDP if it does destroy the app. Brian > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Monday, December 08, 2003 10:00 AM > To: Rosen, Brian > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > distribution? > > > > (gluing together two things that I can't get to jive together in my > head) > > > A typical RTT on the internet these days is 50-100 ms. If you > > experience 30% loss in the first 3 RTTs of voice, you will clip the > > "hello" pretty badly. If it's 7-8 RTTs, you will definitely have a > > very poor experience. > > I do not understand where this 30% loss number comes from. If a host > experiences 30% loss the network is *quite* congested (recent > measurments I have done show that loss rate over 10% are very rare in > the Internet) or the connection is crossing a very ratty error-prone > link. I think the latter is unlikely in the general case. So, how > would this: > > > Yep; bang! 0 to 4Mbit in two packets. > > be useful? If you're already clipping "hello" then this is going to > provide a very lousy experience, right? > > Others have said it already, so I'll just briefly agree: In a > best-effort network I do not think any particular flow (TCP or DCCP or > UDP or SCTP or whatever) should be able to just start sending > at a "high > rate" (where "high rate" is undefined, but 4Mbps is certainly > high). I > think it would not be terribly difficult to show that such behavior > could easily cause problems (to competing TCP, to competing streaming > flows and to the flow that is doing this "instant on"). Slow start is > the current consensus for how to start from zero. Could > there be other > schemes? Sure. Are those here and fully fleshed out such > that we could > even consider them as potential solutions? Not right now. > > My hunch is that sending DCCP (/anything) through without > slow start is > not going to work (i.e., I think consensus would be against > that). So, > if your app can't deal with that then I think we might be stuck ... A > more general wondering of mine is how many streaming apps require this > "instant on" behavior (i.e., is your app an anomaly or is > there a whole > class of apps that want instant-on over best-effort networks?)? > > Thanks! > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 11:29:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17216 for ; Mon, 8 Dec 2003 11:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOFy-0005ze-0Z for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 11:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8GT91C022989 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 11:29:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOFp-0005xr-Bq; Mon, 08 Dec 2003 11:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOFQ-0005xH-OP for avt@optimus.ietf.org; Mon, 08 Dec 2003 11:28:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17177 for ; Mon, 8 Dec 2003 11:28:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATOFP-0007ck-00 for avt@ietf.org; Mon, 08 Dec 2003 11:28:35 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ATOFP-0007cX-00 for avt@ietf.org; Mon, 08 Dec 2003 11:28:35 -0500 Received: from mangole ([130.209.247.112]:2478 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ATOEu-00056y-00 for avt@ietf.org; Mon, 08 Dec 2003 16:28:04 +0000 Date: Mon, 8 Dec 2003 16:28:04 +0000 From: Colin Perkins To: avt@ietf.org Message-Id: <20031208162804.42716619.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Fw: Last Call: 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration' to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI ------- Forwarded message: >Date: Mon, 08 Dec 2003 11:02:05 -0500 >From: The IESG >To: IETF-Announce :; >Cc: >Subject: Last Call: 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type >Registration' to Proposed Standard > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration ' > as a Proposed Standard > > Though this is an individual submission, it has been reviewed and > supported by the Audio Video Transport Working Group. > > 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 2004-01-05. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-03.txt > ------- End of Forwarded Message _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 11:45:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17699 for ; Mon, 8 Dec 2003 11:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOVM-0006uO-CY for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 11:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Gj4CE026509 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 11:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOVJ-0006sH-N7; Mon, 08 Dec 2003 11:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMrr-0000u6-OU for avt@optimus.ietf.org; Mon, 08 Dec 2003 10:00:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11412; Mon, 8 Dec 2003 09:59:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATMrp-0005R2-00; Mon, 08 Dec 2003 10:00:09 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1ATMrp-0005QK-00; Mon, 08 Dec 2003 10:00:09 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 883F177A3CE; Mon, 8 Dec 2003 09:59:33 -0500 (EST) To: "Rosen, Brian" From: Mark Allman Reply-To: mallman@icir.org Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? In-Reply-To: <313680C9A886D511A06000204840E1CF070B6163@whq-msgusr-02.pit.comms.marconi.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wishlist Date: Mon, 08 Dec 2003 09:59:33 -0500 Message-Id: <20031208145933.883F177A3CE@guns.icir.org> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , (gluing together two things that I can't get to jive together in my head) > A typical RTT on the internet these days is 50-100 ms. If you > experience 30% loss in the first 3 RTTs of voice, you will clip the > "hello" pretty badly. If it's 7-8 RTTs, you will definitely have a > very poor experience. I do not understand where this 30% loss number comes from. If a host experiences 30% loss the network is *quite* congested (recent measurments I have done show that loss rate over 10% are very rare in the Internet) or the connection is crossing a very ratty error-prone link. I think the latter is unlikely in the general case. So, how would this: > Yep; bang! 0 to 4Mbit in two packets. be useful? If you're already clipping "hello" then this is going to provide a very lousy experience, right? Others have said it already, so I'll just briefly agree: In a best-effort network I do not think any particular flow (TCP or DCCP or UDP or SCTP or whatever) should be able to just start sending at a "high rate" (where "high rate" is undefined, but 4Mbps is certainly high). I think it would not be terribly difficult to show that such behavior could easily cause problems (to competing TCP, to competing streaming flows and to the flow that is doing this "instant on"). Slow start is the current consensus for how to start from zero. Could there be other schemes? Sure. Are those here and fully fleshed out such that we could even consider them as potential solutions? Not right now. My hunch is that sending DCCP (/anything) through without slow start is not going to work (i.e., I think consensus would be against that). So, if your app can't deal with that then I think we might be stuck ... A more general wondering of mine is how many streaming apps require this "instant on" behavior (i.e., is your app an anomaly or is there a whole class of apps that want instant-on over best-effort networks?)? Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 12:06:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18542 for ; Mon, 8 Dec 2003 12:06:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOpg-0008Db-6m for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 12:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8H64JC031590 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 12:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOpe-0008Cg-Lg; Mon, 08 Dec 2003 12:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOp5-0008A3-78 for avt@optimus.ietf.org; Mon, 08 Dec 2003 12:05:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18452; Mon, 8 Dec 2003 12:05:10 -0500 (EST) From: matthew.d.walker@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATOp3-0000MP-00; Mon, 08 Dec 2003 12:05:25 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1ATOp3-0000LN-00; Mon, 08 Dec 2003 12:05:25 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Dec 2003 17:04:53 +0000 Received: from i2km11-ukbr.domain1.systemhost.net ([193.113.197.28]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Dec 2003 17:04:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Date: Mon, 8 Dec 2003 17:04:52 -0000 Message-ID: <7497DCA1C240C042B28F6657ADFD8E09049AA792@i2km11-ukbr.domain1.systemhost.net> Thread-Topic: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Thread-Index: AcO9qrJp6h8Zs41JRMGmgzjy2JH8hQAAZrrg To: Cc: , X-OriginalArrivalTime: 08 Dec 2003 17:04:52.0935 (UTC) FILETIME=[65AD3D70:01C3BDAD] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mark, very interesting reading this - in paticular, your comment: "A more general wondering of mine is how many streaming apps require = this "instant on" behavior (i.e., is your app an anomaly or is there a whole class of apps that want instant-on over best-effort networks?)?" I totally agree. Whilst "instant on" is really important [at the = application layer] for streaming / VoD applications with trick-modes = such as fast-forward, rewind, etc. (don't want buffering every time you = want to scan / hop channel etc.) it should be up to the application to = provide that type of functionality. It should not be up to the network / = transport to cater for this. With the new video codecs that are coming on-line (H.264 / MPEG4 pt10) = and the associated streaming profiles (which enable a streaming = application to switch between encoded data-rates) it should be = reasonable to design streaming apps that will provide near-instant on, = but still adhere to the slow-start rules of whatever the transport = protocol offers. So, it is my belief that streaming apps do not require instant-on = throughput, and should adhere to the same rules as other applications. rgds Matt Walker=20 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Mark Allman Sent: 08 December 2003 15:00 To: Rosen, Brian Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution?=20 (gluing together two things that I can't get to jive together in my head)=20 > A typical RTT on the internet these days is 50-100 ms. If you > experience 30% loss in the first 3 RTTs of voice, you will clip the > "hello" pretty badly. If it's 7-8 RTTs, you will definitely have a > very poor experience. I do not understand where this 30% loss number comes from. If a host experiences 30% loss the network is *quite* congested (recent measurments I have done show that loss rate over 10% are very rare in the Internet) or the connection is crossing a very ratty error-prone link. I think the latter is unlikely in the general case. So, how would this: > Yep; bang! 0 to 4Mbit in two packets. be useful? If you're already clipping "hello" then this is going to provide a very lousy experience, right? Others have said it already, so I'll just briefly agree: In a best-effort network I do not think any particular flow (TCP or DCCP or UDP or SCTP or whatever) should be able to just start sending at a "high rate" (where "high rate" is undefined, but 4Mbps is certainly high). I think it would not be terribly difficult to show that such behavior could easily cause problems (to competing TCP, to competing streaming flows and to the flow that is doing this "instant on"). Slow start is the current consensus for how to start from zero. Could there be other schemes? Sure. Are those here and fully fleshed out such that we could even consider them as potential solutions? Not right now. =20 My hunch is that sending DCCP (/anything) through without slow start is not going to work (i.e., I think consensus would be against that). So, if your app can't deal with that then I think we might be stuck ... A more general wondering of mine is how many streaming apps require this "instant on" behavior (i.e., is your app an anomaly or is there a whole class of apps that want instant-on over best-effort networks?)? Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 12:08:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18670 for ; Mon, 8 Dec 2003 12:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOrk-0000Gx-KI for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 12:08:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8H8COp000821 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 12:08:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOrb-00007F-G7; Mon, 08 Dec 2003 12:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOr4-0008Nm-6A for avt@optimus.ietf.org; Mon, 08 Dec 2003 12:07:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18596; Mon, 8 Dec 2003 12:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATOr2-0000PM-00; Mon, 08 Dec 2003 12:07:28 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ATOr1-0000PH-00; Mon, 08 Dec 2003 12:07:28 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB8H7JI2014591; Mon, 8 Dec 2003 18:07:20 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW74F36G; Mon, 8 Dec 2003 18:07:19 +0100 Message-ID: <3FD4AFC8.7090001@ericsson.com> Date: Mon, 08 Dec 2003 18:07:20 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: "Rosen, Brian" , "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? References: <20031208163629.F1C3177A3CE@guns.icir.org> In-Reply-To: <20031208163629.F1C3177A3CE@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > And, I'd still love to hear from others as to whether this "instant-on" > is a requirement across the board or whether you're a special case. Okay, my view on this topic about the instant-on is the following. Streaming applications, i.e. with buffers, should do reasonably well with a slow start as it will most likely only effect the initial buffering delay. When it comes to interactive real-time applications, i.e. without buffers, I think the Brian's view is mostly correct. All applications in this area does need to try to transmit at there lowest supported bit-rate initially. Then the question is what the lowest bit-rate is. It is not 4 mbit as somebody claimed for a high-rate conferencing application. Because in that case there exist techniques that will allow one to use a slow starting type of performance, which trades initial video quality against bandwidth during the slow start. For the 4 mbit video stream the initial bit-rate may be 256-512 kbits or possibly even lower. This will be a very coarse quality. but as one continues to transmit during the slow start and discover more bit-rate one can increase the quality. And I don't see this as having the same user problems as bit-rate switching is claimed to have. I think that any user of a circuit switched video telephony client are rather used to this behaviour, when major changes in video happens. It will be a bigger problem for certain high quality audio codecs that are used. If the codec does not support to do bit-rate/quality trade-offs then it probably not very suitable for usage in these best effort networks. There exist codecs that will allow reasonable bit-rate steps to be used. I think that the realistic thing in this environment is to be reasonable in both directions. I think that one has to understand that one a best effort network the media apps can't continue to behave irresponsible and simply blast away with UDP. It is better to start accept the fact that there will be need for a trade off. Then, if one needs to blast away, then one needs to develop more solutions or use resource reservation. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 12:30:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17700 for ; Mon, 8 Dec 2003 11:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOVM-0006uf-D5 for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 11:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Gj4Cv026511 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 11:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATOVL-0006t1-QA; Mon, 08 Dec 2003 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATONc-0006D5-DE for avt@optimus.ietf.org; Mon, 08 Dec 2003 11:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17422; Mon, 8 Dec 2003 11:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATONZ-0007jy-00; Mon, 08 Dec 2003 11:37:01 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1ATONZ-0007il-00; Mon, 08 Dec 2003 11:37:01 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id F1C3177A3CE; Mon, 8 Dec 2003 11:36:29 -0500 (EST) To: "Rosen, Brian" From: Mark Allman Reply-To: mallman@icir.org Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? In-Reply-To: <313680C9A886D511A06000204840E1CF070B619F@whq-msgusr-02.pit.comms.marconi.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wishlist Date: Mon, 08 Dec 2003 11:36:29 -0500 Message-Id: <20031208163629.F1C3177A3CE@guns.icir.org> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > What you are saying, it seems to me, is that we have solved existing > problems by deploying slow start. All the applications so far have > judged slow start as acceptable. Along comes real time interactive > media, and we say sorry, slow start is not acceptable. No, I was not saying that slow start has solved all the problems. Are there potential other methods to do startup? Certainly there are. Are there new reasons to think about different ways to startup? Probably. But, I don't think any new startup method is currently baked enough (and, certainly I don't think any of them have been introduced in the IETF as baked and ready to go). That does not mean that I think slow start is the way to go forever. That is just a pragmatic statement of my feeling that the consensus of the community is that slow start is the way to initiate transmission in the current best-effort Internet. > And you want to claim then that our applications can't be used on the > Internet? > > I would say that you haven't a prayer of stopping us. Look, I'm not trying to pick a fight. This Internet thing is a big cooperative. You are writing an app. I cannot stop you from writing it or running it on the public Internet. But, if the app does bad things to networks then the operators can and will do something about it. (E.g., look at what has been done to p2p stuff on college campuses.) And, we know that CBR UDP apps have the potential to do a bunch of damage. So, it seems that DCCP has its place. > We can address congestion collapse another way, so you can't use that > as an excuse over why we need to move off of UDP. I think those of us > with real time interactive media are very willing to adopt additional > congestion control mechanisms that attempt to deal with "fairness" > (which is not viewed the same way by TCP and real time media), so long > as they don't destroy the app. However, we aren't likely to adopt > anything replacing UDP if it does destroy the app. "Destroy the app" is one end of the spectrum, I think. "Not impact the app at all" is the other. And, the answer is likely somewhere in between. In the end, congestion control is not about getting exactly what each app desires. It's about keeping the network working in a reasonable fashion so that all the apps get reasonable performance. And, I'd still love to hear from others as to whether this "instant-on" is a requirement across the board or whether you're a special case. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 12:52:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20954 for ; Mon, 8 Dec 2003 12:52:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPYB-0002yF-OM for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 12:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Hq3ca011381 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 12:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPY8-0002wY-UT; Mon, 08 Dec 2003 12:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATPXO-0002vI-Hm for avt@optimus.ietf.org; Mon, 08 Dec 2003 12:51:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20890; Mon, 8 Dec 2003 12:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATPXM-0001Nt-00; Mon, 08 Dec 2003 12:51:12 -0500 Received: from mail.cs.tu-berlin.de ([130.149.17.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ATPXM-0001Nq-00; Mon, 08 Dec 2003 12:51:12 -0500 Received: from hobel.cs.tu-berlin.de (stewe@jeder.cs.tu-berlin.de [130.149.17.59]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id SAA19362; Mon, 8 Dec 2003 18:47:49 +0100 (MET) Message-Id: <6.0.0.22.2.20031208094352.0306b6d0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 08 Dec 2003 09:47:22 -0800 To: matthew.d.walker@bt.com From: Stephan Wenger Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Cc: , , In-Reply-To: <7497DCA1C240C042B28F6657ADFD8E09049AA792@i2km11-ukbr.domai n1.systemhost.net> References: <7497DCA1C240C042B28F6657ADFD8E09049AA792@i2km11-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Matthew, At 09:04 AM 12/8/2003, matthew.d.walker@bt.com wrote: >With the new video codecs that are coming on-line (H.264 / MPEG4 pt10) and >the associated streaming profiles (which enable a streaming application to >switch between encoded data-rates) it should be reasonable to design >streaming apps that will provide near-instant on, but still adhere to the >slow-start rules of whatever the transport protocol offers. While I'm a big fan of the extended profile of H.264, and particularly the SI/SP picture technology, I do not believe that there will be any significant deployment of these technologies in the next few years. And even if there is, the problem of varying perceived qualities due to rate changes, and the related user acceptance problems, still exist. (The same is true for all these fancy layered coding concepts that are around since 10 years or so. There was never any significant deployment. I wonder, why.). Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 13:27:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22889 for ; Mon, 8 Dec 2003 13:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ6D-0005S8-WF for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 13:27:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8IRDv2020959 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 13:27:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ61-0005L7-T7; Mon, 08 Dec 2003 13:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQ5E-0005Ix-NR for avt@optimus.ietf.org; Mon, 08 Dec 2003 13:26:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22695; Mon, 8 Dec 2003 13:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5C-00024C-00; Mon, 08 Dec 2003 13:26:10 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATQ5C-00022x-00; Mon, 08 Dec 2003 13:26:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08912; Mon, 8 Dec 2003 13:25:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21456; Mon, 8 Dec 2003 13:25:37 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 13:25:37 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61A5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Magnus Westerlund'" , mallman@icir.org Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 13:25:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Magnus You saw the message from Henning on the effect of slow start on conferencing applications didn't you? What makes you think the video is any different? In a conference application, streams come and go as different speakers come and go. Even in a centrally mixed conference, which is not as demanding as an end-system mixed conference, most participants are not talking, and not sending video. When they start talking, the start sending media, voice and video. To send media all the time unnecessarily uses bandwidth; a lot of it. We don't do this now, we are end system mixed. Even your basic assumption that coarse video is acceptable for a while is not true; it looks very poor. Actually, I'm not aware of any conferencing video systems that ramp bandwidth. The reason is that the codecs are parameterized for a given quality level/bandwidth, and you can't smoothly change the parameters - you set them and restart the codec. I suspect that you could design a codec to smoothly ramp, but that's not what we have available to us now. What you do see sometimes is a codec which has a fixed bandwidth but the algorithm itself sends coarse image more often than fine image, and you see that effect on startup. That is very undesirable, but it exists. Brian > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, December 08, 2003 12:07 PM > To: mallman@icir.org > Cc: Rosen, Brian; 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > Hi, > > > And, I'd still love to hear from others as to whether this > "instant-on" > > is a requirement across the board or whether you're a special case. > > Okay, my view on this topic about the instant-on is the following. > > Streaming applications, i.e. with buffers, should do reasonably well > with a slow start as it will most likely only effect the initial > buffering delay. > > When it comes to interactive real-time applications, i.e. without > buffers, I think the Brian's view is mostly correct. All > applications in > this area does need to try to transmit at there lowest supported > bit-rate initially. Then the question is what the lowest > bit-rate is. It > is not 4 mbit as somebody claimed for a high-rate conferencing > application. Because in that case there exist techniques that > will allow > one to use a slow starting type of performance, which trades initial > video quality against bandwidth during the slow start. For the 4 mbit > video stream the initial bit-rate may be 256-512 kbits or > possibly even > lower. This will be a very coarse quality. but as one continues to > transmit during the slow start and discover more bit-rate one can > increase the quality. And I don't see this as having the same user > problems as bit-rate switching is claimed to have. I think > that any user > of a circuit switched video telephony client are rather used to this > behaviour, when major changes in video happens. > > It will be a bigger problem for certain high quality audio > codecs that > are used. If the codec does not support to do bit-rate/quality > trade-offs then it probably not very suitable for usage in these best > effort networks. There exist codecs that will allow > reasonable bit-rate > steps to be used. > > I think that the realistic thing in this environment is to be > reasonable > in both directions. I think that one has to understand that > one a best > effort network the media apps can't continue to behave > irresponsible and > simply blast away with UDP. It is better to start accept the > fact that > there will be need for a trade off. Then, if one needs to blast away, > then one needs to develop more solutions or use resource reservation. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 13:49:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23726 for ; Mon, 8 Dec 2003 13:49:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQRL-0007EM-Sw for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 13:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8In32k027793 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 13:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQRJ-0007D7-5F; Mon, 08 Dec 2003 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQQe-00073z-TC for avt@optimus.ietf.org; Mon, 08 Dec 2003 13:48:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23692; Mon, 8 Dec 2003 13:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQQc-0002QN-00; Mon, 08 Dec 2003 13:48:18 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATQQc-0002Q4-00; Mon, 08 Dec 2003 13:48:18 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09672; Mon, 8 Dec 2003 13:47:43 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24823; Mon, 8 Dec 2003 13:47:43 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 13:47:43 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61A6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mallman@icir.org'" Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 13:47:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Henning had a message on these threads that pointed out that in conferencing, you don't send until you talk. On a conference with 100 participants, you only see 1-4 or so actually sending, but which 1-4 changes, sometimes rapidly. You can't slow start them when they start talking or you clip. Another example is Push To Talk. Another example of non-interactive media is channel surfing. This one depends somewhat on implementation, but many implementations have different channels coming from different servers. I don't want to seem unwilling to change our app, I am very willing to change the app to better work on the Internet, but not if it destroys the user experience. I don't see a way to do that without modifying TCP. If you assume TCP is fixed, and you need media apps to live with TCP as it is, I don't see how to do that, but I'm certainly eager to be shown how. My app is the 4M app, and there aren't many of us at the moment, but if you saw it, you'd want it, and there is no reason it shouldn't work on the Internet. It does now, after a fashion. And, as I've pointed out, since these kinds of apps represent much higher revenue per bit that the TCP-type apps, it's much more likely that the network operators would deploy TCP stompers than media stompers. YMMV. Brian > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Monday, December 08, 2003 11:36 AM > To: Rosen, Brian > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > > > What you are saying, it seems to me, is that we have solved existing > > problems by deploying slow start. All the applications so far have > > judged slow start as acceptable. Along comes real time interactive > > media, and we say sorry, slow start is not acceptable. > > No, I was not saying that slow start has solved all the problems. Are > there potential other methods to do startup? Certainly there > are. Are > there new reasons to think about different ways to startup? Probably. > But, I don't think any new startup method is currently baked enough > (and, certainly I don't think any of them have been introduced in the > IETF as baked and ready to go). That does not mean that I think slow > start is the way to go forever. That is just a pragmatic statement of > my feeling that the consensus of the community is that slow > start is the > way to initiate transmission in the current best-effort Internet. > > > And you want to claim then that our applications can't be > used on the > > Internet? > > > > I would say that you haven't a prayer of stopping us. > > Look, I'm not trying to pick a fight. This Internet thing is a big > cooperative. You are writing an app. I cannot stop you from > writing it > or running it on the public Internet. But, if the app does bad things > to networks then the operators can and will do something about it. > (E.g., look at what has been done to p2p stuff on college campuses.) > And, we know that CBR UDP apps have the potential to do a bunch of > damage. So, it seems that DCCP has its place. > > > We can address congestion collapse another way, so you > can't use that > > as an excuse over why we need to move off of UDP. I think > those of us > > with real time interactive media are very willing to adopt > additional > > congestion control mechanisms that attempt to deal with "fairness" > > (which is not viewed the same way by TCP and real time > media), so long > > as they don't destroy the app. However, we aren't likely to adopt > > anything replacing UDP if it does destroy the app. > > "Destroy the app" is one end of the spectrum, I think. "Not > impact the > app at all" is the other. And, the answer is likely somewhere in > between. > > In the end, congestion control is not about getting exactly what each > app desires. It's about keeping the network working in a reasonable > fashion so that all the apps get reasonable performance. > > And, I'd still love to hear from others as to whether this > "instant-on" > is a requirement across the board or whether you're a special case. > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 13:52:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23874 for ; Mon, 8 Dec 2003 13:52:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQUE-0007ft-5H for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 13:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Iq1gF029320 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 13:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQUC-0007cR-RO; Mon, 08 Dec 2003 13:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQTX-0007bw-Ad for avt@optimus.ietf.org; Mon, 08 Dec 2003 13:51:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23853; Mon, 8 Dec 2003 13:51:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQTU-0002TB-00; Mon, 08 Dec 2003 13:51:17 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ATQTU-0002Sa-00; Mon, 08 Dec 2003 13:51:16 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB8Iojwx018165; Mon, 8 Dec 2003 13:50:46 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 8 Dec 2003 13:50:38 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 13:50:37 -0500 Message-ID: From: "Phelan, Tom" To: "'Rosen, Brian'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 13:50:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Brian, > In a conference application, streams come and go as different speakers > come and go. Even in a centrally mixed conference, which is not > as demanding as an end-system mixed conference, most participants > are not talking, and not sending video. When they start talking, > the start sending media, voice and video. To send media all the > time unnecessarily uses bandwidth; a lot of it. I guess I've never used more-than-two site video conferencing. You're saying that when a site stops talking its video goes dark (or still)? Tom P. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 14:01:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24140 for ; Mon, 8 Dec 2003 14:01:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQcy-00087n-4D for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 14:01:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8J13l5031114 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 14:01:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQcv-00083P-VC; Mon, 08 Dec 2003 14:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQcG-00082O-Mr for avt@optimus.ietf.org; Mon, 08 Dec 2003 14:00:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24104; Mon, 8 Dec 2003 14:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQcE-0002ZH-00; Mon, 08 Dec 2003 14:00:18 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATQcD-0002Yt-00; Mon, 08 Dec 2003 14:00:17 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10037; Mon, 8 Dec 2003 13:59:44 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26588; Mon, 8 Dec 2003 13:59:45 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 13:59:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61A7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'matthew.d.walker@bt.com'" , mallman@icir.org Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 13:59:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > I totally agree. Whilst "instant on" is really important [at > the application layer] for streaming / VoD applications with > trick-modes such as fast-forward, rewind, etc. (don't want > buffering every time you want to scan / hop channel etc.) it > should be up to the application to provide that type of > functionality. It should not be up to the network / transport > to cater for this. Fast forward/rewind functions can probably maintain an existing stream, or even slow start. What wouldn't work is channel surfing. We know from experience that unless this is very fast, it's a big problem. The digital cable guys know that even the startup time of the MPEG codec is a problem for them, let alone additional delay caused by slow start. Usually, not all channels are served from the same server, so channel surfing has to start/stop streams fast. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 14:03:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24260 for ; Mon, 8 Dec 2003 14:03:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQes-0008PS-7g for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 14:03:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8J32iE032285 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 14:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQer-0008Nr-Bc; Mon, 08 Dec 2003 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATQeZ-0008Mq-5J for avt@optimus.ietf.org; Mon, 08 Dec 2003 14:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24230; Mon, 8 Dec 2003 14:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQeW-0002ct-00; Mon, 08 Dec 2003 14:02:40 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATQeW-0002ce-00; Mon, 08 Dec 2003 14:02:40 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10165; Mon, 8 Dec 2003 14:02:06 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27037; Mon, 8 Dec 2003 14:02:07 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 14:02:06 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61A8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 14:01:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Depends on the implementation. If you have 100 participants, not all of them are on the screen, only 2-10 or so are. When one of the participants that are not on screen start talking, they show up. Optimized implementations would not send the video unless you start talking in such a case. Imagine the effect of 100 participants even at 512K if 1/10 of them sent video vs all of them. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Monday, December 08, 2003 1:51 PM > To: 'Rosen, Brian' > Cc: avt@ietf.org; dccp@ietf.org > Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > Hi Brian, > > > In a conference application, streams come and go as > different speakers > > come and go. Even in a centrally mixed conference, which is not > > as demanding as an end-system mixed conference, most participants > > are not talking, and not sending video. When they start talking, > > the start sending media, voice and video. To send media all the > > time unnecessarily uses bandwidth; a lot of it. > > I guess I've never used more-than-two site video conferencing. You're > saying that when a site stops talking its video goes dark (or still)? > > Tom P. > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 17:58:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09253 for ; Mon, 8 Dec 2003 17:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUKP-0001iu-2V for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 17:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Mw9jJ006620 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 17:58:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUKI-0001fg-2t; Mon, 08 Dec 2003 17:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUKE-0001fF-J1 for avt@optimus.ietf.org; Mon, 08 Dec 2003 17:57:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09221; Mon, 8 Dec 2003 17:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUKB-0000fc-00; Mon, 08 Dec 2003 17:57:55 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATUKB-0000eu-00; Mon, 08 Dec 2003 17:57:55 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17460; Mon, 8 Dec 2003 17:57:22 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02260; Mon, 8 Dec 2003 17:57:24 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 17:57:23 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61AA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mallman@icir.org'" Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 17:57:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Mark The reality of networks these days is that plain jane best effort Internet doesn't make much money. Premium services do. So the trend, which is clearly not universal, but is pretty obvious, is that SPs are trying to bring new bandwidth users onto their networks where the extra bandwidth is not just more bits, but for which they can charge for service beyond best effort packet. Voice is one of those services, and video is one of those services. You don't see a whole lot of investment these days in plain Internet service, and you do in voice/video over IP networks. So, while there are pure play best effort operators out there, and they will be there, the money is in the premium services. Even if an ISP does not directly provide premium services, other SPs will, using the underlying packet carrier as the pipe, and the USERS of the premium services will yell loudly if their premium services are not delivering what they pay for. If a customer of voice/video service gets told that his pipe provider is intentionally degrading his service, what do you think he will do with his pipe business? Everyone agrees, I think, the most desirable situation is one in which we have a true converged network, not overlay networks, not separate networks, for these new services. I'm sure that there will be a lot of overlay networks around for quite a while, because we don't have the mechanisms we are discussing here - ways for classic best effort TCP to co-exist well with real time media. Everyone wins if we figure out good ways for this to happen. Everyone loses if any SP starts intentionally degrading one kind of service to make another kind of service work better. That's why I don't think it's going to be common to stomp on media OR TCP. Rather, I think everyone expects us to do our jobs well and make both kinds of streams work well together. We aren't going to solve this problem with anything done on one side folks; both sides are going to have to have new mechanisms. Brian > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Monday, December 08, 2003 5:02 PM > To: Rosen, Brian > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > > Brian- > > > And, as I've pointed out, since these kinds of apps represent much > > higher revenue per bit that the TCP-type apps, it's much more likely > > that the network operators would deploy TCP stompers than media > > stompers. YMMV. > > I saw your assertion in response to Sally a while back in this thread. > > But, I think we have a disconnect. I am generally thinking > in terms of > best-effort networks (as I think Sally was). Further, a network that > has no priorities or traffic classes, but rather just tries > its hardest > to get all the data across. This is the kind of network where > congestion control is important. And, this is the kind of > network where > I think you'll see "stompers" that attempt to surpress flows that are > attempting to use a disproportionate amount of the bandwdith (whether > that be streaming or mis-behaving TCP or ddos floods or whatever). > > Your claim above does not match my model of a best effort network. > I.e., if people are willing to pay more for the traffic of some > particular app and you provision appropriately then you no longer have > just a dumb best-effort network. If you can engineer a network and > provision appropriately then by all means use UDP and go from zero to > 4Mbps instantly. However, I don't see that as supporting the > assertion > that DCCP can't be used for streaming across best-effort networks that > are not engineered to give different levels of support to different > classes of traffic. > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 19:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16450 for ; Mon, 8 Dec 2003 19:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATW4l-0006ny-6b for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 19:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB90o7gE026154 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 19:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATW4g-0006mp-TL; Mon, 08 Dec 2003 19:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATW4U-0006lC-NG for avt@optimus.ietf.org; Mon, 08 Dec 2003 19:49:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16275; Mon, 8 Dec 2003 19:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATW4S-0003Bz-00; Mon, 08 Dec 2003 19:49:48 -0500 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATW4R-0003BP-00; Mon, 08 Dec 2003 19:49:47 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hB90nie9004067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Dec 2003 19:49:44 -0500 (EST) Message-ID: <3FD51C28.1040108@cs.columbia.edu> Date: Mon, 08 Dec 2003 19:49:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'mallman@icir.org'" , "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? References: <313680C9A886D511A06000204840E1CF070B61AA@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B61AA@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the whole notion of fairness and value also needs to be looked at in a more differentiated fashion. Some of this has been alluded to, by Mark and others, but there seem to be at least three bottleneck cases: - single subscriber bottlenecks, such as my DSL uplink; there, it should be my decision as to whether I'd like to trash my TCP performance to benefit UDP or not - I paid for that link. Having a queueing mechanism that ensures that TCP does not get starved, but can use available bandwidth, would seem to address most needs, without an explicit reservation mechanism. If I asked for an N Mb/s video stream, I presumably know what I was doing and really wanted this. If I don't like the webbrowsing speed while watching the video, I'll turn it off. - multiple subscriber, but local bottlenecks, e.g., the access link owned by the business or university. Single-session TCP fairness makes very little sense since it simply encourages the use of multiple TCP sessions. Also, from a user experience perspective, why should instantaneous fairness be the right metric? I suspect that most people would consider long-term metrics as far more appropriate, e.g., their monthly bit budget. After all, this is what determines the overall expenditure of resources, at least for large multiplexing. For example, at Columbia, we switched from limiting the instantaneous bandwidth available to dorms to a monthly bit budget. Exceed it, and get put into the low-priority queue. This seems to work pretty well and avoids having to distinguish 'good' from 'bad' traffic. I suspect that a simple end system or access router policer that rate-limits non-responsive traffic will do ok for large user populations. Thus, no sending of UDP at 100 Mb/s to the Internet or I2, but few applications seem to need that. This again requires no resource reservation if the traffic engineering can be made to work. - bottlenecks elsewhere: there, session-level instantaneous fairness is probably the best we can do. However, US backbone providers claim very low average packet loss rates (below 1%), so it doesn't seem to be the network part throttling TCP at this point. If this is not true, we have a real problem that requires either an explicit business decision of the kind that Brian advocates or, conversely, penalty measures that discourage high-rate UDP flows. Rosen, Brian wrote: > Mark > > The reality of networks these days is that plain jane best effort > Internet doesn't make much money. Premium services do. So the > trend, which is clearly not universal, but is pretty obvious, > is that SPs are trying to bring new bandwidth users onto their > networks where the extra bandwidth is not just more bits, but > for which they can charge for service beyond best effort packet. > > Voice is one of those services, and video is one of those > services. You don't see a whole lot of investment these days > in plain Internet service, and you do in voice/video over IP > networks. So, while there are pure play best effort operators > out there, and they will be there, the money is in the premium > services. Even if an ISP does not directly provide premium > services, other SPs will, using the underlying packet carrier > as the pipe, and the USERS of the premium services will yell > loudly if their premium services are not delivering what they > pay for. If a customer of voice/video service gets told that > his pipe provider is intentionally degrading his service, what > do you think he will do with his pipe business? > > Everyone agrees, I think, the most desirable situation is > one in which we have a true converged network, not overlay > networks, not separate networks, for these new services. > I'm sure that there will be a lot of overlay networks around > for quite a while, because we don't have the mechanisms we are > discussing here - ways for classic best effort TCP to co-exist > well with real time media. Everyone wins if we figure out good > ways for this to happen. Everyone loses if any SP starts > intentionally degrading one kind of service to make another > kind of service work better. That's why I don't think it's > going to be common to stomp on media OR TCP. Rather, I think > everyone expects us to do our jobs well and make both kinds of > streams work well together. > > We aren't going to solve this problem with anything done on one side > folks; both sides are going to have to have new mechanisms. > > Brian > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 20:50:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20101 for ; Mon, 8 Dec 2003 20:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATX0s-0000no-VD for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 20:50:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB91oA2v003035 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 20:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATX0l-0000lI-3J; Mon, 08 Dec 2003 20:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATX0h-0000kY-ER for avt@optimus.ietf.org; Mon, 08 Dec 2003 20:49:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20064; Mon, 8 Dec 2003 20:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATX0e-0004lR-00; Mon, 08 Dec 2003 20:49:56 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ATX0e-0004lL-00; Mon, 08 Dec 2003 20:49:56 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB91ntsD083228; Mon, 8 Dec 2003 17:49:55 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312090149.hB91ntsD083228@coyote.icir.org> To: "Rosen, Brian" cc: "'mallman@icir.org'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? In-Reply-To: Message from "Rosen, Brian" of "Mon, 08 Dec 2003 13:47:37 EST." <313680C9A886D511A06000204840E1CF070B61A6@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 08 Dec 2003 17:49:55 -0800 From: Eddie Kohler Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian: > I am very willing to change the app to better work on the Internet, News to me. What kinds of changes are you willing to make? Henning: > - single subscriber bottlenecks, such as my DSL uplink; there, it should > be my decision as to whether I'd like to trash my TCP performance to > benefit UDP or not - I paid for that link. > - multiple subscriber, but local bottlenecks, e.g., the access link > owned by the business or university. > - bottlenecks elsewhere: there, session-level instantaneous fairness is > probably the best we can do. Of course a single flow might encounter multiple bottlenecks. In well-provisioned backbones there may or may not be loss, but a lot of the world doesn't work that way, and best-effort backbones probably won't grow monotonically less lossy over time. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 21:11:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20608 for ; Mon, 8 Dec 2003 21:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXLI-0001eK-E1 for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 21:11:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB92BGsT006291 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 21:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXL3-0001Xv-VY; Mon, 08 Dec 2003 21:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXKY-0001Wf-Do for avt@optimus.ietf.org; Mon, 08 Dec 2003 21:10:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20546; Mon, 8 Dec 2003 21:10:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATXKV-0004zW-00; Mon, 08 Dec 2003 21:10:27 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ATXKV-0004zT-00; Mon, 08 Dec 2003 21:10:27 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB92ARsD083394; Mon, 8 Dec 2003 18:10:27 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312090210.hB92ARsD083394@coyote.icir.org> To: dccp@ietf.org cc: avt@ietf.org Reply-To: dccp@ietf.org Date: Mon, 08 Dec 2003 18:10:27 -0800 From: Eddie Kohler Subject: [AVT] Faster Start after idle periods Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , [Replies to dccp@ietf.org only please.] Sally and I talked today about the slow-starting after an idle period. We have a potential solution that doesn't involve sending filler traffic to keep the pipe open. Say your app had a sending rate of K packets/RTT. Then you have an idle period, possibly up to several minutes; and you want to start sending again. (1) Start sending with a window of 8 packets/RTT (not 4). (2) Increase the window size by 4x after each lossless RTT (not 2x). This is twice as fast as slow start. But the multiplicative factor means that if slow start reached a rate in N RTTs, faster start would reach the same rate in sqrt(N) RTTs. A window of 128 packets/RTT is reached after 2 lossless RTTs (for a large RTT of 100ms and maximum-size packets, this is >14Mb/s after .2s). The theoretical justification for this is that the connection recently proved it could sustain rate K on this path. Caveats: (1) You must switch out of faster start (to slow start) once you reach the original rate K. (2) You must switch out of faster start (to AI) after any congestion event. (3) You can't use faster start if your last faster-start encountered congestion, and didn't achieve the original rate K. (Slow start instead.) (4) You probably can't use faster start if you didn't actually sustain rate K for long before. (5) Possibly others. It's not immediate-start. It doesn't change the slow start that the connection must go through initially. It does greatly improve the dynamics of DCCP connections that go idle (push-to-talk, interactive media), without requiring filler traffic. Details remain to be ironed out. Help or simulations welcome. Comments welcome too. Eddie _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 8 21:17:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20825 for ; Mon, 8 Dec 2003 21:17:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXQs-0001xd-Rd for avt-archive@odin.ietf.org; Mon, 08 Dec 2003 21:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB92H21M007501 for avt-archive@odin.ietf.org; Mon, 8 Dec 2003 21:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXQq-0001vP-Rc; Mon, 08 Dec 2003 21:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXQL-0001uw-Jk for avt@optimus.ietf.org; Mon, 08 Dec 2003 21:16:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20797; Mon, 8 Dec 2003 21:16:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATXQI-00053g-00; Mon, 08 Dec 2003 21:16:26 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ATXQI-00053d-00; Mon, 08 Dec 2003 21:16:26 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hB92GQsD083449; Mon, 8 Dec 2003 18:16:26 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200312090216.hB92GQsD083449@coyote.icir.org> To: dccp@ietf.org cc: avt@ietf.org In-Reply-To: Message from Eddie Kohler of "Mon, 08 Dec 2003 18:10:27 PST." <200312090210.hB92ARsD083394@coyote.icir.org> Date: Mon, 08 Dec 2003 18:16:26 -0800 From: Eddie Kohler Subject: [AVT] Re: [dccp] Faster Start after idle periods Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Caveats: > ... > (5) Possibly others. I forgot to mention: (4.5) You'll have to send "pings" -- one packet an RTT or so -- to verify that connectivity still exists. In many cases the acks you send for the other endpoint's data will suffice. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 00:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27625 for ; Tue, 9 Dec 2003 00:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATa5T-0007hY-C1 for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 00:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9576R1029583 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 00:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATa5N-0007fc-JR; Tue, 09 Dec 2003 00:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATa4R-0007ec-VP for avt@optimus.ietf.org; Tue, 09 Dec 2003 00:06:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27601; Tue, 9 Dec 2003 00:05:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATa4P-0000Oa-00; Tue, 09 Dec 2003 00:06:01 -0500 Received: from [61.11.88.62] (helo=gdaserver) by ietf-mx with smtp (Exim 4.12) id 1ATa4N-0000OQ-00; Tue, 09 Dec 2003 00:06:00 -0500 Received: from gdaserver ([127.0.0.1]) by gdaserver (JAMES SMTP Server 2.1.3) with SMTP ID 496; Tue, 9 Dec 2003 10:36:13 +0530 (IST) Message-ID: <001a01c3be13$a0d2a000$3400a8c0@mohan> From: "mohan" Cc: , References: <20031208145933.883F177A3CE@guns.icir.org> Date: Tue, 9 Dec 2003 10:46:40 +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 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [AVT] unsubscribe me Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Mark Allman" To: "Rosen, Brian" Cc: "'Eddie Kohler'" ; ; Sent: Monday, December 08, 2003 8:29 PM Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? > > (gluing together two things that I can't get to jive together in my > head) > > > A typical RTT on the internet these days is 50-100 ms. If you > > experience 30% loss in the first 3 RTTs of voice, you will clip the > > "hello" pretty badly. If it's 7-8 RTTs, you will definitely have a > > very poor experience. > > I do not understand where this 30% loss number comes from. If a host > experiences 30% loss the network is *quite* congested (recent > measurments I have done show that loss rate over 10% are very rare in > the Internet) or the connection is crossing a very ratty error-prone > link. I think the latter is unlikely in the general case. So, how > would this: > > > Yep; bang! 0 to 4Mbit in two packets. > > be useful? If you're already clipping "hello" then this is going to > provide a very lousy experience, right? > > Others have said it already, so I'll just briefly agree: In a > best-effort network I do not think any particular flow (TCP or DCCP or > UDP or SCTP or whatever) should be able to just start sending at a "high > rate" (where "high rate" is undefined, but 4Mbps is certainly high). I > think it would not be terribly difficult to show that such behavior > could easily cause problems (to competing TCP, to competing streaming > flows and to the flow that is doing this "instant on"). Slow start is > the current consensus for how to start from zero. Could there be other > schemes? Sure. Are those here and fully fleshed out such that we could > even consider them as potential solutions? Not right now. > > My hunch is that sending DCCP (/anything) through without slow start is > not going to work (i.e., I think consensus would be against that). So, > if your app can't deal with that then I think we might be stuck ... A > more general wondering of mine is how many streaming apps require this > "instant on" behavior (i.e., is your app an anomaly or is there a whole > class of apps that want instant-on over best-effort networks?)? > > Thanks! > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 03:46:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18222 for ; Tue, 9 Dec 2003 03:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdVT-00037t-8I for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 03:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB98kB45011964 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 03:46:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdVK-00034r-Ml; Tue, 09 Dec 2003 03:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTSV-0007IK-Gi for avt@optimus.ietf.org; Mon, 08 Dec 2003 17:02:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06413; Mon, 8 Dec 2003 17:02:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTST-00070V-00; Mon, 08 Dec 2003 17:02:25 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1ATTSS-0006z4-00; Mon, 08 Dec 2003 17:02:24 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 908DC77A69B; Mon, 8 Dec 2003 17:01:54 -0500 (EST) To: "Rosen, Brian" From: Mark Allman Reply-To: mallman@icir.org Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? In-Reply-To: <313680C9A886D511A06000204840E1CF070B61A6@whq-msgusr-02.pit.comms.marconi.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Wishlist Date: Mon, 08 Dec 2003 17:01:54 -0500 Message-Id: <20031208220154.908DC77A69B@guns.icir.org> Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian- > And, as I've pointed out, since these kinds of apps represent much > higher revenue per bit that the TCP-type apps, it's much more likely > that the network operators would deploy TCP stompers than media > stompers. YMMV. I saw your assertion in response to Sally a while back in this thread. But, I think we have a disconnect. I am generally thinking in terms of best-effort networks (as I think Sally was). Further, a network that has no priorities or traffic classes, but rather just tries its hardest to get all the data across. This is the kind of network where congestion control is important. And, this is the kind of network where I think you'll see "stompers" that attempt to surpress flows that are attempting to use a disproportionate amount of the bandwdith (whether that be streaming or mis-behaving TCP or ddos floods or whatever). Your claim above does not match my model of a best effort network. I.e., if people are willing to pay more for the traffic of some particular app and you provision appropriately then you no longer have just a dumb best-effort network. If you can engineer a network and provision appropriately then by all means use UDP and go from zero to 4Mbps instantly. However, I don't see that as supporting the assertion that DCCP can't be used for streaming across best-effort networks that are not engineered to give different levels of support to different classes of traffic. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 03:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18397 for ; Tue, 9 Dec 2003 03:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdZG-0003UK-9x for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 03:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB98o5rI013340 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 03:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdZC-0003RH-Nh; Tue, 09 Dec 2003 03:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdYQ-0003OJ-Bc for avt@optimus.ietf.org; Tue, 09 Dec 2003 03:49:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18349; Tue, 9 Dec 2003 03:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATdYN-0003wV-00; Tue, 09 Dec 2003 03:49:11 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ATdYM-0003wS-00; Tue, 09 Dec 2003 03:49:11 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB98nAI2021543; Tue, 9 Dec 2003 09:49:10 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW743NSS; Tue, 9 Dec 2003 09:49:10 +0100 Message-ID: <3FD58C85.6060808@ericsson.com> Date: Tue, 09 Dec 2003 09:49:09 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: avt@ietf.org, dccp@ietf.org Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? References: <313680C9A886D511A06000204840E1CF070B61A5@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B61A5@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Brian, Rosen, Brian wrote: > Magnus > > You saw the message from Henning on the effect of slow start on > conferencing applications didn't you? What makes you think > the video is any different? I wasn't thinking of conferencing. I was more thinking of single conversational cases. I agree that the leg from a new sender to the conference focus will be problematic, and every switch would need to do the slow start which would effect the media badly. The reason I think video is different from other media like audio is: at least in a conference application, the amount of bandwidth. You can get high quality voice using for example AMR-WB with a source bit rate of 23.35 kbit/s + IP/UDP/RTP overhead giving a total around 40 kbit/s. While 40 kbit/s video gives either a very small picture or very bad quality. To get a comparable quality in the video with a least a CIF size screen you must go much higher. > > In a conference application, streams come and go as different speakers > come and go. Even in a centrally mixed conference, which is not > as demanding as an end-system mixed conference, most participants > are not talking, and not sending video. When they start talking, > the start sending media, voice and video. To send media all the > time unnecessarily uses bandwidth; a lot of it. > I agree that sending all the time is stupid. > We don't do this now, we are end system mixed. > > Even your basic assumption that coarse video is acceptable for > a while is not true; it looks very poor. > Yes, my point was not that it would not look bad initially, my point is that is that it is possible to make the video codec go from a very bad initial quality up to as good as you have bandwidth. In an application that keeps on sending the bad quality is only in the initial start-up. > Actually, I'm not aware of any conferencing video systems that ramp > bandwidth. The reason is that the codecs are parameterized for a given > quality level/bandwidth, and you can't smoothly change the parameters - > you set them and restart the codec. I suspect that you could design > a codec to smoothly ramp, but that's not what we have available to us > now. What you do see sometimes is a codec which has a fixed bandwidth > but the algorithm itself sends coarse image more often than fine image, > and you see that effect on startup. That is very undesirable, but > it exists. > I am not surprised that there is no system that does this. As I said in my previous mail it is time for media application developers to leave their heaven of no congestion awareness and start developing things. Regarding the video codecs and their parameter sets. I know that if you need to switch parameter sets it can create problems in some codecs. However I know of least one codec, H.264, that is design and supports the use of multiple parameter sets. Also within a parameter sets the video has rather large differences in possible bit-rates. Even if no person has been using a video codec in the fashion of frequently turning on the bit-rate limit to the control, it is possible. Still the main point I would like to make is: For best effort services, we and the users will probably need to accept that quality can vary or be changed during a session, due to congestion. If one can't accept this, then one must start using resource reservation. Then media applications can encourage the network and congestion people to continue develop solutions that can get rid of slow start to be able to improve quality in the future. I also liked the proposal from Eddie about the speeded up slow start that will lower the media impact. Is someone keeping track of the different applications that will have problem and the different proposed solutions. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 04:35:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18221 for ; Tue, 9 Dec 2003 03:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdVT-00037u-99 for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 03:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB98kB2p011962 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 03:46:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdVL-000358-KD; Tue, 09 Dec 2003 03:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWUy-00087O-21 for avt@optimus.ietf.org; Mon, 08 Dec 2003 20:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18400; Mon, 8 Dec 2003 20:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWUv-000449-00; Mon, 08 Dec 2003 20:17:09 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ATWR5-0003wm-03; Mon, 08 Dec 2003 20:13:11 -0500 Received: from pine.neustar.com ([209.173.57.70]) by manatick with esmtp (Exim 4.24) id 1ATWCT-00025L-IH; Mon, 08 Dec 2003 19:58:05 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hB90vOb9030194; Tue, 9 Dec 2003 00:57:24 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 19:57:23 -0500 Message-ID: From: "Peterson, Jon" To: "'Rosen, Brian'" , "'mallman@icir.org'" Cc: "'Eddie Kohler'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Mon, 8 Dec 2003 19:57:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Brian, While some service providers may offer various QoS schemes in order to squeeze extra revenue out of every bit they push, surely for the foreseeable future there will continue to be providers who do not - who merely offer best-effort Internet as a commodity. By failing to standardize a responsible real-time protocol, we in fact encourage the sustained deployment of the sorts of overlay networks you describe below. While the IETF does not always see eye-to-eye with the marketplace, we do have a responsibility to offer the marketplace credible alternatives to replacing the Internet with a labyrinth of admissions control systems. While I understand that the '4Megs or bust' philosophy springs from the admirable goal of providing a consistent user experience, if I owned one of your videophones (you know, various annual gift-giving holidays are just around the corner...) I'd still like to be able to use it over my more modest home office connection. I'd like a device that isn't hardwired to just shut down if it can't offer me its ideal codec. Congestion control can offer feedback to the device to help it know the transport-layer rate that it can practically use, which could in turn influence codec selection, and so on. The more RSVP-like approach of reserving the optimal amount of bandwidth also has its place, and the IETF has long since acknowledged the right of both of these approaches to co-exist, if uneasily. The IETF does not hold a gun to any vendor's head, forcing them to do either or both. There are forms of real-time communications that today's best-effort Internet is unlikely to support in their full glory. But is this seriously an argument that there is no point in standardizing a congestion control scheme for unreliable datagrams for use over a best-effort network? That a protocol instantiating such would have no applicability to real-time communications? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, December 08, 2003 2:57 PM > To: 'mallman@icir.org' > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > Mark > > The reality of networks these days is that plain jane best effort > Internet doesn't make much money. Premium services do. So the > trend, which is clearly not universal, but is pretty obvious, > is that SPs are trying to bring new bandwidth users onto their > networks where the extra bandwidth is not just more bits, but > for which they can charge for service beyond best effort packet. > > Voice is one of those services, and video is one of those > services. You don't see a whole lot of investment these days > in plain Internet service, and you do in voice/video over IP > networks. So, while there are pure play best effort operators > out there, and they will be there, the money is in the premium > services. Even if an ISP does not directly provide premium > services, other SPs will, using the underlying packet carrier > as the pipe, and the USERS of the premium services will yell > loudly if their premium services are not delivering what they > pay for. If a customer of voice/video service gets told that > his pipe provider is intentionally degrading his service, what > do you think he will do with his pipe business? > > Everyone agrees, I think, the most desirable situation is > one in which we have a true converged network, not overlay > networks, not separate networks, for these new services. > I'm sure that there will be a lot of overlay networks around > for quite a while, because we don't have the mechanisms we are > discussing here - ways for classic best effort TCP to co-exist > well with real time media. Everyone wins if we figure out good > ways for this to happen. Everyone loses if any SP starts > intentionally degrading one kind of service to make another > kind of service work better. That's why I don't think it's > going to be common to stomp on media OR TCP. Rather, I think > everyone expects us to do our jobs well and make both kinds of > streams work well together. > > We aren't going to solve this problem with anything done on one side > folks; both sides are going to have to have new mechanisms. > > Brian > > > -----Original Message----- > > From: Mark Allman [mailto:mallman@icir.org] > > Sent: Monday, December 08, 2003 5:02 PM > > To: Rosen, Brian > > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet > real-time media > > dis tribution? > > > > > > > > Brian- > > > > > And, as I've pointed out, since these kinds of apps represent much > > > higher revenue per bit that the TCP-type apps, it's much > more likely > > > that the network operators would deploy TCP stompers than media > > > stompers. YMMV. > > > > I saw your assertion in response to Sally a while back in > this thread. > > > > But, I think we have a disconnect. I am generally thinking > > in terms of > > best-effort networks (as I think Sally was). Further, a > network that > > has no priorities or traffic classes, but rather just tries > > its hardest > > to get all the data across. This is the kind of network where > > congestion control is important. And, this is the kind of > > network where > > I think you'll see "stompers" that attempt to surpress > flows that are > > attempting to use a disproportionate amount of the > bandwdith (whether > > that be streaming or mis-behaving TCP or ddos floods or whatever). > > > > Your claim above does not match my model of a best effort network. > > I.e., if people are willing to pay more for the traffic of some > > particular app and you provision appropriately then you no > longer have > > just a dumb best-effort network. If you can engineer a network and > > provision appropriately then by all means use UDP and go > from zero to > > 4Mbps instantly. However, I don't see that as supporting the > > assertion > > that DCCP can't be used for streaming across best-effort > networks that > > are not engineered to give different levels of support to different > > classes of traffic. > > > > allman > > > > > > -- > > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 09:10:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26412 for ; Tue, 9 Dec 2003 09:10:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATiZ4-0006Hm-QK for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 09:10:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9EAE8F024113 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 09:10:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATiYu-0006Fl-1W; Tue, 09 Dec 2003 09:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATiY5-000678-No for avt@optimus.ietf.org; Tue, 09 Dec 2003 09:09:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26341; Tue, 9 Dec 2003 09:08:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATiY3-00002m-00; Tue, 09 Dec 2003 09:09:11 -0500 Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx with esmtp (Exim 4.12) id 1ATiY2-00002I-00; Tue, 09 Dec 2003 09:09:10 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB9E88XI015629; Tue, 9 Dec 2003 16:08:08 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB9E87gR015617; Tue, 9 Dec 2003 16:08:07 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Date: Tue, 9 Dec 2003 16:08:40 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5201700ECE@exrad2.ad.rad.co.il> Thread-Topic: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Thread-Index: AcO+MXS/0njGYrT8QwWfFvy+DVq5bwAKtalA From: "Yaakov Stein" To: "Magnus Westerlund" , "Rosen, Brian" Cc: , , "Eddie Kohler" Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable There is another application (other than video, that is) that is potentially high-bandwidth and has problems with slow-start. I am speaking of TDM pseudowires (as being standardized in the PWE3 WG). One can carry an E1 or T1 (or several of them) over the public Internet, although higher rate TDM services probably require dedicated networks. Not only is TDM an inherent constant rate service, it would be difficult to start it at anything other than its full rate, since the other side requires the full bandwidth for clock recovery, without which nothing works. (Although I could imagine a special mechanism that sends the full number of packets per second, but partially suppresses packet content for the first few seconds.) However, I am not sure whether TDM is an important case here as the setup or pull-down of a TDM service is not a frequent event. Y(J)S _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 09:16:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26553 for ; Tue, 9 Dec 2003 09:16:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATieh-0006il-C4 for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 09:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9EG2af025782 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 09:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATieg-0006hU-5K; Tue, 09 Dec 2003 09:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATidz-0006ge-2w for avt@optimus.ietf.org; Tue, 09 Dec 2003 09:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26519; Tue, 9 Dec 2003 09:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATidx-00008O-00; Tue, 09 Dec 2003 09:15:17 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ATidw-000085-00; Tue, 09 Dec 2003 09:15:17 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB9EEkwx013644; Tue, 9 Dec 2003 09:14:46 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 9 Dec 2003 09:14:41 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 09:14:40 -0500 Message-ID: From: "Phelan, Tom" To: "'Yaakov Stein'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Tue, 9 Dec 2003 09:14:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Yaakov, It seems to me that the TDM connection could deal with connection setup delays caused by a ramp-up period at the beginning of the connection. The connection would really begin once the sufficient rate was reached. Since after that the transmission would be at constant rate, there wouldn't be any more start up problems. Tom Phelan > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, December 09, 2003 9:09 AM > To: Magnus Westerlund; Rosen, Brian > Cc: avt@ietf.org; dccp@ietf.org; Eddie Kohler > Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > distribution? > > > > There is another application (other than video, that is) > that is potentially high-bandwidth and has problems with > slow-start. > > I am speaking of TDM pseudowires > (as being standardized in the PWE3 WG). > > One can carry an E1 or T1 (or several of them) > over the public Internet, although higher rate TDM services > probably require dedicated networks. > > Not only is TDM an inherent constant rate service, > it would be difficult to start it at anything other > than its full rate, since the other side requires the full > bandwidth for clock recovery, without which nothing works. > > (Although I could imagine a special mechanism that sends the full > number of packets per second, but partially suppresses packet content > for the first few seconds.) > > However, I am not sure whether TDM is an important case here > as the setup or pull-down of a TDM service is not a frequent event. > > Y(J)S > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 09:29:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26773 for ; Tue, 9 Dec 2003 09:29:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATirG-0007Ka-TK for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 09:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9ET2ce028163 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 09:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATirF-0007J5-Hf; Tue, 09 Dec 2003 09:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATiqF-0007Hz-9N for avt@optimus.ietf.org; Tue, 09 Dec 2003 09:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26751; Tue, 9 Dec 2003 09:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATiqB-0000GE-00; Tue, 09 Dec 2003 09:27:55 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATiqA-0000Fz-00; Tue, 09 Dec 2003 09:27:54 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01316; Tue, 9 Dec 2003 09:27:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21206; Tue, 9 Dec 2003 09:27:16 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 09:27:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61AF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" Cc: "'Eddie Kohler'" , "'mallman@icir.org'" , avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Tue, 9 Dec 2003 09:27:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Jon While I certainly think what I'm doing is something everyone would really, truly, want to have, I'm certainly aware that won't happen for some time. My app is simply a good example of what the long term future holds. The near term is more likely the simple voice conferencing application that Henning pointed out, and the channel surfing app for video (which is usually the better part of a megabit, or more). I think that the discussion of who carriers will penalize is not very fruitful, but I'll keep swinging on those pitches as long as people conjecture that SPs are motivated more by TCP fairness than premium traffic revenue. As I said, I really don't see any carrier penalizing TCP or UDP unless it gets excessive, in the manner Henning suggests. I have long advocated charging for what you deliver rather than prohibiting/firewalling/protecting-the-network. I don't foresee a labyrinth of admission control; I see some very simple mechanisms that will have pretty wide deployment. What we are missing for them is the feedback of loss. I certainly think that codec selection for current conditions is appropriate, downshifting (once) depending on conditions is appropriate, keep alives, or any new kinds of mechanisms that don't destroy the user experience are fine with me. I'm happy to work on, and help advocate, newer transports for media that are better at coexisting with TCP. However, I think I understand what is an acceptable user experience and what isn't; I've spent the better part of the last 4 years studying the effect of these kinds of decisions on user experience, some of which is directly applicable to less-than-4Mbit media streams. I claim that as long as UDP works, and DCCP doesn't, we aren't going to move apps to DCCP. Interactive media streams start and stop abruptly, and the codecs we have are close to constant rate. You know that. UDP can deliver that, the current proposals for DCCP can't. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Monday, December 08, 2003 7:57 PM > To: 'Rosen, Brian'; 'mallman@icir.org' > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media > dis tribution? > > > > Brian, > > While some service providers may offer various QoS schemes in order to > squeeze extra revenue out of every bit they push, surely for > the foreseeable > future there will continue to be providers who do not - who > merely offer > best-effort Internet as a commodity. By failing to > standardize a responsible > real-time protocol, we in fact encourage the sustained > deployment of the > sorts of overlay networks you describe below. While the IETF > does not always > see eye-to-eye with the marketplace, we do have a > responsibility to offer > the marketplace credible alternatives to replacing the Internet with a > labyrinth of admissions control systems. > > While I understand that the '4Megs or bust' philosophy > springs from the > admirable goal of providing a consistent user experience, if > I owned one of > your videophones (you know, various annual gift-giving > holidays are just > around the corner...) I'd still like to be able to use it over my more > modest home office connection. I'd like a device that isn't > hardwired to > just shut down if it can't offer me its ideal codec. > Congestion control can > offer feedback to the device to help it know the > transport-layer rate that > it can practically use, which could in turn influence codec > selection, and > so on. The more RSVP-like approach of reserving the optimal amount of > bandwidth also has its place, and the IETF has long since > acknowledged the > right of both of these approaches to co-exist, if uneasily. > The IETF does > not hold a gun to any vendor's head, forcing them to do > either or both. > > There are forms of real-time communications that today's best-effort > Internet is unlikely to support in their full glory. But is > this seriously > an argument that there is no point in standardizing a > congestion control > scheme for unreliable datagrams for use over a best-effort > network? That a > protocol instantiating such would have no applicability to real-time > communications? > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Monday, December 08, 2003 2:57 PM > > To: 'mallman@icir.org' > > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > > Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet > real-time media > > dis tribution? > > > > > > Mark > > > > The reality of networks these days is that plain jane best effort > > Internet doesn't make much money. Premium services do. So the > > trend, which is clearly not universal, but is pretty obvious, > > is that SPs are trying to bring new bandwidth users onto their > > networks where the extra bandwidth is not just more bits, but > > for which they can charge for service beyond best effort packet. > > > > Voice is one of those services, and video is one of those > > services. You don't see a whole lot of investment these days > > in plain Internet service, and you do in voice/video over IP > > networks. So, while there are pure play best effort operators > > out there, and they will be there, the money is in the premium > > services. Even if an ISP does not directly provide premium > > services, other SPs will, using the underlying packet carrier > > as the pipe, and the USERS of the premium services will yell > > loudly if their premium services are not delivering what they > > pay for. If a customer of voice/video service gets told that > > his pipe provider is intentionally degrading his service, what > > do you think he will do with his pipe business? > > > > Everyone agrees, I think, the most desirable situation is > > one in which we have a true converged network, not overlay > > networks, not separate networks, for these new services. > > I'm sure that there will be a lot of overlay networks around > > for quite a while, because we don't have the mechanisms we are > > discussing here - ways for classic best effort TCP to co-exist > > well with real time media. Everyone wins if we figure out good > > ways for this to happen. Everyone loses if any SP starts > > intentionally degrading one kind of service to make another > > kind of service work better. That's why I don't think it's > > going to be common to stomp on media OR TCP. Rather, I think > > everyone expects us to do our jobs well and make both kinds of > > streams work well together. > > > > We aren't going to solve this problem with anything done on one side > > folks; both sides are going to have to have new mechanisms. > > > > Brian > > > > > -----Original Message----- > > > From: Mark Allman [mailto:mallman@icir.org] > > > Sent: Monday, December 08, 2003 5:02 PM > > > To: Rosen, Brian > > > Cc: 'Eddie Kohler'; avt@ietf.org; dccp@ietf.org > > > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet > > real-time media > > > dis tribution? > > > > > > > > > > > > Brian- > > > > > > > And, as I've pointed out, since these kinds of apps > represent much > > > > higher revenue per bit that the TCP-type apps, it's much > > more likely > > > > that the network operators would deploy TCP stompers than media > > > > stompers. YMMV. > > > > > > I saw your assertion in response to Sally a while back in > > this thread. > > > > > > But, I think we have a disconnect. I am generally thinking > > > in terms of > > > best-effort networks (as I think Sally was). Further, a > > network that > > > has no priorities or traffic classes, but rather just tries > > > its hardest > > > to get all the data across. This is the kind of network where > > > congestion control is important. And, this is the kind of > > > network where > > > I think you'll see "stompers" that attempt to surpress > > flows that are > > > attempting to use a disproportionate amount of the > > bandwdith (whether > > > that be streaming or mis-behaving TCP or ddos floods or whatever). > > > > > > Your claim above does not match my model of a best effort network. > > > I.e., if people are willing to pay more for the traffic of some > > > particular app and you provision appropriately then you no > > longer have > > > just a dumb best-effort network. If you can engineer a > network and > > > provision appropriately then by all means use UDP and go > > from zero to > > > 4Mbps instantly. However, I don't see that as supporting the > > > assertion > > > that DCCP can't be used for streaming across best-effort > > networks that > > > are not engineered to give different levels of support to > different > > > classes of traffic. > > > > > > allman > > > > > > > > > -- > > > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > > > _______________________________________________ > > > dccp IETF mailing list: dccp@ietf.org > > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 09:51:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27314 for ; Tue, 9 Dec 2003 09:51:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjCa-0000Hc-Hi for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 09:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Ep4iU001063 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 09:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjCZ-0000Gd-0n; Tue, 09 Dec 2003 09:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjCP-0000G3-5g for avt@optimus.ietf.org; Tue, 09 Dec 2003 09:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27305 for ; Tue, 9 Dec 2003 09:50:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATjCN-0000vm-00 for avt@ietf.org; Tue, 09 Dec 2003 09:50:51 -0500 Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx with esmtp (Exim 4.12) id 1ATjCL-0000vd-00 for avt@ietf.org; Tue, 09 Dec 2003 09:50:49 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB9EnmXI020347 for ; Tue, 9 Dec 2003 16:49:48 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB9EnlgR020340 for ; Tue, 9 Dec 2003 16:49:47 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Would DCCP kill Internet real-time media distribution? Date: Tue, 9 Dec 2003 16:50:23 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5201700ED0@exrad2.ad.rad.co.il> Thread-Topic: [dccp] RE: [AVT] Would DCCP kill Internet real-time media distribution? Thread-Index: AcO+XtPMyMdNu7SER9ecQEh8RTYxMAAANBjQ From: "Yaakov Stein" To: "Phelan, Tom" Cc: Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Hi Yaakov, >=20 > It seems to me that the TDM connection could deal with=20 > connection setup delays caused by a ramp-up period at the beginning of = the=20 > connection. The connection would really begin once the sufficient = rate was=20 > reached. Since after that the transmission would be at constant rate, = there=20 > wouldn't be any more start up problems. >=20 > Tom Phelan There are several problem with that, as I said in my earlier email. First, what exactly does one send before the TDM is "up to full rate"? Arbitrarily chopped packets?=20 For the structure-aware case one could enable timeslots one at a time, but the PWE3 WG is mandating the structure-agnostic mode as the standards-track one, and here it is not clear how one could meaningfully = reduce the rate. Second, the far end uses the initial period of TDM to lock onto the TDM source clock's frequency and phase. This task has to be relatively fast, since before then the TDM output does not comply with the international standards for jitter and wander, and can cause problems in the far-end TDM = network. The only thing I can see that would work is to send dummy packets (marked as such) at a rate determined by the local TDM clock,=20 and increasing their size until full bandwidth is attained. Thereafter the dummy marking is removed and the true data sent. By using such a mechanism the TDM clock could be acquired without meaningful TDM data being lost or corrupting the far-end = network. Y(J)S _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 10:05:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28167 for ; Tue, 9 Dec 2003 10:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjQA-0000dM-83 for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 10:05:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9F56R0002407 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 10:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjQ7-0000bL-Nl; Tue, 09 Dec 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATjPm-0000aa-4Q for avt@optimus.ietf.org; Tue, 09 Dec 2003 10:04:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28054; Tue, 9 Dec 2003 10:04:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATjPj-0001D3-00; Tue, 09 Dec 2003 10:04:39 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATjPj-0001CZ-00; Tue, 09 Dec 2003 10:04:39 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03124; Tue, 9 Dec 2003 10:04:04 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28635; Tue, 9 Dec 2003 10:04:05 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 10:04:05 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B61B1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Magnus Westerlund'" Cc: avt@ietf.org, dccp@ietf.org Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution? Date: Tue, 9 Dec 2003 10:03:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Mangus > I wasn't thinking of conferencing. I was more thinking of single > conversational cases. I agree that the leg from a new sender to the > conference focus will be problematic, and every switch would > need to do > the slow start which would effect the media badly. I'm pretty sure that a point-to-point only solution is not a solution even if the incidence of point to point is 100 x more common. > > The reason I think video is different from other media like > audio is: at > least in a conference application, the amount of bandwidth. > You can get > high quality voice using for example AMR-WB with a source bit rate of > 23.35 kbit/s + IP/UDP/RTP overhead giving a total around 40 kbit/s. > While 40 kbit/s video gives either a very small picture or very bad > quality. To get a comparable quality in the video with a least a CIF > size screen you must go much higher. Why do you think that the bandwidth matters in this discussion? While bigger bandwidth causes congestion sooner, you can get congestion with a 40kbit stream on a 256K uplink pretty easily. The solution is not very bandwidth sensitive I think. Because of the effect of packetization periods on overall delay, we see that as codec bandwidth goes up, packet size goes up. My 4M streams are extreme, because you reach MTU before you get a big packetization period, but that is not true with slower video streams. > Yes, my point was not that it would not look bad initially, > my point is > that is that it is possible to make the video codec go from a > very bad > initial quality up to as good as you have bandwidth. In an > application > that keeps on sending the bad quality is only in the initial start-up. But that presents a poor user experience; an experience they do not get on existing transports. If you degrade the user experience when using a data network, you won't get many users. > > > Actually, I'm not aware of any conferencing video systems that ramp > > bandwidth. The reason is that the codecs are parameterized > for a given > > quality level/bandwidth, and you can't smoothly change the > parameters - > > you set them and restart the codec. I suspect that you could design > > a codec to smoothly ramp, but that's not what we have > available to us > > now. What you do see sometimes is a codec which has a > fixed bandwidth > > but the algorithm itself sends coarse image more often than > fine image, > > and you see that effect on startup. That is very undesirable, but > > it exists. > > > > I am not surprised that there is no system that does this. As > I said in > my previous mail it is time for media application developers to leave > their heaven of no congestion awareness and start developing things. You might want to go talk to the chip vendors, as we mostly see hardware encoders for video applications except for toys. It's a chip level problem, not software. > > Regarding the video codecs and their parameter sets. I know > that if you > need to switch parameter sets it can create problems in some codecs. > However I know of least one codec, H.264, that is design and supports > the use of multiple parameter sets. Also within a parameter sets the > video has rather large differences in possible bit-rates. Even if no > person has been using a video codec in the fashion of > frequently turning > on the bit-rate limit to the control, it is possible. I don't yet have enough experience with high quality H.264 to confirm or deny that this is possible. I haven't seen that, but implementations are still very new. > > Still the main point I would like to make is: For best effort > services, > we and the users will probably need to accept that quality > can vary or > be changed during a session, due to congestion. If one can't accept > this, then one must start using resource reservation. Actually, I don't agree. I think a combination of admission control and some new mechanisms on both TCP and UDP-or-replacement can achieve quite acceptable results without resource reservation mechanisms. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 11:18:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02093 for ; Tue, 9 Dec 2003 11:18:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkYu-0003o1-Dp for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 11:18:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GICFv014625 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 11:18:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkYk-0003n8-A6; Tue, 09 Dec 2003 11:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkYI-0003mE-Rp for avt@optimus.ietf.org; Tue, 09 Dec 2003 11:17:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02066; Tue, 9 Dec 2003 11:17:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkYH-0002OZ-00; Tue, 09 Dec 2003 11:17:33 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ATkYH-0002M6-00; Tue, 09 Dec 2003 11:17:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2003 08:19:00 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB9GH1BN007266; Tue, 9 Dec 2003 08:17:01 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AKO99509; Tue, 9 Dec 2003 08:17:00 -0800 (PST) Date: Tue, 09 Dec 2003 11:16:58 -0500 From: "David R. Oran" To: dccp@ietf.org cc: avt@ietf.org Subject: Re: [AVT] Faster Start after idle periods Message-ID: <2147483647.1070968618@[10.32.245.157]> In-Reply-To: <200312090210.hB92ARsD083394@coyote.icir.org> References: <200312090210.hB92ARsD083394@coyote.icir.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========6EA4B0827EC0109F5D50==========" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --==========6EA4B0827EC0109F5D50========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Define "idle period". If I'm on a conference call, announce the speaker, then listen for 2 hours=20 of rambling, and then speak up to ask "any questions"? is that restart=20 after idle? It seems to me there are some very tricky time constants here. how does this differ from HTTP tearing down a TCP connection to a web site=20 and then putting up another one to the same site on the next click and=20 claiming that it doesn't need to do slow start because the browser is "just = coming back from an idle period". If DCCP is allowed to keep congestion state across idle periods, then=20 shouldn't TCP too? We keep cycling around the core issue which is the claims by some in the=20 community that realtime interactive media does not work acceptably well if=20 it has to be congestion-responsive in its transmission rate, and the=20 contention by others that some clever adaptive rate control can work well=20 enough. I think we need existence proofs of a system that does rate-adapt=20 successfully before recommending the use of DCCP in preference to UDP. What would be even MORE helpful would be practical policing/dropping=20 algorithms on bottleneck links that dropped ALL packets of a subset of the=20 flows rather than RED or WRED across all the flows. That way a=20 measurement-based admission control scheme might have a chance of keeping a = subset of the realtime flows going with acceptable loss/delay during=20 congestion. Dave. --On Monday, December 8, 2003 6:10 PM -0800 Eddie Kohler =20 wrote: > [Replies to dccp@ietf.org only please.] > > Sally and I talked today about the slow-starting after an idle period. = We > have a potential solution that doesn't involve sending filler traffic to > keep the pipe open. > > Say your app had a sending rate of K packets/RTT. Then you have an idle > period, possibly up to several minutes; and you want to start sending > again. > (1) Start sending with a window of 8 packets/RTT (not 4). > (2) Increase the window size by 4x after each lossless RTT (not 2x). > > This is twice as fast as slow start. But the multiplicative factor means > that if slow start reached a rate in N RTTs, faster start would reach the > same rate in sqrt(N) RTTs. A window of 128 packets/RTT is reached after = 2 > lossless RTTs (for a large RTT of 100ms and maximum-size packets, this is >> 14Mb/s after .2s). > > The theoretical justification for this is that the connection recently > proved it could sustain rate K on this path. > > Caveats: > (1) You must switch out of faster start (to slow start) once you reach = the > original rate K. > (2) You must switch out of faster start (to AI) after any congestion > event. (3) You can't use faster start if your last faster-start > encountered congestion, and didn't achieve the original rate K. > (Slow start instead.) > (4) You probably can't use faster start if you didn't actually sustain > rate K for long before. > (5) Possibly others. > > It's not immediate-start. It doesn't change the slow start that the > connection must go through initially. It does greatly improve the > dynamics of DCCP connections that go idle (push-to-talk, interactive > media), without requiring filler traffic. > > Details remain to be ironed out. Help or simulations welcome. Comments > welcome too. > > Eddie > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt --==========6EA4B0827EC0109F5D50========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/1fV6jWaEtlTdKuYRAlimAJ9O+zoTJbldJM6txA3Dp7zSo0vVxgCdHJX4 djbRKAi2Uakp25SIkyX8WJ0= =ao1/ -----END PGP SIGNATURE----- --==========6EA4B0827EC0109F5D50==========-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 9 22:12:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29912 for ; Tue, 9 Dec 2003 22:12:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATull-0006WP-8N for avt-archive@odin.ietf.org; Tue, 09 Dec 2003 22:12:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA3C82T024949 for avt-archive@odin.ietf.org; Tue, 9 Dec 2003 22:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATule-0006Sf-7q; Tue, 09 Dec 2003 22:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATul1-0006Rm-Ok for avt@optimus.ietf.org; Tue, 09 Dec 2003 22:11:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29847; Tue, 9 Dec 2003 22:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATuky-0000Bl-00; Tue, 09 Dec 2003 22:11:20 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1ATukx-0000Bg-00; Tue, 09 Dec 2003 22:11:19 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hBA3ArGp000264; Tue, 9 Dec 2003 20:10:53 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hBA39hRh023449; Tue, 9 Dec 2003 21:09:43 -0600 Message-ID: <3FD68EFD.30B770E5@motorola.com> Date: Tue, 09 Dec 2003 21:11:57 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: dccp@ietf.org, avt@ietf.org Subject: Re: [AVT] Faster Start after idle periods References: <200312090210.hB92ARsD083394@coyote.icir.org> <2147483647.1070968618@[10.32.245.157]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ...... > I think we need existence proofs of a system that does rate-adapt > successfully before recommending the use of DCCP in preference to UDP. Not only that, we need to also show that RTP/DCCP can outperform RTP/UDP in whatever terms before the vendors and SPs can see any incentives to spend money for the switch. This is not going to be easy considering what's been happening for IPv6. There needs to be an IETF "official" list of incentives for adopting DCCP composed eventually. Just telling the vendors and SPs that UDP is unfriendly to TCP traffic won't cut it, IMO. AVT probably should wait to see such an "incentive list" composed before diving into migrating payload RFCs to DCCP. regards, -Qiaobing _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 10 03:54:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04695 for ; Wed, 10 Dec 2003 03:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU06o-0001VH-96 for avt-archive@odin.ietf.org; Wed, 10 Dec 2003 03:54:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA8sE89005731 for avt-archive@odin.ietf.org; Wed, 10 Dec 2003 03:54:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU06b-0001QR-Qu; Wed, 10 Dec 2003 03:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU06F-0001Pe-4y for avt@optimus.ietf.org; Wed, 10 Dec 2003 03:53:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04638; Wed, 10 Dec 2003 03:53:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU06C-0005tr-00; Wed, 10 Dec 2003 03:53:36 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AU06B-0005to-00; Wed, 10 Dec 2003 03:53:36 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBA8raSs005944; Wed, 10 Dec 2003 09:53:36 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW749J5Y; Wed, 10 Dec 2003 09:53:36 +0100 Message-ID: <3FD6DF10.5020103@ericsson.com> Date: Wed, 10 Dec 2003 09:53:36 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: dccp@ietf.org, avt@ietf.org Subject: Re: [dccp] Re: [AVT] Faster Start after idle periods References: <200312090210.hB92ARsD083394@coyote.icir.org> <2147483647.1070968618@[10.32.245.157]> <3FD68EFD.30B770E5@motorola.com> In-Reply-To: <3FD68EFD.30B770E5@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Qiaobing, I reacted to this: Qiaobing Xie wrote: > AVT probably should wait to see such an "incentive list" composed before diving > into migrating payload RFCs to DCCP. There should be no reason to do any changes to the RTP payload formats due to that one transport RTP over DCCP instead of UDP. So far the discussion has not shown any need to do any changes to RTP at all. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 10 04:21:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05117 for ; Wed, 10 Dec 2003 04:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0Wo-0002ZZ-DG for avt-archive@odin.ietf.org; Wed, 10 Dec 2003 04:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA9L6he009838 for avt-archive@odin.ietf.org; Wed, 10 Dec 2003 04:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0Wk-0002YN-1k; Wed, 10 Dec 2003 04:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU0Vy-0002XV-Iy for avt@optimus.ietf.org; Wed, 10 Dec 2003 04:20:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05112 for ; Wed, 10 Dec 2003 04:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU0Vv-00069D-00 for avt@ietf.org; Wed, 10 Dec 2003 04:20:11 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AU0Vv-00068n-00 for avt@ietf.org; Wed, 10 Dec 2003 04:20:11 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62125 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AU0VP-0002H1-00; Wed, 10 Dec 2003 09:19:39 +0000 Date: Wed, 10 Dec 2003 09:19:35 +0000 From: Colin Perkins To: Magnus Westerlund Cc: Qiaobing.Xie@motorola.com, avt@ietf.org Subject: Re: [dccp] Re: [AVT] Faster Start after idle periods Message-Id: <20031210091935.66149f04.csp@csperkins.org> In-Reply-To: <3FD6DF10.5020103@ericsson.com> References: <200312090210.hB92ARsD083394@coyote.icir.org> <2147483647.1070968618@[10.32.245.157]> <3FD68EFD.30B770E5@motorola.com> <3FD6DF10.5020103@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [since this is now about payload formats, I'll limit the cc to avt - please try to avoid cc'ing both lists] --> Magnus Westerlund writes: > Qiaobing Xie wrote: > > AVT probably should wait to see such an "incentive list" composed > > before diving into migrating payload RFCs to DCCP. > > There should be no reason to do any changes to the RTP payload formats > due to that one transport RTP over DCCP instead of UDP. So far the > discussion has not shown any need to do any changes to RTP at all. I can certainly imagine that some payload formats could use the improved loss feedback that DCCP provides. We yet haven't identified any need for changes to RTP payload formats, but I wouldn't necessarily rule them out. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 11 03:29:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22120 for ; Thu, 11 Dec 2003 03:29:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMBs-0000lz-Kp for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 03:28:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB8Su9a002923 for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 03:28:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUMAz-0000eK-PH; Thu, 11 Dec 2003 03:28:01 -0500 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU8cX-00054o-7p for avt@optimus.cnri.reston.va.us; Wed, 10 Dec 2003 12:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org.ietf.org) by ns.cnri.reston.va.us with smtp (Exim 4.20) id 1AU8cV-0004oL-OX for avt@optimus; Wed, 10 Dec 2003 12:59:31 -0500 Received: from ietf-mx by ietf.org.ietf.org (SMI-8.6/SMI-SVR4) id MAA24138; Wed, 10 Dec 2003 12:59:25 -0500 Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8cS-0004pS-00 for avt@ietf.org; Wed, 10 Dec 2003 12:59:28 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1AU8cR-0004oZ-00 for avt@ietf.org; Wed, 10 Dec 2003 12:59:27 -0500 Received: from [192.168.0.233] (c-67-164-72-164.client.comcast.net[67.164.72.164]) by comcast.net (rwcrmhc12) with SMTP id <200312101758570140087fbqe>; Wed, 10 Dec 2003 17:58:57 +0000 Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <126CEC13-2B3B-11D8-A508-0003938AC164@pioneer-pra.com> Content-Transfer-Encoding: 7bit Cc: John Gildred From: John Gildred Date: Wed, 10 Dec 2003 10:02:51 -0800 To: avt@ietf.org X-Mailer: Apple Mail (2.606) Subject: [AVT] HTTP Trickplay Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello AVT: Has anyone submitted an I-D in the past which defines a method of providing trickplay over HTTP (much like what RTSP can do)? For example, adding HTTP headers for playback position, speed, direction, etc. -John Gildred Vice President of Engineering Pioneer Research Center USA, Inc. A Division of Pioneer Electronics 101 Metro Drive, Suite 264 San Jose, California 95110 Office (408) 437-1800 Ext. 105 Mobile (510) 295-7770 john@pioneer-pra.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 11 12:43:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11669 for ; Thu, 11 Dec 2003 12:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUqG-00082K-Ja for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 12:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBHhChu030843 for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 12:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUq5-00080i-Bz; Thu, 11 Dec 2003 12:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUp7-0007zm-Gs for avt@optimus.ietf.org; Thu, 11 Dec 2003 12:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11646 for ; Thu, 11 Dec 2003 12:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUp5-000260-00 for avt@ietf.org; Thu, 11 Dec 2003 12:41:59 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AUUp5-00025r-00 for avt@ietf.org; Thu, 11 Dec 2003 12:41:59 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hBBHfwTA023451 for ; Thu, 11 Dec 2003 09:41:58 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hBBHfwVK023450 for avt@ietf.org; Thu, 11 Dec 2003 09:41:58 -0800 (PST) Date: Thu, 11 Dec 2003 09:41:58 -0800 (PST) From: John Lazzaro Message-Id: <200312111741.hBBHfwVK023450@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: HTTP trickplay Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > John Gildred writes: > > Has anyone submitted an I-D in the past which defines a method of > providing trickplay over HTTP (much like what RTSP can do)? From the MMUSIC minutes of IETF 51 (London): ======================================================================== 10. Tunneling RTSP/RTP/RTCP in HTTP (draft-gentric-avt-rtsp-http-00.txt) ======================================================================== RTSP describes a TCP-based streaming mode. This includes interleaved RTP/RTCP packets. The draft proposal is to extend this to HTTP-only firewalls. Source of proposal: Internet Streaming Media Alliance. The basic proposal is to use HTTP to create a channel in each direction. The authors are looking for more ideas and thoughts on how to proceed. Melinda Shore (mshore@cisco.com) expressed her disagreement with the proposal, because it raises serious security concerns. Its whole thrust is to violating site security policy. It would be more consistent with network policy to use Jonathan's SIP approach. If the draft is accepted, HTTP might become characterized as "Horrible Trashcan Transport Protocol". Jonathan Rosenberg noted that it is too late to salvage HTTP's reputation: RFC 3093 "IP Over HTTP" already describes how to do it. Mark Handley also expressed his concern with the security implications. Port 554 is allocated for RTSP; managers can open it if they want to. Apparently some firewall vendors already block strange uses of HTTP. Site administrators are aware of this sort of tunneling and are asking firewall vendors for controls. Joerg Ott ruled that the responses he had heard make it clear that the proposal is going nowhere in the MMUSIC WG. --- --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 11 14:39:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16692 for ; Thu, 11 Dec 2003 14:39:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWeX-00052D-Fa for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 14:39:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBJdDEs019304 for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 14:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWeL-00050D-9f; Thu, 11 Dec 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWdT-0004zH-HR for avt@optimus.ietf.org; Thu, 11 Dec 2003 14:38:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16670 for ; Thu, 11 Dec 2003 14:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWdQ-0005Z7-00 for avt@ietf.org; Thu, 11 Dec 2003 14:38:04 -0500 Received: from ribbit.cs.berkeley.edu ([128.32.112.203]) by ietf-mx with esmtp (Exim 4.12) id 1AUWdQ-0005Z4-00 for avt@ietf.org; Thu, 11 Dec 2003 14:38:04 -0500 Received: from ribbit.CS.Berkeley.EDU (localhost [127.0.0.1]) by ribbit.CS.Berkeley.EDU (3.14/2.71/) with ESMTP id hBBJc3TA023887 for ; Thu, 11 Dec 2003 11:38:03 -0800 (PST) Received: (from lazzaro@localhost) by ribbit.CS.Berkeley.EDU (3.14/3.14/Submit) id hBBJc3QX023886 for avt@ietf.org; Thu, 11 Dec 2003 11:38:03 -0800 (PST) Date: Thu, 11 Dec 2003 11:38:03 -0800 (PST) From: John Lazzaro Message-Id: <200312111938.hBBJc3QX023886@ribbit.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] RTP + Bluetooth in the news ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Several EE Times stories today covering the Bluetooth Americas conference, which talks about RTP over Bluetooth work underway: http://www.eetimes.com/sys/news/OEG20031211S0019 http://www.commsdesign.com/story/OEG20031210S0010 Given that wireless MIDI controllers are one of the target areas of use for RTP MIDI, I thought I should check on the list -- if the folks involved in the aforementioned work are listening in, is there any work in sight on the IETF side to support Bluetooth uses for RTP? Or, like RTP over 801.11, is the hope that the RTP <-> UDP <-> Bluetooth layering abstraction will "just work", isolating AVT from new Bluetooth-related work items? --------------------------------------------------- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 11 18:45:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03324 for ; Thu, 11 Dec 2003 18:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaUW-00089g-Be for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 18:45:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBNj81O031323 for avt-archive@odin.ietf.org; Thu, 11 Dec 2003 18:45:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaUP-00088S-C2; Thu, 11 Dec 2003 18:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaUB-00088D-0G for avt@optimus.ietf.org; Thu, 11 Dec 2003 18:44:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03314 for ; Thu, 11 Dec 2003 18:44:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaU7-0005hl-00 for avt@ietf.org; Thu, 11 Dec 2003 18:44:43 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AUaU7-0005hC-00 for avt@ietf.org; Thu, 11 Dec 2003 18:44:43 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:64069 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AUaTd-00013u-00; Thu, 11 Dec 2003 23:44:13 +0000 Date: Thu, 11 Dec 2003 23:44:16 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Subject: Re: [AVT] WG last call: iLBC payload format and codec Message-Id: <20031211234416.0cc6f371.csp@csperkins.org> In-Reply-To: <20031207141839.46a14542.csp@csperkins.org> References: <20031207141839.46a14542.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I draw the attention of the group to the revised IPR statement for this draft available at: http://www.ietf.org/ietf/IPR/global-ip-ipr-draft-ietf-avt-ilbc-codec.txt Colin --> Colin Perkins writes: > This is to announce a working group last call on the RTP Payload Format > and codec for iLBC speech: > > draft-ietf-avt-rtp-ilbc-04.txt > draft-ietf-avt-ilbc-codec-04.txt > > Please send any final comments on these drafts to the mailing list by > 19th December 2003. If no substantive comments are received by that > time, we will ask the IESG to publish the codec as an Experimental RFC > and the RTP payload format as a Proposed Standard RFC. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 12 13:32:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19343 for ; Fri, 12 Dec 2003 13:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs4x-0000Aw-1b for avt-archive@odin.ietf.org; Fri, 12 Dec 2003 13:31:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIVsgL000626 for avt-archive@odin.ietf.org; Fri, 12 Dec 2003 13:31:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs46-00008x-VU; Fri, 12 Dec 2003 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs3E-000081-UE for avt@optimus.ietf.org; Fri, 12 Dec 2003 13:30:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19246 for ; Fri, 12 Dec 2003 13:30:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUs3C-0003bw-00 for avt@ietf.org; Fri, 12 Dec 2003 13:30:06 -0500 Received: from law14-f10.law14.hotmail.com ([64.4.21.10] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AUs3C-0003bB-00 for avt@ietf.org; Fri, 12 Dec 2003 13:30:06 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 12 Dec 2003 10:29:34 -0800 Received: from 220.104.108.82 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 12 Dec 2003 18:29:34 GMT X-Originating-IP: [220.104.108.82] X-Originating-Email: [fedmain@hotmail.com] X-Sender: fedmain@hotmail.com From: "Mainka Fedrick" To: avt@ietf.org Date: Fri, 12 Dec 2003 18:29:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Dec 2003 18:29:34.0502 (UTC) FILETIME=[E42DD460:01C3C0DD] Subject: [AVT] Profile specification Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi all, In RFC3550 section 5.3.1, it is stated that "The format of these 16 bits is to be defined by the profile specification under which the implementations are operating." May I know what is the meaning of profile in this case? Is this "profile specification" the same profile under which the PT type can be defined (see section 5.1 under payload type)? Does a profile specify the format of the Marker Bit, the Payload Type and use of Header Extension? Best Regards, Fedrick _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 12 14:40:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21585 for ; Fri, 12 Dec 2003 14:40:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUt8R-00049J-Pf for avt-archive@odin.ietf.org; Fri, 12 Dec 2003 14:40:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCJdZ0D015900 for avt-archive@odin.ietf.org; Fri, 12 Dec 2003 14:39:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUt7t-00047l-Oe; Fri, 12 Dec 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUt6z-00045X-Gy for avt@optimus.ietf.org; Fri, 12 Dec 2003 14:38:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21549 for ; Fri, 12 Dec 2003 14:38:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUt6w-0005O2-00 for avt@ietf.org; Fri, 12 Dec 2003 14:38:02 -0500 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1AUt6w-0005LM-00 for avt@ietf.org; Fri, 12 Dec 2003 14:38:02 -0500 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id hBCJbQHW041843; Fri, 12 Dec 2003 11:37:26 -0800 (PST) (envelope-from casner@acm.org) Date: Fri, 12 Dec 2003 11:37:25 -0800 (PST) From: Stephen Casner To: Mainka Fedrick cc: avt@ietf.org Subject: Re: [AVT] Profile specification In-Reply-To: Message-ID: <20031212110854.Y45663@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Fri, 12 Dec 2003, Mainka Fedrick wrote: > In RFC3550 section 5.3.1, it is stated that "The format of these 16 bits is > to be defined by the profile specification under which the implementations > are operating." > > May I know what is the meaning of profile in this case? Is this "profile > specification" the same profile under which the PT type can be defined (see > section 5.1 under payload type)? The term "profile" is defined in Section 1, and I believe that term is used consistently throughout the document. That is, there should be no other meanings. Therefore, the short answer to your question is yes. > Does a profile specify the format of the Marker Bit, the Payload > Type and use of Header Extension? Yes. Section 13 lists aspects that may be defined in a profile. So far, all of the profiles that have been written simply follow the default format in the main RTP spec for the format of the Marker and PT byte, and none have defined Header Extensions. Only one profile has been published as an RFC (that's 3551 which updates 1890), but two more are about to be published. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 15 10:58:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14659 for ; Mon, 15 Dec 2003 10:58:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVv6s-0000tE-GL for avt-archive@odin.ietf.org; Mon, 15 Dec 2003 10:58:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFFwEIB003371 for avt-archive@odin.ietf.org; Mon, 15 Dec 2003 10:58:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVv6e-0000ri-IK; Mon, 15 Dec 2003 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVv6P-0000rO-7n for avt@optimus.ietf.org; Mon, 15 Dec 2003 10:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14641 for ; Mon, 15 Dec 2003 10:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVv6M-0007Ps-00 for avt@ietf.org; Mon, 15 Dec 2003 10:57:42 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1AVv6L-0007Pi-00 for avt@ietf.org; Mon, 15 Dec 2003 10:57:42 -0500 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBFFv4P18242 for ; Mon, 15 Dec 2003 10:57:04 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLYJKHZP; Mon, 15 Dec 2003 10:57:04 -0500 Received: from nortelnetworks.com (acart1g3.ca.nortel.com [47.129.129.178]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNB63; Mon, 15 Dec 2003 10:57:05 -0500 Message-ID: <3FDDD9CF.2080402@nortelnetworks.com> Date: Mon, 15 Dec 2003 10:57:03 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] 2833bis default event support Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Suppose a receiver indicates support for the telephone-events payload type but does not indicate which events it supports. Do we continue to require support for events 0 to 13 in all implementations? Tom Taylor _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 16 08:03:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13825 for ; Tue, 16 Dec 2003 08:03:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEr3-0000fV-7D for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 08:03:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGD3DT3002563 for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 08:03:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEqs-0000en-D6; Tue, 16 Dec 2003 08:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEqa-0000eY-A9 for avt@optimus.ietf.org; Tue, 16 Dec 2003 08:02:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13806 for ; Tue, 16 Dec 2003 08:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEqZ-0000eP-00 for avt@ietf.org; Tue, 16 Dec 2003 08:02:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEqX-0000eD-00 for avt@ietf.org; Tue, 16 Dec 2003 08:02:42 -0500 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 1AWEqX-0000e1-00 for avt@ietf.org; Tue, 16 Dec 2003 08:02:41 -0500 Received: from MCOMLAP3 ([10.10.150.80]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Dec 2003 14:02:16 +0100 From: "Rolf Hakenberg" To: "Colin Perkins" Cc: , , , , , Subject: RE: [AVT] Retransmission draft Date: Tue, 16 Dec 2003 14:02:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20031207191302.665669f8.csp@csperkins.org> X-OriginalArrivalTime: 16 Dec 2003 13:02:16.0062 (UTC) FILETIME=[D468B1E0:01C3C3D4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Colin and all, > > At the last 3GPP SA4 meeting there was a consensus on to make RTP > > Retransmission a working assumption in PSS Rel-6, subject to > the concerns > > on server complexity and delay being addressed at the next meeting. > > Do you expect addressing these concerns to require changes to the draft? No, I do not expect this to happen. The comments and concerns expressed at 3GPP have been quite specific to the 3GPP PSS (packet based streaming)environment and proposed use of RTP RTX in this requirement. One question for example was the correlation of RTP RTX with retransmission in the radio link control (RLC) layer considering the RLC discard timer and possible additional delay introduced by RTP RTX. Questions on complexity are very much implementation dependent and the draft already provides good general information about this issue in chapter 10. I do not see a need to elaborate any further on this issue in the draft. FYI: If 3GPP finds any information important for an implementor of RTP RTX in a 3GPP PSS environment, it has means to put this information as "informative parts" into the 3GPP specifiction. Best Regards, Rolf. > > > Important for our current discussion on potential IPRs and how to > > progress the draft is the fact that there was no condition on the IPR > > issues, but in fact conditions that the draft should move to RFC on > > standards track before the finalisation of 3GPP Rel-6. > > Moving to the standards track requires resolution of the IPR issue within > AVT, of course. > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 16 12:56:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25504 for ; Tue, 16 Dec 2003 12:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJQX-0005UJ-Ik for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 12:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGHu9SW021046 for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 12:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJQP-0005RS-Fp; Tue, 16 Dec 2003 12:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWJPx-0005Qx-89 for avt@optimus.ietf.org; Tue, 16 Dec 2003 12:55:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25447 for ; Tue, 16 Dec 2003 12:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWJPv-00049t-00 for avt@ietf.org; Tue, 16 Dec 2003 12:55:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWJPu-00049m-00 for avt@ietf.org; Tue, 16 Dec 2003 12:55:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AWJPu-00048h-00 for avt@ietf.org; Tue, 16 Dec 2003 12:55:30 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 16 Dec 2003 17:55:03 +0000 Received: from cisco.com (sjc-vpn4-75.cisco.com [10.21.80.75]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBGHsviN026538; Tue, 16 Dec 2003 09:54:58 -0800 (PST) Message-ID: <3FDF46F0.94F2C700@cisco.com> Date: Tue, 16 Dec 2003 12:54:56 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: avt@ietf.org Subject: Re: [AVT] 2833bis default event support References: <3FDDD9CF.2080402@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't see any reason to require (0-15 btw). Implementations can support whatever events they like and they MUST declare support for all the events they want to use (0-15 included). It may be worthwhile saying, that for 2833 backwards compatibility, if you receive an SDP with 2833 events and no fmtp parameter, that you assume events 0-15 are supported. -- Flemming Tom Taylor wrote: > Suppose a receiver indicates support for the telephone-events payload > type but does not indicate which events it supports. Do we continue to > require support for events 0 to 13 in all implementations? > > Tom Taylor > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 16 13:51:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27525 for ; Tue, 16 Dec 2003 13:51:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKHl-00087l-KV for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 13:51:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGIp9OX031203 for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 13:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKHf-00086b-D6; Tue, 16 Dec 2003 13:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKH1-00085r-Bv for avt@optimus.ietf.org; Tue, 16 Dec 2003 13:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27508 for ; Tue, 16 Dec 2003 13:50:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWKGy-000603-00 for avt@ietf.org; Tue, 16 Dec 2003 13:50:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWKGx-0005zn-00 for avt@ietf.org; Tue, 16 Dec 2003 13:50:20 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWKGx-0005yV-00 for avt@ietf.org; Tue, 16 Dec 2003 13:50:19 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGIn6t04999; Tue, 16 Dec 2003 13:49:06 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLSTLS7T; Tue, 16 Dec 2003 13:49:07 -0500 Received: from nortelnetworks.com (acart1b9.ca.nortel.com [47.129.129.19]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWNCMY; Tue, 16 Dec 2003 13:49:06 -0500 Message-ID: <3FDF53A1.6000600@nortelnetworks.com> Date: Tue, 16 Dec 2003 13:49:05 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: avt@ietf.org Subject: Re: [AVT] 2833bis default event support References: <3FDDD9CF.2080402@nortelnetworks.com> <3FDF46F0.94F2C700@cisco.com> In-Reply-To: <3FDF46F0.94F2C700@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sounds good to me. Flemming Andreasen wrote: > I don't see any reason to require (0-15 btw). Implementations can support > whatever events they like and they MUST declare support for all the events > they want to use (0-15 included). It may be worthwhile saying, that for > 2833 backwards compatibility, if you receive an SDP with 2833 events and no > fmtp parameter, that you assume events 0-15 are supported. > > -- Flemming > > Tom Taylor wrote: > > >>Suppose a receiver indicates support for the telephone-events payload >>type but does not indicate which events it supports. Do we continue to >>require support for events 0 to 13 in all implementations? >> >>Tom Taylor >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Dec 16 18:22:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13990 for ; Tue, 16 Dec 2003 18:22:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOW6-0003S9-Al for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 18:22:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNMEMM013272 for avt-archive@odin.ietf.org; Tue, 16 Dec 2003 18:22:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOVs-0003R1-2I; Tue, 16 Dec 2003 18:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHdE-0008EJ-58 for avt@optimus.ietf.org; Tue, 16 Dec 2003 11:01:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21272 for ; Tue, 16 Dec 2003 11:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHdB-00005z-00 for avt@ietf.org; Tue, 16 Dec 2003 11:01:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHd8-00005e-00 for avt@ietf.org; Tue, 16 Dec 2003 11:01:04 -0500 Received: from drum.kom.e-technik.tu-darmstadt.de ([130.83.139.190] helo=mailserver.KOM.e-technik.tu-darmstadt.de) by ietf-mx with esmtp (Exim 4.12) id 1AWHd7-00003a-00 for avt@ietf.org; Tue, 16 Dec 2003 11:01:02 -0500 Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id RAA06598 for ; Tue, 16 Dec 2003 17:00:30 +0100 (MET) Message-ID: <3FDF2C1D.7070705@kom.tu-darmstadt.de> Date: Tue, 16 Dec 2003 17:00:29 +0100 From: Ivica Rimac User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Subject: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, we are also thinking of an application combining live streaming of continuous media with time-lined static media objects. The idea is to transfer slides of a lecture (binary static object) synchronized with the spoken explaination (audio). Looking into the FLUTE draft, it seems to already provide the necessary means for reliable transfer of time-lined static media: providing additional timing attributes to the FDT. With the latter and the RTP timing information, the application can synchronize both media objects. Now since Magnus does not think there is a straightforward solution, I am wondering where I might be wrong? Has there been any follow-up discussion? > Hi Magnus, >  > It was good to learn of your views on Flute! We have been thinking on similar lines about the possible use SMIL for synchronizing Flute transfers with media streams. The use of SDP for describing the sessions of the FLUTE protocol has been in the plans. We have also been preliminarily considering the use of both SMIL and SDP for our work on Internet Media Guides in MMUSIC. >  > Looking forward to seeing you in Minneapolis! >  > -Pekka >  > ------------------- > Juha-Pekka Luoma > Nokia Research Center > Tampere, Finland > ------------------- >  > > -----Original Message----- > > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, October 30, 2003 11:42 AM > > To: Takeshi Yoshimura > > Cc: Walsh Rod (NRC/Tampere); finlayson@live.com; avt@ietf.org > > Subject: Re: [MMUSIC] time-lined static media with FLUTE & IMG > > > > > > Hi, > > > > The static media draft is dead. I have no plans of updating it as I > > currently don't think it is the right approach to the > > problem. The usage > > of RTP actually seems rather unnecessary. Most of the functionality in > > RTP is not at all needed and other things where missing. Here > > I find the > > FLUTE solution more addressing the problems around binary object > > transport for multicast. However I don't know its performance for > > unicast, however for any unicast session HTTP is probably > > usable if one > > can schedule the GET command appropriately and to know when to stop > > requesting because it is to late. > > > > The FLUTE solution are still missing many vital parts to my > > understanding. The first is how to achieve the synchronization. One > > could for example use SMIL however this requires one to have resolved > > how one performs the referencing to downloaded binary objects. To my > > understanding a defined cache utilizing FLUTEs source URI declaration > > could be a possibility. There also seem to be shortcoming that no real > > effort has been made into defining how the session > > declaration should be > > made. > > > > The usage of RFC 2733 or ULP does not seem to provide the > > necessary FEC > > performance to be used in multicast delivery, at least not for objects > > larger than a few packets. However this is not my expertise > > area, but I > > assume there are good reasons why more advanced algorithms like > > reed-solomon or tornado codes seem to be used in the area. > > > > I don't think this problem space has any straightforward solutions. It > > is hard problems, requiring well thought through solutions. There is > > definitely need to do more work in the area. > > > > My personal feeling in regards to MBMS is that the work is to > > hurried to > > be able to produce a good solution. > > > > As a conclusion to the original question, I would say that the > > application of FLUTE for time-lined static media delivery as > > combination > > to multicasted continuos media like audio and video requires further > > investigation. > > > > Cheers > > > > Magnus > > > > Takeshi Yoshimura wrote: > > > > > Hi Rod and Magnus, > > > > > > I'm also considering a reliable and time-lined static media > > delivery, > > > because it is discussed in 3GPP as one of the services over 3G MBMS > > > (Multimedia Broadcast/Multicast Service). > > > > > > You seem to extend FLUTE for this purpose, but I think > > combining generic > > > RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733, > > > draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way. > > > What do you think of this approach? > > > > > > Regarding this issue, what's the current status of > > > draft-westerlund-avt-rtp-static-media-01? Is there any technical > > > problem with this? > > > > > > Best regards, > > > Takeshi > > > > > > > > >>Hi Magnus, Ross (and everyone) > > >> > > >>1$B%9(J-2 years back there was a draft on time-lined static > > media (draft-westerlund-avt-rtp-static-media-01) - basically > > to send files, text (etc) with timed presentation along with > > AV media streams. Since the basic requirements haven't gone > > away, but RMT has made progress on usable protocols, what do > > you think about using FLUTE (draft-ietf-rmt-flute-02) for the > > same job? With a quick comparison I think it should be pretty > > straight forward, although you may have some preferences (or > > extensions to the FLUTE-FDT) if you already have a working > > RTP-payload'ed implementation. > > >> > > >>Ross mentioned sending ID-3 tags in-band with audio > > streams. Any ideas you have on doing this with FLUTE (ID3) > > and RTP (music) could be pretty useful for the Internet Media > > Guide (IMG) work in MMUSIC - how to move around (and > > announce) metadata for 'foo' multicast and unicast sessions. > > >> > > >>Cheers, Rod. > > > > -- > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > >  > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- Best regards, +--- Ivica Rimac -----------------------------------------------+ | KOM - Multimedia Communications | | Department of Electrical Engineering & Information Technology | | Darmstadt University of Technology | | email: Ivica.Rimac@kom.tu-darmstadt.de | | Merckstr. 25 tel.: +49-6151-16-6112 (Fax -6152) | | 64283 Darmstadt http://www.kom.e-technik.tu-darmstadt.de | +---------------------------------------------------------------+ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Dec 17 05:00:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01452 for ; Wed, 17 Dec 2003 05:00:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYTe-0003kK-6d for avt-archive@odin.ietf.org; Wed, 17 Dec 2003 05:00:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHA0LSE014391 for avt-archive@odin.ietf.org; Wed, 17 Dec 2003 05:00:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYTN-0003jH-Gy; Wed, 17 Dec 2003 05:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYSz-0003iT-TW for avt@optimus.ietf.org; Wed, 17 Dec 2003 04:59:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01406 for ; Wed, 17 Dec 2003 04:59:38 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWYSw-00059M-00 for avt@ietf.org; Wed, 17 Dec 2003 04:59:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWYSu-00059F-00 for avt@ietf.org; Wed, 17 Dec 2003 04:59:37 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWYSu-00059C-00 for avt@ietf.org; Wed, 17 Dec 2003 04:59:36 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBH9xa621665 for ; Wed, 17 Dec 2003 11:59:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 11:59:35 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 11:59:36 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 11:59:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG Date: Wed, 17 Dec 2003 11:59:34 +0200 Message-ID: Thread-Topic: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG Thread-Index: AcPEK67MKg704CqAS+SyXZPuKVEh5QAU7Nbg To: , X-OriginalArrivalTime: 17 Dec 2003 09:59:35.0751 (UTC) FILETIME=[79F7B570:01C3C484] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ivica Great to hear you're interested in this field. > Has there been any follow-up discussion? Not much so far. I think the related people are hammering away at other = problems at the moment, so this one is queued (at least for me). > Now since Magnus does not think there is a straightforward=20 > solution, I=20 > am wondering where I might be wrong? I think Magnus was refering to FEC (for RTP). The references where not = ALC FEC references. I (also) am not a FEC expert, but if you have an = idea of what your application reliability and network loss = characteristics might be, it should be easier to assess what kind of FEC = scheme would suit. Fortunately ALC's designed to allow new and old = schemes to 'plug-in' staightforwardly. You just need the FEC spec that = meets your needs. As I interpretted it, Magnus highlighted 3 issues needing solution: 1. How to achieve synchronisation 2. How to reference downloaded binary objects 3. Session description (declaration) of FLUTE sessions (e.g. SDP = extension) You have addressed (1) with "providing additional timing attributes to = the FDT"... > Looking into the FLUTE draft, it seems to already provide the=20 > necessary=20 > means for reliable transfer of time-lined static media: providing=20 > additional timing attributes to the FDT. With the latter and the RTP=20 > timing information, the application can synchronize both=20 > media objects. Which makes sense. Essentially I can see three simple solutions for (1): 1. describe the timing information in the FDT as an extension (your = suggestion) 2. describe the timing information in the FDT in a seperate object (e.g. = in a SMIL file - Magnus's suggestion) 3. use the expires field already in the FDT as the implicit timing field = (I not convinced whether this is a good idea) If you've got a spec of any of these I'd be happy to distrubte and = review it. Irrespecive of how you solve (1), you need to solve (2) - how to = reference "downloaded binary objects" (aka "files"). FLUTE already gives = you URIs to identify files so the simple way is to use these. If you = want to be globaly unique, I guess you'll choose URLs (rather than URNs) = although there's the consideration of whether HTTP://... is going to be = resolved to an HTTP GET by your application if it's not savvy with = what's being multicast. Could just use relative URLs, or even define a = new FLUTE URL. For me everything is fine as is (it's easy to reference a = URI and take care that you understand it's uniqueness in whatever = domain). If anyone sees some significant problems with this, please = highlight them - especially whether we need a FLUTE URL (since that = needs an Internet-draft). Finally, to solve (3) you need to define a FLUTE Session Description = Syntax/extension. It's a fair bet that SDP will be with us for some time = ahead so an SDP extension seems to be the minimal Internet-draft for = general Interent usage. This is on my todo list, unless someone else = does it first. BTW, one of the open source FLUTE implementations is available here: http://atm.tut.fi/mad/ Cheers, Rod _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 18 13:07:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06287 for ; Thu, 18 Dec 2003 13:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2YQ-0007nw-2T for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 13:07:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBII7HYY029943 for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 13:07:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2YA-0007hD-U8; Thu, 18 Dec 2003 13:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2Q3-0007PR-7A for avt@optimus.ietf.org; Thu, 18 Dec 2003 12:58:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05958 for ; Thu, 18 Dec 2003 12:58:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX2Q1-0007Q0-00 for avt@ietf.org; Thu, 18 Dec 2003 12:58:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX2Pt-0007PJ-00 for avt@ietf.org; Thu, 18 Dec 2003 12:58:36 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AX2Pr-0007ON-00 for avt@ietf.org; Thu, 18 Dec 2003 12:58:28 -0500 Received: from mangole ([130.209.247.112]:1678 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AX2PJ-0003eE-00; Thu, 18 Dec 2003 17:57:53 +0000 Date: Thu, 18 Dec 2003 17:57:59 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com, Eddie Kohler Message-Id: <20031218175759.7198af46.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__18_Dec_2003_17_57_59_+0000_yT05VQVFJoR/qsPT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] Draft AVT minutes from IETF 58 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart=_Thu__18_Dec_2003_17_57_59_+0000_yT05VQVFJoR/qsPT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Folks, Attached are draft minutes for the AVT sessions at the 58th IETF in Minneapolis. We're running late with these, so please send any comments immediately, so we can meet the submission deadline. Thanks, Colin --Multipart=_Thu__18_Dec_2003_17_57_59_+0000_yT05VQVFJoR/qsPT Content-Type: text/plain; name="minutes.txt" Content-Disposition: attachment; filename="minutes.txt" Content-Transfer-Encoding: base64 CkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBXb3JraW5nIEdyb3VwIE1pbnV0ZXMKClJlcG9ydGVkIGJ5 IE1hZ251cyBXZXN0ZXJsdW5kIGFuZCBDb2xpbiBQZXJraW5zCgogICBUaGUgQVZUIHdvcmtpbmcg Z3JvdXAgbWV0IGZvciB0d28gc2Vzc2lvbnMgZHVyaW5nIHRoZSA1OHRoIElFVEYuIER1cmluZwog ICB0aGVzZSBzZXNzaW9ucyB0aGUgZ3JvdXAgZGlzY3Vzc2VkIFJUUCBjb25zaWRlcmF0aW9ucyBm b3IgRENDUCwgdGhlIFNTTQogICBSVENQIEV4dGVuc2lvbiwgVm9JUCBoZWFkZXIgY29tcHJlc3Np b24gb3ZlciBtdWx0aXBsZSBob3BzIGFuZCBNUExTLCBvbmUKICAgbmV3IFJUUCBwcm9maWxlLCB2 aWRlbyBwYXJhbWV0ZXIgYW5kIGNvbW1hbmQgc2lnbmFsbGluZywgYW5kIG51bWVyb3VzCiAgIFJU UCBwYXlsb2FkIGZvcm1hdHMuIAoKSW50cm9kdWN0aW9uIGFuZCBkb2N1bWVudCBzdGF0dXMKCiAg IFRoZSB3b3JraW5nIGdyb3VwIGhhcyBwdWJsaXNoZWQgOCBSRkNzIHNpbmNlIHRoZSBwcmV2aW91 cyBJRVRGIG1lZXRpbmc6CiAgIFJGQyAzNTQ1LCAzNTUwLCAzNTUxLCAzNTU1LCAzNTU2LCAzNTU3 LCAzNTU4LCBhbmQgMzYxMS4gVGhlcmUgaXMgYWxzbyBhCiAgIGRvY3VtZW50IChkcmFmdC1pZXRm LWF2dC1tcGVnNC1zaW1wbGUtMDgudHh0KSBpbiB0aGUgUkZDIGVkaXRvcnMgcXVldWUsCiAgIGFu ZCB0aGUgUlRQIHByb2ZpbGUgZm9yIHNlY3VyaXR5IChkcmFmdC1pZXRmLXNydHAtMDkudHh0KSB3 YXMgYXBwcm92ZWQKICAganVzdCBwcmlvciB0byB0aGUgbWVldGluZyBhbmQgd2lsbCBnbyBvbiB0 byB0aGUgUkZDIGVkaXRvci4gIFRoZXJlIGFyZQogICBmb3VyIHdvcmtpbmcgZ3JvdXAgZHJhZnRz IHdhaXRpbmcgZm9yIEFyZWEgRGlyZWN0b3IgcmV2aWV3LCBuYW1lbHk6CiAgIGRyYWZ0LWlldGYt YXZ0LXJ0cC1yZXRyYW5zbWlzc2lvbi0wOS50eHQsIGRyYWZ0LWlldGYtYXZ0LXRjcnRwLTA3LnR4 dCwgCiAgIGRyYWZ0LWlldGYtYXZ0LXJ0Y3AtZmVlZGJhY2stMDcudHh0IGFuZCAKICAgZHJhZnQt YnVybWVpc3Rlci1hdnQtcnRjcC1mZWVkYmFjay1zaW0tMDIudHh0LgoKICAgVGhlIHdvcmtpbmcg Z3JvdXAgaGFzIGEgbnVtYmVyIG9mIGRvY3VtZW50cywgYm90aCB3b3JraW5nIGdyb3VwIGFuZAog ICBpbmRpdmlkdWFsIHN1Ym1pc3Npb25zIHRoYXQgYXJlIG5vdCBvdGhlcndpc2UgdG8gYmUgZGlz Y3Vzc2VkIGluIHRoZSAKICAgbWVldGluZywgYW5kIHdlcmUgaW5zdGVhZCByZXBvcnRlZCBvbiBi eSB0aGUgY2hhaXJzOiAKCiAgIC0gRHJhZnQtaWV0Zi1hdnQtcnRwLWNsZWFybW9kZS0wMy50eHQg YW5kIGRyYWZ0LWpvbmVzLWF2dC1hdWRpby10MzgtMDEudHh0CiAgICAgYXJlIGJhc2ljYWxseSBy ZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwuIFRoZXkgaGF2ZSBib3RoIHJlY2VpdmVk CiAgICAgZWRpdG9yaWFsIGNvbW1lbnRzLCBzbyBhZnRlciBhbiB1cGRhdGUgdGhleSB3aWxsIGdv IHRvIFdHIGxhc3QgY2FsbC4gQW55IAogICAgIGNvbW1lbnRzIHdhcyBlbmNvdXJhZ2VkIHRvIGJl IHNlbnQgaW4gYmVmb3JlIHRoZSBlbmQgb2YgdGhlIG1lZXRpbmcgd2Vlay4gCgogICAtIFRvbSBU YXlsb3IgaXMgd29ya2luZyBvbiB1cGRhdGluZyBkcmFmdC1pZXRmLWF2dC1SRkMyODMzYmlzLTAz LnR4dAogICAgIHVuZGVyIEhlbm5pbmcgU2NodWx6cmlubmUncyBzdXBlcnZpc2lvbi4gVGhlIGRv Y3VtZW50IHdpbGwgcmVjZWl2ZSBhbgogICAgIGVkaXRvcmlhbCByZW9yZ2FuaXNhdGlvbiBkdWUg dG8gaXRzIGdyb3d0aCBmcm9tIERUTUYgdG9uZSBkcmFmdCB0byBhCiAgICAgZ2VuZXJhbCB0b25l IHNpZ25hbGxpbmcgZHJhZnQuIFRoZXJlIHdlcmUgYWxzbyBzdWJzdGFudGlhbCBjb21tZW50cwog ICAgIHJhaXNlZCBieSBUb20gVGF5bG9yIGFuZCBBbmRyZWFzZW4gRmxlbW1pbmcgdGhhdCBuZWVk IHRvIGJlIGFkZHJlc3NlZAogICAgIGluIHRoZSBuZXh0IHZlcnNpb24uIEFuIHVwZGF0ZSBpcyBl eHBlY3RlZCB3aXRoaW4gYSBmZXcgbW9udGhzLiAKCiAgIC0gZHJhZnQtaWV0Zi1hdnQtdXhwLTA2 LnR4dCBoYXMgYmVlbiBzdGFsbGVkIGZvciBxdWl0ZSBhIHdoaWxlIGR1ZSB0byAKICAgICBpdHMg Y29ubmVjdGlvbiB3aXRoIHRoZSBVTFAgZHJhZnQuIEl0IGhhcyBiZWVuIGVzdGFibGlzaGVkIHRo YXQgdGhleQogICAgIGFyZSBkaWZmZXJlbnQgZW5vdWdoIHRvIGJlIGFibGUgdG8gcHJvZ3Jlc3Mg b24gdGhlaXIgb3duLiBUaGUgVVhQCiAgICAgZHJhZnQgc2VlbXMgdG8gYmUgZnVuZGFtZW50YWxs eSBzb3VuZCwgaG93ZXZlciBpdCByZXF1aXJlcyBzaWduaWZpY2FudAogICAgIGVkaXRvcmlhbCB3 b3JrIGJlZm9yZSBpdCBjYW4gYWR2YW5jZS4gCgogICAtIGRyYWZ0LWtlcnItYXZ0LXZvcmJpcy1y dHAtMDMudHh0IGhhcyByZWNlaXZlZCBtaW5vciB1cGRhdGVzIHNpbmNlIGxhc3QKICAgICBtZWV0 aW5nLCBhbmQgYSBtb3JlIG1ham9yIHVwZGF0ZSBhcmUgZXhwZWN0ZWQuCgogICAtIGRyYWZ0LWhl cmxlaW4tc3BlZXgtcnRwLXByb2ZpbGUtMDEudHh0LCBhbmQgCiAgICAgZHJhZnQtcmFtYWxoby1y Z2wtcnRwZm9ybWF0LTAyLnR4dCBhcmUgYm90aCBhd2FpdGluZyB1cGRhdGVzLiAKCiAgIC0gZHJh ZnQtaWV0Zi1hdnQtbXBlZzFhbmQyLW1vZC0wMC50eHQgaXMgYW4gdXBkYXRlIHRvIHRoZSBSVFAg cGF5bG9hZCAKICAgICBmb3JtYXQgZm9yIE1QRUcxIGFuZCAyIHZpZGVvIChSRkMgMjI1MCkgaW50 ZW5kZWQgdG8gYmUgcHVibGlzaGVkIGFzCiAgICAgYSBkcmFmdCBzdGFuZGFyZCBSRkMuIFJldmll dyBpcyBzb2xpY2l0ZWQuIAoKICAgLSBkcmFmdC1jaGVuLXJ0cC1idi0wMC50eHQ6IHRoZXJlIHdh cyBhIG1peC11cCB3aXRoIHRoZSBkZWFkbGluZXMgYW5kIAogICAgIHN1Ym1pc3Npb24sIGFuZCB0 d28gbmV3IHZlcnNpb25zIGNhbiBiZSBleHBlY3RlZCBkaXJlY3RseSBhZnRlciB0aGUKICAgICBt ZWV0aW5nLiBSZXZpZXcgaXMgc29saWNpdGVkLgoKICAgLSBkcmFmdC1oYXRhbmFrYS1hdnQtcnRw LWF0cmFjeC0wMy50eHQgaGFzIHJlY2VudGx5IGJlZW4gZGlzY3Vzc2VkIGFuZAogICAgIHNlZW1z IHRvIGJlIG5lZWRpbmcgc29tZSByZWRlc2lnbi4KCkRvY3VtZW50IHVwZGF0ZXMgb24gYmVoYWxm IG9mIHRoZSBhdXRob3JzCgogICBTZXZlcmFsIGF1dGhvcnMgd2VyZSBub3QgYWJsZSB0byBhdHRl bmQsIGJ1dCBpbnN0ZWFkIHJlcXVlc3RlZCB0aGF0IHRoZQogICBjaGFpcnMgcHJlc2VudCBhIGJy aWVmIHVwZGF0ZSBvbiB0aGVpciBkcmFmdDogCgogICAtIGRyYWZ0LWlldGYtYXZ0LXVscC0wOC50 eHQgaGFzIGJlZW4gdXBkYXRlZCwgd2l0aCB0aGUgbWFpbiBjaGFuZ2UgYmVpbmcKICAgICB0byBt b3ZlIGEgbnVtYmVyIG9mIGZpZWxkcyBmcm9tIHRoZSBSVFAgaGVhZGVyIHRvIHRoZSBwYXlsb2Fk IHNlY3Rpb24sCiAgICAgbWFraW5nIHRoZSBtYXNrIGZpZWxkIG9ubHkgMTYgYml0cy4gVGhpcyBo YXMgYmVlbiBhZGRyZXNzZWQgYnkgdXNpbmcgYQogICAgIGZsYWcgYml0IHRvIGluZGljYXRlIDE2 IG9yIDQ4IGJpdHMgb2YgbWFzayBmaWVsZC4gVGhlIGRyYWZ0IGlzIGV4cGVjdGVkIAogICAgIHRv IGFkdmFuY2UgcmF0aGVyIHF1aWNrbHkuCgogICAtIGRyYWZ0LWlldGYtYXZ0LXJ0cC1qcGVnMjAw MC0wNC50eHQgaGFzIGJlZW4gdXBkYXRlZCB3aXRoIHN1cHBvcnQgZm9yCiAgICAgaW50ZXJsYWNl ZCBpbWFnZXMuIE90aGVyIHVwZGF0ZXMgYXJlIHRleHQgY2xhcmlmaWNhdGlvbiwgTUlNRSBhbmQg U0RQCiAgICAgc2VjdGlvbiwgYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24uIFRoZSBhdXRob3Jz IGhhcyByZXF1ZXN0IFdHIGxhc3QKICAgICBjYWxsLiBDb2xpbiBQZXJraW5zIGhhcyBhdCBsZWFz dCBzb21lIGVkaXRvcmlhbCBjb21tZW50cywgYnV0IHRoZQogICAgIGRvY3VtZW50IGNhbiBiZSBl eHBlY3RlZCB0byBwcm9ncmVzcyByYXRoZXIgcXVpY2tseS4gCgogICAtIGRyYWZ0LWlldGYtYXZ0 LW1pZGktcnRwLTAwLnR4dCBhbmQgZHJhZnQtaWV0Zi1hdnQtbWlkaS1ndWlkZWxpbmVzLQogICAg IDAwLnR4dCwgdGhlIHVwZGF0ZWQgdmVyc2lvbnMgY29udGFpbnMgbW9zdGx5IGVkaXRvcmlhbCBj aGFuZ2VzIGFuZCAKICAgICBoYXZlIGJlZW4gcmVuYW1lZCBhbmQgcmVwdWJsaXNoZWQgYXMgd29y a2luZyBncm91cCBkb2N1bWVudHMuIEpvaG4KICAgICBMYXphcnJvIHBsYW5zIHRvIGVuc3VyZSBo ZSBoYXMgZmluaXNoZWQgaGlzIGltcGxlbWVudGF0aW9uIGJlZm9yZQogICAgIHJlcXVlc3Rpbmcg d29ya2luZyBncm91cCBsYXN0IGNhbGwgdG8gY2F0Y2ggYW55IGZpbmFsIGJ1Z3MgaW4gdGhlCiAg ICAgc3BlY2lmaWNhdGlvbi4gSG93ZXZlciwgaGUgZXhwZWN0cyB0byBoYXZlIGZpbmlzaGVkIHRo aXMgYnkgdGhlIGVuZCAKICAgICBvZiB0aGUgeWVhci4gCgogICAtIGRyYWZ0LWxhenphcm8tYXZ0 LXJ0cC1mcmFtaW5nLWNvbnRyYW5zLTAyLnR4dCwgY29udGFpbnMgZGVmaW5pdGlvbiBvZgogICAg IGZyYW1pbmcgb2YgUlRQIGFuZCBSVENQIGludG8gY29ubmVjdGlvbiBvcmllbnRlZCB0cmFuc3Bv cnQsIGludGVuZGVkCiAgICAgdG8gYmUgaW50ZXJvcGVyYWJsZSB3aXRoIHRoZSBkZWZpbml0aW9u cyB0aGF0IHdlcmUgaW4gUkZDIDE4ODkuIEl0IHdhcwogICAgIGFza2VkIGlmIHdlIHNob3VsZCBj b250aW51ZSB0aGlzIHBhdGgsIG9yIGRldmVsb3AgYSBkaWZmZXJlbnQgcHJvdG9jb2wgCiAgICAg YWxsb3dpbmcgZm9yIG11bHRpcGxleGluZyBvZiBSVFAgYW5kIFJUQ1Agb24gdGhlIHNhbWUgVENQ IGNvbm5lY3Rpb24/CiAgICAgUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgYW55IGNv bW1lbnRzIG9uIHRoaXMgaXNzdWUgdG8gdGhlCiAgICAgbGlzdC4KClJUUCBwYXlsb2FkIGZvcm1h dCBmb3IgQU1SLVdCKwo8ZHJhZnQtc2pvYmVyZy1hdnQtcnRwLWFtcndicGx1cy0wMC50eHQ+Cgog ICBBcmkgTGFrYW5pZW1pIHByZXNlbnRlZCBhbiBpbnRyb2R1Y3Rpb24gdG8gQU1SLVdCKyBjb2Rl YyBhbmQgcHJvcG9zZWQKICAgUlRQIHBheWxvYWQgZm9ybWF0LiAgVGhlIGNvZGVjIHNwZWNpZmlj YXRpb24gaXMgbm90IHlldCBmaW5pc2hlZCwgYnV0IAogICBpcyBleHBlY3RlZCB0byBiZSByZWFk eSBieSBNYXJjaC4gIFRoZSBwYXlsb2FkIGZvcm1hdCBpcyBiYXNlZCBvbiB0aGUKICAgcGF5bG9h ZCBmb3JtYXQgZm9yIEFNUiBhbmQgQU1SLVdCIChSRkMgMzI2NykuIFRoZSBjaGFuZ2VzIGFyZSBy ZW1vdmFsIAogICBvZiBiYW5kd2lkdGgtZWZmaWNpZW50IG1vZGUsIGEgUlRQIHRpbWVzdGFtcCBy YXRlIG9mIDk2IGtIeiwgYW5kIHRoZQogICByZW1vdmFsIG9mIHRoZSBwYXlsb2FkIGxldmVsIG11 bHRpLWNoYW5uZWwgZnVuY3Rpb25hbGl0eS4gCgogICBDb2xpbiBQZXJraW5zIGNvbW1lbnRlZCB0 aGF0IG11bHRpLWNoYW5uZWwgdXNhZ2UgaGFzIHByZXZpb3VzbHkgYmVlbgogICBzaWduYWxsZWQg b3V0IG9mIGJhbmQsIGhvd2V2ZXIgQU1SLVdCKyB1c2VzIGEgbW9kZSBmaWVsZCB0byBpbmRpY2F0 ZSBpZgogICBmcmFtZXMgY29udGFpbnMgbW9ubyBvciBzdGVyZW8gY29udGVudC4gTWFnbnVzIFdl c3Rlcmx1bmQgY29tbWVudGVkIHRoYXQKICAgYW55IGZ1dHVyZSBzaWduYWxsaW5nIGluIHRoaXMg YXJlYSBwcm9iYWJseSBuZWVkcyB0byBiZSBtb3JlIGdlbmVyYWwsCiAgIHNpbmNlIHRoZSBBVFJB Qy1YIHBheWxvYWQgZm9ybWF0IHByb3Bvc2VzIGEgc2ltaWxhciB0aGluZy4gCgogICBDb2xpbiBQ ZXJraW5zIGhhZCBhIGZ1cnRoZXIgY29tbWVudCB0aGF0IHRoZXJlIGFyZSBpbnRlcm9wZXJhYmls aXR5CiAgIGNvbnNpZGVyYXRpb25zIHNpbmNlIEFNUi1XQisgaXMgYSBzdXBlcnNldCBvZiBBTVIt V0IuIElmIGFuIEFNUi1XQisKICAgY2FwYWJsZSBlbmQtcG9pbnQgZG9lcyBub3QgYWxzbyBvZmZl ciBBTVItV0IgaW4gaXRzIGluaXRpYWwgb2ZmZXJzLAogICBhbiBBTVItV0Igb25seSBlbmQtcG9p bnQgd291bGQgZmFpbCB0byB1bmRlcnN0YW5kIHRoYXQgdGhleSBzaG91bGQKICAgYmUgYWJsZSB0 byBjb21tdW5pY2F0ZS4gVGhlIGRyYWZ0IG5lZWRzIHRvIGFkZHJlc3MgdGhpcyBjb25jZXJuLgoK ICAgQWxsaXNvbiBNYW5raW4sIHN0cmVzc2VkIHRoYXQgdGhpcyB3b3JrIGFzIGJlaW5nIHJlbGF0 ZWQgdG8gaW5jb21wbGV0ZQogICB3b3JrIGluIDNHUFAsIGFuZCBtYXkgbmVlZCB0ZWNobmljYWwg Y2hhbmdlcyBsYXRlciB0byBtYXRjaCBjaGFuZ2VzIGluCiAgIHRoZSBjb2RlYy4gSXQgd2FzIGZ1 cnRoZXIgbm90aWNlZCB0aGF0IHRoaXMgcGF5bG9hZCBmb3JtYXQgd2lsbCBub3QKICAgYWR2YW5j ZSB1bnRpbCB0aGUgM0dQUCBBTVItV0IrIGNvZGVjIHNwZWNpZmljYXRpb24gaXMgZnJvemVuLiAK CiAgIFRoZSBmdXR1cmUgd29yayBmcm9tIHRoZSBhdXRob3JzIHdpbGwgYmUgdG8gdHJhY2sgdGhl IGNvZGVjIGRldmVsb3BtZW50CiAgIHRvIGtlZXAgdGhlIHBheWxvYWQgZm9ybWF0IGFsaWduZWQg d2l0aCB0aGUgY29kZWMuIENvbW1lbnRzIGFib3V0IHRoZQogICBkZXNpZ24gY2hvaWNlcyBzbyBm YXIgYXJlIHNvbGljaXRlZC4gVGhlIGRyYWZ0IHdhcyBhY2NlcHRlZCBhcyBhbiBBVlQKICAgd29y ayBpdGVtIGluIHByaW5jaXBsZSwgc3ViamVjdCB0byByZXNvbHV0aW9uIG9mIHRoZSBzaWduYWxs aW5nIGlzc3Vlcy4KClJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgVk1SLVdCIAo8ZHJhZnQtYWhtYWRp LWF2dC1ydHAtdm1yLXdiLTAwLnR4dD4KCiAgIFNhc3NhbiBBaG1hZGkgbWFkZSBhbiBvdmVydmll dyBvZiB0aGUgVmFyaWFibGUgTXVsdGktUmF0ZSBXaWRlLUJhbmQKICAgc3BlZWNoIGNvZGVjIHdo aWNoIGlzIGFuIHNlbGVjdGVkIDNHUFAyIENETUEgMjAwMCBjb2RlYyBzaW5jZSBBcHJpbAogICAy MDAzLiBJdCBjb250YWlucyBhIGludGVyb3BlcmFiaWxpdHkgbW9kZSB0aGF0IHVzZXMgc29tZSBt b2RlcyBpZGVudGljYWwKICAgdG8gQU1SLVdCIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmlsaXR5IHdp dGggQU1SLVdCIG9ubHkgZW5kLXBvaW50cy4gVGhpcwogICB3aWxsIGFsbG93IGZvciBiZXR0ZXIg cXVhbGl0eSBhbmQgYmV0dGVyIGVmZmljaWVuY3kgYnkgcmVtb3ZpbmcgdGhlIG5lZWQKICAgZm9y IHRyYW5zY29kaW5nLiBUaGVyZSBpcyBhIGNsZWFyIGludGVyZXN0IGZvciBoYXZpbmcgdHdvIGRp ZmZlcmVudAogICBjaXJjdWl0IHN3aXRjaGVkIGNlbGx1bGFyIG5ldHdvcmtzIHVzaW5nIHRoZSBz YW1lIG9yIGludGVyb3BlcmFibGUKICAgc3BlZWNoIGNvZGVjIHRvIGJlIGNvbm5lY3RlZCB3aXRo IGFuIElQIG5ldHdvcmsuIAoKICAgVGhlIFZNUi1XQiBwYXlsb2FkIGZvcm1hdCBpcyBiYXNlZCBv biBSRkMzMjY3IHBheWxvYWQgZm9ybWF0LiBNb3N0IG9mCiAgIHRoZSBSRkMgMzI2NyBmdW5jdGlv bmFsaXR5IGlzIG1haW50YWluZWQsIGV4Y2VwdCBmb3IgYW55dGhpbmcgcmVsYXRlZCB0bwogICBV bmVxdWFsIEVycm9yIFByb3RlY3Rpb24gKFVFUCksIGFzIHRoZSBzcGVlY2ggZW5jb2RlciBpcyBk ZXNpZ24gdG8gd29yawogICBvdmVyIG5ldHdvcmsgd2l0aCBlcXVhbCBlcnJvciBwcm90ZWN0aW9u IG9mIHRoZSBlbmNvZGVkIHNwZWVjaCBiaXRzLiAKCiAgIFRoZSBtYWluIGlzc3VlIHJhaXNlZCBm b3IgYm90aCBBTVItV0IrIGFuZCBWTVItV0IgZm9ybWF0cyBpcyB0aGF0IHRoZXkKICAgYXJlIHN1 cGVyLXNldHMgb2YgdGhlIEFNUi1XQiBjb2RlYy4gVGhpcyBtYXkgcmVzdWx0IGluIHRocmVlIE1J TUUgdHlwZXMKICAgZXhpc3RpbmcgZm9yIHRoZSBzYW1lIGNvZGVjLiBIb3cgdGhpcyBzaWduYWxs aW5nIHByb2JsZW0gaXMgcmVzb2x2ZWQgdG8KICAgYXZvaWQgaW50ZXJvcGVyYWJpbGl0eSBwcm9i bGVtcyBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGJlZm9yZSBlaXRoZXIKICAgZHJhZnQgZ29lcyBm b3J3YXJkLiBUaG9tYXMgWmVuZyBhc2tlZCBpZiBpdCBpcyBwb3NzaWJsZSB0byBjb21lIHVwIHdp dGgKICAgYSBzaW5nbGUgcGF5bG9hZCBmb3JtYXQgdGhhdCB3b3VsZCB3b3JrIGZvciBhbGwgdGhl IHRocmVlIGNvZGVjcyAoQU1SLAogICBBTVItV0IsIEFNUi1XQisgYW5kIFZNUi1XQikgdG8gcmVk dWNlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuIEl0CiAgIGNvdWxkIGJlIGRlc2lyYWJsZSB0 byBoYXZlIHN1Y2ggYSBzb2x1dGlvbiBhbmQgaXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQuCgogICBT YXNzYW4gcmVxdWVzdGVkIHRoYXQgdGhlIHdvcmsgYmUgYWNjZXB0ZWQgYXMgYW4gQVZUIHdvcmsg aXRlbS4gQ29saW4KICAgUGVya2lucyBjb21tZW50ZWQgdGhhdCBoZSBoYXMgbm8gcHJpbmNpcGFs IHByb2JsZW1zIG9mIGFjY2VwdGluZyB0aGlzIAogICBhcyBhIHdvcmsgaXRlbSwgYXMgbG9uZyBh cyBpdCBpcyBndWFyYW50ZWVkIHRoYXQgdGhlIGNvZGVjcyB3aWxsIGJlCiAgIGFjY2VwdGVkLCBh bmQgdGhlIHNpZ25hbGxpbmcgaXNzdWUgaXMgcmVzb2x2ZWQuIFNhc3NhbiBhbnN3ZXJlZCB0aGF0 IAogICB0aGUgY29kZWMgaXMgY3VycmVudGx5IHVuZGVyZ29pbmcgY2hhcmFjdGVyaXNhdGlvbiB0 ZXN0cyBhbmQgdGhhdCBmaW5hbAogICBzcGVjaWZpY2F0aW9uIHdpbGwgYmUgYXZhaWxhYmxlIGlu IEFwcmlsIDIwMDQuIAoKUlRQIHBheWxvYWQgZm9ybWF0cyBmb3IgRVRTSSBEU1IgY29kZWNzIAo8 ZHJhZnQtaWV0Zi1hdnQtZHNyLWVzMjAyMDUwLTAxLnR4dD4gCjxkcmFmdC14aWUtYXZ0LXhkc3It ZXMyMDIyMTEtMDAudHh0PiAKPGRyYWZ0LXhpZS1hdnQteGFkc3ItZXMyMDIyMTItMDAudHh0PiAK CiAgIFFpYW9iaW5nIFhpZSBkaXNjdXNzZWQgdGhlIHRocmVlIEVUU0kgRFNSIGNvZGVjcyB3aXRo b3V0IGFuIFJUUCBwYXlsb2FkCiAgIGZvcm1hdCBzbyBmYXIuICBIZSBvdXRsaW5lZCBob3cgdGhh dCByZWxhdGUgdG8gdGhlIERTUiBjb2RlYyB0aGF0IGhhcyBhCiAgIHBheWxvYWQgZm9ybWF0IGlu IFJGQyAzNTU3LiBGcm9tIGFuIFJUUCBwYXlsb2FkIGZvcm1hdCB0aGUgZGlmZmVyZW5jZSBpcwog ICB0d28gcG9zc2libGUgZnJhbWUgbGVuZ3RocyBhbmQgdGhlaXIgaW50ZXJuYWwgZnJhbWUgZGVm aW5pdGlvbiB0aGF0IG5lZWQKICAgdG8gYmUgaW5kaWNhdGVkIHRocm91Z2ggc2lnbmFsbGluZy4K CiAgIEl0IHdhcyBwcmV2aW91c2x5IHN1Z2dlc3RlZCB0aGF0IHRoZSB0aHJlZSBkcmFmdHMgc2hv dWxkIGJlIG1lcmdlZCBpbnRvCiAgIGEgc2luZ2xlIGRvY3VtZW50LCBhcyB0aGV5IGFyZSB2ZXJ5 IHNpbWlsYXIuIFRoaXMgcXVlc3Rpb24gd2FzIGFza2VkIHRvCiAgIHRoZSBncm91cCwgYnV0IG5v IGNvbW1lbnRzIHdlcmUgcmVjZWl2ZWQuIAoKaUxCQyBjb2RlYyBhbmQgUlRQIHBheWxvYWQgZm9y bWF0IAo8ZHJhZnQtaWV0Zi1hdnQtaWxiYy1jb2RlYy0wMz4gCjxkcmFmdC1pZXRmLWF2dC1ydHAt aWxiYy0wMz4KCiAgIEFsYW4gRHVyaWMgcHJlc2VudGVkIHRoZSBtb3N0IHJlY2VudCBjaGFuZ2Vz IHRvIHRoZSBkcmFmdHMuIFNlZSB0aGUKICAgcHJlc2VudGF0aW9uIHNsaWRlcyBmb3IgdGhlIGxp c3Qgb2YgY2hhbmdlcy4gQWxhbiByZXF1ZXN0ZWQgdGhhdCB3b3JraW5nCiAgIGdyb3VwIGxhc3Qg Y2FsbCBiZSBpc3N1ZWQgZm9yIGJvdGggZHJhZnRzLiAgQ29saW4gUGVya2lucyBjb21tZW50ZWQg dGhhdAogICBiZXNpZGUgc29tZSBuaXRzLCB0aGUgb25seSBzdWJzdGFudGlhbCBjb21tZW50IHJl Z2FyZHMgdHdvIHN0YXRlbWVudHMgaW4KICAgdGhlIGJvdGggZHJhZnRzLCByZWdhcmRpbmcgdGhl IGZyZWUtd2FyZSBuYXR1cmUgb2YgaUxCQyBhbmQgdGhhdCBDYWJsZUxhYnMgCiAgIGludGVuZHMg dG8gaW5jbHVkZSBpdCBpbiBvbmUgb2YgaXRzIHNwZWNpZmljYXRpb25zLCBzaW5jZSB0aGVzZSBj b25mbGljdAogICB3aXRoIElFVEYgSVBSIGRpc2Nsb3N1cmUgcnVsZXMgKHRoZXkgc2hvdWxkIGJl IGluIGFuIElQUiBzdGF0ZW1lbnQsIG5vdAogICBpbiB0aGUgZHJhZnQpLgoKICAgQXMgc29vbiBh biB1cGRhdGVkIHZlcnNpb25zIGFyZSBhdmFpbGFibGUgaXQgd2lsbCBiZSBsYXN0IGNhbGxlZC4g VGhlCiAgIGNvZGVjIGlzIGludGVuZGVkIHRvIGdvIHRvIEV4cGVyaW1lbnRhbCBzdGF0dXMsIGFu ZCB0aGUgcGF5bG9hZCBmb3JtYXQKICAgZm9yIHN0YW5kYXJkcyB0cmFjayBhcyBwcm9wb3NlZC4g QWxsaXNvbiBNYW5raW4gcHJvbWlzZWQgdG8gcHJvdmlkZSBhCiAgIGJvaWxlcnBsYXRlIGZvciB0 aGUgY29kZWMgZHJhZnQgdGhhdCBzcGVjaWZpZXMgdGhlIGludGVudGlvbiBvZiBnb2luZyB0bwog ICBpbmZvcm1hdGlvbmFsIHdoZW4gbW9yZSBleHBlcmllbmNlIGhhcyBiZWVuIGdhdGhlcmVkIHJl Z2FyZGluZyB0aGUKICAgY29kZWMuIAoKUlRQIHBheWxvYWQgZm9ybWF0IGZvciBjb252ZXJzYXRp b25hbCB0ZXh0IAo8ZHJhZnQtaGVsbHN0cm9tLWF2dC1yZmMyNzkzYmlzLTAyLnR4dD4KCiAgIEd1 bm5hciBIZWxsc3Ry9m0gcHJlc2VudGVkIHRoaXMgdXBkYXRlIHRvIFJGQyAyNzkzLCB3aGljaCBi b3RoIHVwZGF0ZXMKICAgdGhlIHBheWxvYWQgZm9ybWF0LCBhbmQgYWxzbyBkZWZpbmVzIGEgbmV3 IGZvcm1hdCBpbnRlbmRlZCBmb3IgZ2F0ZXdheQogICB1c2FnZSBhbGxvd2luZyBmb3IgYXVkaW8g YW5kIHRleHQgbXVsdGlwbGV4aW5nIGluIHRoZSBzYW1lIFJUUCBzZXNzaW9uLgogICBUaGVyZSB3 aGVyZSBzb21lIGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBSVFAgcHJvZmlsZSBpbmRlcGVuZGVu Y3kgb2YKICAgdGhlIGZvcm1hdCwgdG8gYXZvaWQgY29uZnVzaW9uLiBUaGUgcmVnaXN0cmF0aW9u IG9mICJ0ZXh0L3JlZCIgc2hvdWxkCiAgIGFsc28gYmUgbW92ZWQgaW50byBhIHNlcGFyYXRlIGRv Y3VtZW50LiAKCiAgIFRoZSBuZXcgZm9ybWF0IGZvciBnYXRld2F5IHVzZSBpcyBzaWduYWxsZWQg YnkgdGhlICJhdWRpby90MTQwIiBNSU1FCiAgIHR5cGUgd2l0aCB2YXJpb3VzIHBhcmFtZXRlcnMu IEl0IHdhcyBub3RlZCB0aGF0IHRoZSBzaWduYWxsZWQgcmF0ZSBpbgogICBjaGFyYWN0ZXJzLXBl ci1zZWNvbmQgY2Fubm90IGJlIGd1YXJhbnRlZWQgb24gdGhlIHJlY2VpdmVyIHNpZGUgZHVlIHRv CiAgIG5ldHdvcmsgaml0dGVyLiAgCgogICBUaGUgZHJhZnQgZGVmaW5lcyBhbiBpbnRlcm5hbCBi bG9jayBzZXF1ZW5jZSBudW1iZXIgaW4gYWRkaXRpb24gdG8gdGhlCiAgIFJUUCBzZXF1ZW5jZSBu dW1iZXIuIENvbGluIFBlcmtpbnMgY29tbWVudGVkIHRoYXQgd2hlbiBzd2l0Y2hpbmcgZnJvbQog ICBhdWRpbyB0byB0ZXh0LCBpdCBpcyBwb3NzaWJsZSBmb3IgdGhlIGxhc3QgcGFja2V0IG9mIGF1 ZGlvIHRvIGJlIGxvc3QsCiAgIGJ1dCBub3QgZGV0ZWN0ZWQuIEhlbm5pbmcgU2NodWx6cmlubmUg bm90ZWQgdGhhdCB0aGlzIGNhbiBiZSBhZGRyZXNzZWQKICAgYnkgdXNpbmcgUkZDIDIxOTggcmVk dW5kYW5jeSB0byBsb3dlciB0aGF0IHJpc2sgYXMgZG9uZSBpbiBSRkMgMjgzMy4gQQogICBmdXJ0 aGVyIGNvbW1lbnQgaXMgdGhhdCBhdWRpby90MTQwIGlzIGNhcGFibGUgb2YgaGFuZGxpbmcgYW55 IG9mIHRoZQogICByZWR1bmRhbmN5IG1lY2hhbmlzbSwgc28gYm90aCBSRkMgMjczMyBhbmQgUkZD IDIxOTggY2FuIGJlIHVzZWQuIFRodXMKICAgdGhlcmUgaXMgcHJvYmFibHkgbm8gbmVlZCB0byBt ZW50aW9uIGVpdGhlciBvZiB0aGVtIGV4cGxpY2l0bHkuIE1hZ251cwogICBXZXN0ZXJsdW5kIGNv bW1lbnRlZCB0aGF0IHRoZSB1c2FnZSBvZiBSRkMgMjE5OCBpcyBxdWl0ZSByZXN0cmljdGVkIGR1 ZQogICB0byB0aGUgc21hbGwgbWF4aW11bSB0aW1lc3RhbXAgb2Zmc2V0IGZvciBhIHJlZHVuZGFu Y3kgcGFja2V0ICgxNCBiaXRzKSwKICAgcmVzdWx0aW5nIGluIHRoYXQgYSAxNmtIeiB0aW1lc3Rh bXAgcmF0ZSB3aWxsIG9ubHkgYWxsb3cgcmVkdW5kYW50IGJsb2NrCiAgIGZyb20gdGhlIGxhc3Qg c2Vjb25kLiAKCiAgIEd1bm5hciBhbHNvIHBvaW50ZWQgb3V0IHRoYXQgSVRVLVQgU0cgMTYgaGFz IGEgZGVzaXJlIHRvIGhhdmUgdGhpcwogICBmb3JtYXQgYXZhaWxhYmxlIGluIEZlYnJ1YXJ5IDIw MDQuIFRvIG1lZXQgdGhpcyBnb2FsIHRoZXJlIGlzIG5lZWQgdG8KICAgbW92ZSBxdWlja2x5LCBt dWx0aXBsZSByZXZpc2lvbnMgYXJlIHByb2JhYmx5IG5lZWRlZCBiZWZvcmUgdGhlIGVuZCBvZgog ICB0aGUgeWVhci4gCgogICBUaGUgY29uc2Vuc3VzIG9mIHRoZSByb29tIHdhcyB0aGF0IGl0IGlz IGFwcHJvcHJpYXRlIHRvIGFjY2VwdCB0aGlzIGFzCiAgIGFuIEFWVCB3b3JrIGl0ZW0sIGhvd2V2 ZXIgQ29saW4gSmFtZXMgbWFkZSBhbiBvYmplY3Rpb24gYWdhaW5zdCB0aGUKICAgY3VycmVudCBz b2x1dGlvbiBiZWNhdXNlIGl0IGhhc24ndCBiZWVuIHN1ZmZpY2llbnRseSByZXZpZXdlZCwgYW5k IGhlCiAgIHdhcyBub3QgY29udmluY2VkIHRoYXQgaXQgd2FzIHRoZSBzaW1wbGVzdCBwb3NzaWJs ZSBzb2x1dGlvbiBhbGxvd2luZwogICBmb3IgZWFzaWVzdCBpbXBsZW1lbnRhdGlvbiBzaW1wbGlm eWluZyBkZXBsb3ltZW50LiAKClJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgM0dQUCBUaW1lZCBUZXh0 CjxkcmFmdC1yZXktYXZ0LTNncHAtdGltZWQtdGV4dC0wMS50eHQ+CgogICBKb3PpIFJleSBwcmVz ZW50ZWQgdGhlIG9wZW4gaXNzdWVzIHJlZ2FyZGluZyB0aGUgZm9ybWF0LiBUaGUgbWFpbgogICBk aXNjdXNzaW9uIGhhcyBjb25jZXJuZWQgaWYgdGhlIGZvcm1hdCBzaG91bGQgYmUgbWFkZSBnZW5l cmljLCBvcgogICBzcGVjaWZpYyBmb3IgZWFjaCB0aW1lZCB0ZXh0IGZvcm1hdC4gVGhlcmUgaXMg d29yayBpbiBib3RoIE1QRUcgYW5kIFczQwogICB0byBkZWZpbmUgYWRkaXRpb25hbCB0aW1lZCB0 ZXh0IGZvcm1hdHMsIGhvd2V2ZXIgdGhleSBhcmUgbm90IHlldCByZWFkeS4KICAgVGhlcmUgaXMs IGhvd2V2ZXIsIGEgY2xlYXIgZGVzaXJlIHRvIGZpbmlzaCB0aGlzIHBheWxvYWQgZm9ybWF0IGZv ciAzR1BQCiAgIHRpbWVkIHRleHQgaW4gdGhlIDNHUFAgUmVsZWFzZSA2IHRpbWVmcmFtZSwgaS5l LiAgYnkgTWFyY2ggMjAwNC4gVG8gbWVldAogICB0aGUgZGVhZGxpbmUgdGhlcmUgaXMgbmVlZCB0 byBtb3ZlIG11Y2ggcXVpY2tlciB0aGFuIHdoYXQgaGFzIHByZXZpb3VzbHkKICAgYmVlbiBkb25l LiAKCiAgIEFuIGlucHV0IGluIHRoaXMgZGlzY3Vzc2lvbiB3YXMgZW1haWwgdG8gQVZUIG1haWxp bmcgbGlzdCBmcm9tIEphbiB2YW4KICAgZGVyIE1lZXIsIHByb3Bvc2luZyB0aGF0IE1QRUctNCBT SU1QTEUgcGF5bG9hZCBmb3JtYXQgaXMgdXNlZC4gRnVydGhlcgogICBkaXNjdXNzaW9uIG9uIHRo ZSBsaXN0IGlzIGVuY291cmFnZWQgdG8gYWxsb3cgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvCiAg IGRldGVybWluZSBpZiB0aGVyZSBzaG91bGQgYmUgb25lIHBheWxvYWQgZm9ybWF0IGZvciBhbGwg dGV4dCB1c2FnZSBvcgogICBvbmUgZm9yIGVhY2ggImNvZGVjIiBkZWZpbml0aW9uPyAKCiAgIEFu b3RoZXIgY29tbWVudCB0aGF0IHdhcyByYWlzZWQgd2FzIGlzIHRoYXQgaXQgaXMgdmVyeSBjb21w bGV4IHNvbHV0aW9uLgogICBXZSBzaG91bGQgY29uc2lkZXIgaWYgdGhlIGZvcm1hdCBzaG91bGQg cmF0aGVyIGJlIGRlc2lnbmVkIGFzIHRyYW5zcG9ydAogICBmb3JtYXQgb2YgdGhlIHNlbWFudGlj cywgcmF0aGVyIHRoZW4gYmVpbmcgYSB0cmFuc3BvcnQgb2YgYSBmaWxlIGZvcm1hdC4gCgpSVFAg cGF5bG9hZCBmb3JtYXQgZm9yIFVuY29tcHJlc3NlZCBWaWRlbwo8ZHJhZnQtaWV0Zi1hdnQtdW5j b21wLXZpZGVvLTA0LnR4dD4KCiAgIFRoZSBjaGFuZ2VzIHRvIHRoZSBkcmFmdCB3ZXJlIHByZXNl bnRlZCBieSBMYWRhbiBHaGFyYWkuIFRoZSBjaGFuZ2UgbGlzdAogICBpcyBhdmFpbGFibGUgaW4g dGhlIHByZXNlbnRhdGlvbi4gQSBjb21tZW50IHJhaXNlZCBpcyB0aGF0IHRoZSBkcmFmdAogICBw cm9iYWJseSBzaG91bGQgZGVmaW5lIHRoZSBHYW1tYSB2YWx1ZSB0aGUgdmlkZW8uICBNYWdudXMg V2VzdGVybHVuZAogICBhc2tlZCBpZiB0aGUgYXV0aG9ycyBoYXMgY29uc2lkZXJlZCB0aGUgdXNh Z2Ugb2YgdGhlIElQdjYganVtYm9ncmFtIGFuZAogICBpZiB0aGUgYnl0ZSBvZmZzZXQgZmllbGQg d2lsbCBjcmVhdGUgYW55IHByb2JsZW0gYXMgYmVpbmcgdG8gc21hbGwgZm9yCiAgIHJlYWxseSBs YXJnZSBwaWN0dXJlIHNpemVzLiBCZXNpZGVzIHRoZXNlLCBhbmQgc29tZSBlZGl0b3JpYWwgY29t bWVudHMsCiAgIHRoZSBkcmFmdCBzZWVtcyB0byBiZSBpbiBnb29kIHNoYXBlLCBhbmQgYSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBpcwogICBleHBlY3RlZCB3aGVuIHRoZSBuZXh0IHJldmlzaW9u IGJlY29tZXMgYXZhaWxhYmxlLiAKCiAgIEFsbGlzb24gTWFua2luIGFsc28gYXNrZWQgaWYgdGhl IGRyYWZ0IGhhZCBhIHN0cmljdCB3b3JkaW5nIChNVVNUKSBhYm91dAogICB0aGUgbmVlZCBvZiBi ZWluZyBjb25nZXN0aW9uIGF3YXJlLCBkdWUgdG8gY29tbWVudHMgcmVjZWl2ZWQgcmVnYXJkaW5n CiAgIFJGQyAzNDk3LiBDb2xpbiBQZXJraW5zIHJlc3BvbmRlZCB0aGF0IFJGQyAzNDk3IGhhcyB0 aGUgcmVxdWVzdGVkCiAgIHN0cmVuZ3RoIGluIHdvcmRpbmcsIGFuZCB3b3VsZCBlbnN1cmUgdGhh dCBhbHNvIHRoaXMgZHJhZnQgaGFzIGl0LiAKClJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgSC4yNjQg VmlkZW8KPGRyYWZ0LWlldGYtYXZ0LXJ0cC1oMjY0LTAzLnR4dD4KCiAgIE1hZ251cyBXZXN0ZXJs dW5kIG91dGxpbmVkIHJlY2VudCBjaGFuZ2VzIGluIHRoZSBSVFAgZm9ybWF0IGZvciBILjI2NAog ICB2aWRlby4gIFRoZXJlIHdlcmUgdHdvIHBhY2tldGlzYXRpb24gbW9kZXMgaW4gdGhlIHByZXZp b3VzIGRyYWZ0LCBvbmUKICAgd2l0aCBkZWNvZGluZyBvcmRlciBudW1iZXJzIChET05zKSwgYW5k IG9uZSB3aXRob3V0LiBUaGUgcnVsZXMgZm9yIHdoZW4KICAgRE9OcyBzaG91bGQgYmUgdXNlZCB3 ZXJlIHVuY2xlYXIuIFRoZSBuZXcgdmVyc2lvbiBzaW1wbGlmaWVzIHRoZXNlCiAgIHJ1bGVzOiB0 aGUgRE9OIGlzIGVpdGhlciBhbHdheXMgcHJlc2VudCwgb3IgbmV2ZXIgcHJlc2VudC4gVGhpcyBn aXZlcwogICB0aHJlZSBwYWNrZXRpc2F0aW9uIG1vZGVzOiBzaW5nbGUgTkFMIHVuaXQgbW9kZSwg bm9uLWludGVybGVhdmVkIHdpdGgKICAgU1RBUHMsIGFuZCBpbnRlcmxlYXZlZCB3aXRoIE1UQVBz LgoKICAgQW4gYWRkaXRpb25hbCBpbnRlcmxlYXZpbmcgcGFyYW1ldGVyLCBtYXgtZG9uLWRpZmYs IHdhcyBhZGRlZCB0byBoZWxwCiAgIGNvbnRyb2wgaW50ZXJsZWF2aW5nLiBUaGlzIGdpdmVzIHRo ZSBtYXhpbXVtIGRpc3BsYWNlbWVudCBpbiB0ZXJtcyBvZgogICB0aGUgRE9OLCBtdWNoIGluIHRo ZSBzdHlsZSBvZiB0aGUgTVBFRy00IHBheWxvYWQgZm9ybWF0LgoKICAgTWlub3IgYnVnIGZpeGVz IGluY2x1ZGU6IGFzc2lnbm1lbnQgb2YgRE9OIHZhbHVlcyBmb3IgU1RBUC1CIHBhY2tldHMgd2Fz CiAgIGNvcnJlY3RlZCBhbmQgY2xhcmlmaWVkLCBkZXJpdmF0aW9uIG9mIHRoZSBET04gZm9yIE1U QVBzIHdhcyBjaGFuZ2VkIHRvCiAgIGFsbG93IHdyYXBhcm91bmQgb2YgdmFsdWVzIHdpdGhpbiBv bmUgTVRBUCwgdGhlIHVzZSBvZiB0aGUgUlRQIHRpbWVzdGFtcAogICBhbmQgcGljdHVyZSB0aW1p bmcgU0VUIG1lc3NhZ2UgaGFzIGJlZW4gY2xhcmlmaWVkLCBhbmQgQmFzZTY0IGVuY29kaW5nCiAg IGlzIG5vdyB1c2VkIGluIHRoZSAicGFyYW1ldGVyLXNldHMiIE1JTUUgcGFyYW1ldGVyLgoKICAg RGF2ZSBMaW5kYmVyZyBub3RlZCB0aGF0IG5ldHdvcmsgU0xBcyBhcmUgb2Z0ZW4gYmFzZWQgb24g UlRDUCBqaXR0ZXIsCiAgIGJ1dCBILjI2NCBiaS1wcmVkaWN0aXZlIHNsaWNlcyBkaXNydXB0IHRo ZSBqaXR0ZXIgY2FsY3VsYXRpb24uIFRoaXMgaXMKICAgY29tbW9uIHRvIG1hbnkgcGF5bG9hZCBm b3JtYXRzLCBhbmQgbWFrZXMgdGhlIFJUQ1Agaml0dGVyIG1lYXN1cmVtZW50cwogICB1c2VsZXNz IGZvciBtZWFzdXJpbmcgbmV0d29yayBwZXJmb3JtYW5jZS4gRGF2ZSBhc2tlZCBmb3IgYSBub3Rl IHRvIGJlCiAgIGluc2VydGVkIGludG8gdGhlIGRyYWZ0LCB0byBjbGFyaWZ5IHRoZSBpc3N1ZSwg YW5kIHNvbGljaXRlZCBpbnB1dCBmcm9tCiAgIG5ldHdvcmsgb3BlcmF0b3JzIG9uIGhvdyB0aGV5 IGludGVuZCB0byBkZWFsIHdpdGggdGhpcyBpc3N1ZSBpbiB0aGUKICAgZGVzaWduIG9mIHRoZWly IFNMQXMuCgogICBUaGVyZSBhcmUgc2V2ZXJhbCBvcGVuIGlzc3VlczogdGhlIHNlY3VyaXR5IHNl Y3Rpb24gbmVlZHMgcmV2aWV3OyBkb2VzCiAgIHRoZSBiZW5lZml0IG9mIHRoZSBtYXgtZG9uLWRp ZmYgcGFyYW1ldGVyIG91dHdlaWdoIHRoZSBjb21wbGV4aXR5IGl0CiAgIGJyaW5nczsgYW5kIHNo b3VsZCBNSU1FIHBhcmFtZXRlcnMsIHNpbWlsYXIgdG8gdGhlIEguMjQxIEN1c3RvbU1heE1CUFMs CiAgIEN1c3RvbU1heEZTLCBDdXN0b21NQWNEUEIgYW5kIGN1c3RvbU1heEJSYW5kQ1BCLCBiZSBh ZGRlZD8gT24gdGhlIGxhdGVyCiAgIHN1YmplY3QsIERhdmUgTGluZGJlcmcgLSBub3RpbmcgdGhh dCBoZSdzIHRoZSBlZGl0b3Igb2YgSC4yNDEgaW4gSVRVIC0KICAgZ2F2ZSBhbiAiZW50aHVzaWFz dGljIHllcyIsIHNpbmNlIHRoZSBwcm9maWxlcyBhbmQgbGV2ZWxzIGluIEguMjY0IHdlcmUKICAg ZGVzaWduZWQgZm9yIG1vcmUgdHJhZGl0aW9uYWwgYXBwbGljYXRpb25zLCBhbmQgdGhlc2UgcGFy YW1ldGVycyBhcmUKICAgdmVyeSB1c2VmdWwgdG8gc3VwcG9ydCBlbWVyZ2luZyBhcHBsaWNhdGlv bnMuIAoKICAgQ29saW4gUGVya2lucyBhc2tlZCBhYm91dCBOb2tpYSdzIElQUiBzdGF0ZW1lbnQg Zm9yIHRoaXMgZHJhZnQsIHdoaWNoCiAgIGdyYW50cyBhIHJveWFsdHkgZnJlZSBsaWNlbnNlLCBw cm92aWRlZCB0aGUgSC4yNjQgYmFzZSBhbHNvIGhhcyBhCiAgIHJveWFsdHkgZnJlZSBsaWNlbnNl LiBEb2VzIHRoZSBILjI2NCBiYXNlIGhhdmUgc3VjaCBhIGxpY2Vuc2U/IE5vOiBpdAogICBzZWVt cyB1bmxpa2VseSB0aGF0IGFueSBwYXJ0IG9mIEguMjY0IHdpbGwgYmUgcm95YWx0eSBmcmVlLiBU aGUgSVBSCiAgIGNvbmRpdGlvbnMgb24gdGhlIHBheWxvYWQgZm9ybWF0IGFwcGVhciB0byBiZSBu byBtb3JlIHJlc3RyaWN0aXZlIHRoYW4KICAgdGhvc2Ugb24gdGhlIGNvZGVjLiAKCiAgIFRob21h cyBaZW5nIG5vdGVkIHRoYXQgdGhlIG1heC1kb24tZGlmZiBpcyB1bmRlZmluZWQgaWYgbm90IHNp Z25hbGxlZCwKICAgYnV0IHRoYXQgdGhlIHJlY2VpdmVyIGlzIGV4cGVjdGVkIHRvIHVzZSB0aGlz IGluIHRoZSBkZWNvZGluZyBwcm9jZXNzLgogICBNYWdudXMgc2FpZCB0aGF0IHRoaXMgaXMgYSBj b21wbGV4IGlzc3VlLCBhbmQgdGhhdCBpdCdzIG5vdCBvYnZpb3VzIHdoYXQKICAgaXMgdGhlIGJl c3QgYnVmZmVyaW5nIHN0cmF0ZWd5IGZvciBhIHJlY2VpdmVyIHdoZW4gaW50ZXJsZWF2aW5nIGlz IHVzZWQuCiAgIFRoZSBtYXgtZG9uLWRpZmYgcGFyYW1ldGVyIGlzIGV4cGVjdGVkIHRvIGJlIHVz ZWQgYXMgYW4gaW50ZXJsZWF2aW5nCiAgIGRlcHRoIGluZGljYXRvciwgdG8gc2ltcGxpZnkgdGhp cyBwcm9jZXNzLiBUaG9tYXMgY29tcGxhaW5lZCBhYm91dCB0aGUKICAgY29tcGxleGl0eSBvZiB0 aGUgdGVybWlub2xvZ3ksIGFuZCBjbGFyaWZpY2F0aW9uIGlzIHByb2JhYmx5IG5lZWRlZC4KClJU Q1AgRXh0ZW5zaW9ucyBmb3IgU1NNIHdpdGggVW5pY2FzdCBGZWVkYmFjawo8ZHJhZnQtaWV0Zi1h dnQtcnRjcHNzbS0wNS50eHQ+CgogICBK9nJnIE90dCB1cGRhdGVkIHRoZSBncm91cCBvbiBjaGFu Z2VzIHRvIHRoZSBSVENQIEV4dGVuc2lvbnMgZm9yIFNTTQogICB3aXRoIFVuaWNhc3QgRmVlZGJh Y2sgPGRyYWZ0LWlldGYtYXZ0LXJ0Y3Bzc20tMDUudHh0PiBzaW5jZSB0aGUgNTd0aAogICBJRVRG IG1lZXRpbmcuIFRoZXJlIGFyZSAyIG9wZW4gaXNzdWVzLCBiZXNpZGVzIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLAogICByZW1haW5pbmc6IGhvdyB0byBmb3JtIGNvbXBvdW5kIHBhY2tldHMgYW5k IGhvdyB0byBkZXRlcm1pbmUgdGhlIFJUQ1AKICAgYmFuZHdpZHRoLgoKICAgUkZDIDM1NTAgcmVx dWlyZXMgYWxsIFJUQ1AgcGFja2V0cyB0byBiZSBjb21wb3VuZCBwYWNrZXRzLCBzdGFydGluZyB3 aXRoCiAgIGVpdGhlciBhbiBTUiBvciBSUiBwYWNrZXQuIFRoaXMgZHJhZnQgcmVxdWlyZXMgc291 cmNlcyB0byBzZW5kIHJlY2VwdGlvbgogICBxdWFsaXR5IHN1bW1hcnkgKCJSU0kiKSBwYWNrZXRz LCBidXQgaXQncyB1bmNsZWFyIGlmIHRoZXNlIHNob3VsZCBmb2xsb3cKICAgYW4gU1Igb3IgUlIg cGFja2V0LiAgSvZyZyBzdWdnZXN0ZWQgdGhhdCBpdCB3b3VsZCBiZSBjbGVhbmVzdCB0byBpbmNs dWRlCiAgIFJTSSBwYWNrZXRzIGluIGEgY29tcG91bmQgUlRDUCBwYWNrZXRzIHdpdGggU1IgZGF0 YSwgYnV0IHRoaXMgcmFpc2VzIHRoZQogICBpc3N1ZSBvZiBob3cgdG8gc3BsaXQgUlRDUCBiYW5k d2lkdGggYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyLCBhbmQKICAgbWVhbnMgdGhhdCB0aGUg dGltZXN0YW1wIGluIFJTSSBwYWNrZXRzIGlzIHJlZHVuZGFudC4gIENvbGluIFBlcmtpbnMKICAg YWdyZWVkIHRoYXQgaW5jbHVkaW5nIFJTSSBwYWNrZXRzIHdpdGggU1IgcGFja2V0cyBpcyBhcHBy b3ByaWF0ZSwgc2luY2UKICAgdGhlIHJlcG9ydHMgYXJlIGNvbWluZyBmcm9tIHRoZSBzZW5kZXIu CgogICBUaGVyZSBhcmUgdHdvIGFsdGVybmF0aXZlcyB0byBjb250cm9sIHRoZSBSVENQIGJhbmR3 aWR0aDogZGlzdHJpYnV0ZSB0aGUKICAgY3VycmVudCBncm91cCBzaXplIGluIFJTSSBwYWNrZXRz IGFuZCBsZXQgdGhlIHJlY2VpdmVycyBjYWxjdWxhdGUgdGhlaXIKICAgcmVwb3J0aW5nIGludGVy dmFsLCBvciBub3RpZnkgcmVjZWl2ZXJzIGFib3V0IHRoZSBhbGxvd2FibGUgYmFuZHdpZHRoLgog ICBUaGUgZm9ybWVyIGlzIGNsb3NlciB0byB0aGUgc3RhbmRhcmQgUlRDUCBhbGdvcml0aG0sIHRo ZSBsYXR0ZXIgYWxsb3dzCiAgIHRoZSBzZW5kZXIgdG8ga2VlcCB0aGUgZ3JvdXAgc2l6ZSBjb25m aWRlbnRpYWwuIFRoZSBkcmFmdCBjdXJyZW50bHkKICAgYWxsb3dzIGJvdGggYWx0ZXJuYXRpdmVz LCBidXQgdGhpcyBtYXkgbm90IGJlIGlkZWFsIChhbmQgcmVxdWlyZXMgc29tZQogICBjbGFyaWZp Y2F0aW9uIG9mIHRoZSBjYXNlIHdlcmUgYXJlIHNpZ25hbGxlZCBmb3IgYSBzZXNzaW9uKS4gSW5w dXQgaXMKICAgc29saWNpdGVkLgoKICAgQ29saW4gUGVya2lucyBhc2tlZCBpZiB0aGVyZSBpcyBh biBpc3N1ZSByZWdhcmRpbmcgc3RlcCBqb2lucyBhbmQgbGVhdmVzCiAgIHdoZW4gdGhlIGdyb3Vw IHNpemUgaXMgZXhwbGljaXRseSBjb252ZXllZD8gVGhpcyBpcyB0aGUgcmVhc29uIHdoeSB0aW1l cgogICByZWNvbnNpZGVyYXRpb24gd2FzIGFkZGVkIHRvIFJUQ1AsIGFuZCBpdCBtYXkgYmUgbmVj ZXNzYXJ5IHRvIGRlZmluZSBob3cKICAgdGhlIGV4dGVuc2lvbnMgaW50ZXJhY3Qgd2l0aCByZWNv bnNpZGVyYXRpb24uCgogICBOZXh0IHN0ZXBzIGFyZSB0byBmaXggdGhlIGVkaXRvcmlhbCBuaXRz LCBwcm92aWRlIG1vcmUgZGV0YWlsIG9uIGhvdyAKICAgdGhlIGRpc3RyaWJ1dGlvbiBzb3VyY2Ug Z2VuZXJhdGVzIFJTSSBwYWNrZXRzLCBhbmQgdG8gcmV3b3JrIHNlY3VyaXR5CiAgIGNvbnNpZGVy YXRpb25zIHNlY3Rpb24gdG8gZ2l2ZSBtb3JlIGV4cGxpY2l0IGd1aWRhbmNlIHRvIGltcGxlbWVu dG9ycy4KICAgVGhlIGFpbSBpcyB0byBjb21wbGV0ZSB0aGUgd29yayBieSB0aGUgZW5kIG9mIERl Y2VtYmVyIDIwMDMuCgpFeHRlbmRlZCBTZWN1cmUgUlRQIFByb2ZpbGUgZm9yIFJUQ1AtYmFzZWQg RmVlZGJhY2sKPGRyYWZ0LWlldGYtYXZ0LXByb2ZpbGUtc2F2cGYtMDAudHh0PgoKICAgSvZyZyBP dHQgb3V0bGluZWQgdGhlIG5ldyBSVFAvU0FWUEYgcHJvZmlsZSwgY29tYmluaW5nIHRoZSBTZWN1 cmUgUlRQCiAgIHByb2ZpbGUgYW5kIHRoZSBSVENQIGZlZWRiYWNrIHByb2ZpbGUuICBUaGUgbWFq b3IgaW1wbGljYXRpb24gb2YgdGhpcwogICBjb21iaW5hdGlvbiBpcyBhIHBvdGVudGlhbCBpbXBh Y3Qgb24gdGhlIHRpbWVsaW5lc3Mgb2YgZmVlZGJhY2sgc2luY2UKICAgU1JUQ1AgYWRkcyBzb21l IDEwLTIwIGJ5dGVzIHBlciBwYWNrZXQgKDEwLTQwJSksIHdoaWNoIGRlY3JlYXNlcyB0aGUKICAg cmVzcG9uc2l2ZW5lc3Mgb2YgdGhlIGZlZWRiYWNrLiBSdWxlcyBhcmUgcHJvdmlkZWQgZm9yIG5l Z290aWF0aW9uIGFuZAogICBpbnRlci13b3JraW5nLCBub3Rpbmcgd2hpY2ggY29tYmluYXRpb25z IG1ha2Ugc2Vuc2UsIGFuZCBlbnN1cmluZyB0aGF0CiAgIHRoZXJlIGFyZSBubyBiaWRkaW5nIGRv d24gYXR0YWNrcy4gVGhlIGNvbWJpbmF0aW9uIG9mIHRoZXNlIHByb2ZpbGVzIGlzCiAgIGdlbmVy YWxseSBzdHJhaWdodC1mb3J3YXJkLCBob3dldmVyLiBSZXZpZXcgZnJvbSB0aGUgd29ya2luZyBn cm91cCBpcwogICBzb2xpY2l0ZWQuIAoKUlRDUCBTdHJlYW1pbmcgRXh0ZW5kZWQgUmVwb3J0cwo8 ZHJhZnQtdHNlbmctYXZ0LXJ0Y3Atc3RyZWFtaW5nLWV4dGVucy0wMC50eHQ+CgogICBBbGFuIFRz ZW5nIGludHJvZHVjZWQgYW4gZXh0ZW5zaW9uIHRvIFJUQ1AgWFIgKFJGQyAzNjExKSB3aGljaCBy ZXBvcnRzCiAgIG1vcmUgZGV0YWlsZWQgc3RhdGlzdGljcyBvbiByZS1idWZmZXJpbmcgYW5kIHBh Y2tldCBjb3JydXB0aW9uLiBUaGlzIGlzCiAgIGludGVuZGVkIHRvIGJlIHVzZWZ1bCBmb3Igc3Ry ZWFtaW5nIG1lZGlhIGFwcGxpY2F0aW9ucy4gCgogICBUaGVyZSBhcmUgc2V2ZXJhbCBrbm93biBp c3N1ZXMgd2l0aCB0aGUgZHJhZnQ6IGV2ZW4gdGhlIGJlc3QgbWVhc3VyZW1lbnQKICAgb2YgY29y cnVwdGlvbiBpcyBvbmx5IGEgYmVzdCBndWVzcyBvZiAiZ29vZCIgdmVyc3VzICJiYWQiIGZyYW1l czsgYW5kCiAgIHNvbWUgZXhpc3RpbmcgYXBwbGljYXRpb24gYXJjaGl0ZWN0dXJlcyBtYXkgbm90 IHN1cHBvcnQgY29sbGVjdGlvbiBvZgogICB0aGUgZGF0YSB0byBiZSByZXBvcnRlZC4gQ29tbWVu dHMgYXJlIHNvbGljaXRlZCBvbiB0aGUgbWFpbGluZyBsaXN0IC0KICAgdGhlIGF1dGhvcnMgYXJl IGNvbGxlY3RpbmcgZmVlZGJhY2sgYW5kIHNvcnRpbmcgb3V0IHRoZSBkZXRhaWxzIG9mIHRoZQog ICBwcm9wb3NhbC4KCiAgIFRob21hcyBaZW5nIGFza2VkIGZvciBjbGFyaWZpY2F0aW9uIG9uIHRo ZSBmcmVxdWVuY3kgb2YgdGhlIHJlcG9ydHMuIElzCiAgIGl0IHN1ZmZpY2llbnQgdG8gcmVwb3J0 IHRoaXMgaW5mb3JtYXRpb24gb25jZSwgYXQgZW5kIG9mIHRoZSBzdHJlYW0sIG9yCiAgIHNob3Vs ZCBpdCBiZSByZXBvcnRlZCBwZXJpb2RpY2FsbHk/IEFsYW4gcmVwbGllZCB0aGF0IGl0IGlzIHZp YWJsZSB0bwogICBzZW5kIHRoZSBkYXRhIG9ubHkgb25jZSwgYnV0IHNlbmRpbmcgcGVyaW9kaWMg dXBkYXRlcyBpbiBjb25qdW5jdGlvbgogICB3aXRoIHBhY2tldCBsb3NzIGRhdGEgd291bGQgYWxz byBiZSBkZXNpcmFibGUuIFdpbGwgdHJ5IHRvIHByb3ZpZGUgbW9yZQogICByZWNvbW1lbmRhdGlv bnMgYW5kIHVzZSBjYXNlcyBpbiBhIGZ1dHVyZSB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4KCiAgIFZp Y3RvciBWYXJzYSBhc2tlZCBpZiB0aGVzZSByZXBvcnRzIHdlcmUgaW50ZW5kZWQgdG8gYmUgdXNl ZCBmb3IKICAgYWRhcHRhdGlvbiBvZiB0aGUgc3RyZWFtaW5nLCBvciBqdXN0IGZvciBvZmZsaW5l IGNvbGxlY3Rpb24/IEFsYW4KICAgcmVwbGllZCB0aGF0IHRoZSBvcmlnaW5hbCBwbGFuIHdhcyB0 byB1c2UgYSBzaW5nbGUgcmVwb3J0LCBidXQgaXQgCiAgIHNlZW1zIHRvIGJlIHVzZWZ1bCBmb3Ig YWRqdXN0aW5nIHRoZSBmZWVkYmFjayBkdXJpbmcgdGhlIHN0cmVhbS4gCiAgIFZpY3RvciBub3Rl ZCB0aGF0IHRoZSBtYWluIGFkdmFudGFnZSBvZiBzZW5kaW5nIHRoZXNlIHJlcG9ydHMgd2l0aGlu CiAgIFJUQ1AgaXMgdGhhdCB0aGV5J3JlIHN5bmNocm9uaXNlZCB3aXRoIHRoZSBtZWRpYSwgdGhp cyBpcyBvbmx5IHVzZWZ1bCAKICAgaWYgdGhlIHNlbmRlciBhZGFwdHMgaW4gcmVhbC10aW1lLiBU byBhbGxvdyB0aGlzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIAogICBpZiB0aGUgZHJhZnQgaW5jbHVk ZWQgYSBkZXNjcmlwdGlvbiBvZiBob3cgYSBzZW5kZXIgY291bGQgdXNlIHRoZQogICBzdGF0aXN0 aWNzIHRvIGFkYXB0LiBDb2xpbiBQZXJraW5zIG5vdGVkIHRoYXQgaGUgd291bGQgcHJlZmVyIHRo ZXNlCiAgIGRyYWZ0cyB0byBkZXNjcmliZSB0aGUgcmVwb3J0aW5nIGV4dGVuc2lvbnMgaW4gYSBu b3JtYXRpdmUgbWFubmVyLCB3aXRoCiAgIHNlcGFyYXRlIGRyYWZ0cyBnaXZpbmcgaW5mb3JtYXRp dmUgZ3VpZGFuY2Ugb24gaG93IHRoZSBkYXRhIGNvdWxkIGJlCiAgIHVzZWQuIAoKICAgTWFnbnVz IFdlc3Rlcmx1bmQgZXhwcmVzc2VkIHNjZXB0aWNpc20gb24gdGhlIHVzZSBvZiB0aGUgZHJhZnQs IHNpbmNlCiAgIG11Y2ggb2YgdGhlIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBmcm9tIG90aGVy IHNvdXJjZXMsIG9yIGNhbiBiZQogICBpbmZlcnJlZC4gTWljaGFlbCBSYW1hbGhvIGFsc28gd29u ZGVyZWQgYWJvdXQgdGhlIGludGVuZGVkIHVzZSBvZiB0aGUKICAgd29yay4gSGUgbm90ZWQgdGhh dCBpdCdzIGltcG9ydGFudCBhbmQgdXNlZnVsIHRvIHNlcGFyYXRlIG5ldHdvcmsgZXZlbnRzCiAg IGZyb20gY2xpZW50IGV2ZW50cywgYW5kIGFncmVlZCB0aGF0IGl0IG1pZ2h0IGJlIGludGVyZXN0 aW5nIHRvIGtub3cgdGhhdAogICBjZXJ0YWluIGNsaWVudCBldmVudHMgb2NjdXJyZWQgYW5kIGlt cGFjdGVkIHRoZSB1c2VyIGV4cGVyaWVuY2UsIGJ1dAogICBjb3VsZG4ndCBzZWUgaG93IHRoZSBk YXRhIHdhcyB1c2VkIC0gZXhjZXB0IGFzIGEgcmVwb3J0aW5nIG1lY2hhbmlzbS4gSWYKICAgdGhl IGRhdGEgaXMgb25seSByZXBvcnRlZCwgYW5kIG5vdCB1c2VkIHRvIGRyaXZlIGFkYXB0YXRpb24s IGFsdGVybmF0aXZlCiAgIHRyYW5zcG9ydCBtZWNoYW5pc21zIG1heSBiZSBtb3JlIGFwcHJvcHJp YXRlLiAKCiAgIEl0IHdhcyBzdWdnZXN0ZWQgdGhhdCB0aGUgd29yayBvZiB0aGUgUk1PTk1JQiB3 b3JraW5nIGdyb3VwIG1heSBiZQogICByZWxldmFudCB0byB0aGlzIHByb2JsZW0uIERldGFpbHMg Y2FuIGJlIGZvdW5kIGF0OgogICBodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvcm1v bm1pYi1jaGFydGVyLmh0bWwgCgpEYXRhZ3JhbSBDb25nZXN0aW9uIENvbnRyb2wgUHJvdG9jb2wg KERDQ1ApCjxkcmFmdC1pZXRmLWRjY3Atc3BlYy0wNS50eHQ+CjxkcmFmdC1pZXRmLWRjY3AtY2Np ZDItMDQudHh0Pgo8ZHJhZnQtaWV0Zi1kY2NwLWNjaWQzLTA0LnR4dD4KPGRyYWZ0LWlldGYtZGNj cC1jY2lkMy10aGluLTAwLnR4dD4JIAoKICAgRWRkaWUgS29obGVyIGdhdmUgYSBzaG9ydCBwcmVz ZW50YXRpb24gb24gdGhlIERhdGFncmFtIENvbmdlc3Rpb24KICAgQ29udHJvbCBQcm90b2NvbC4g RENDUCBpcyB1bmRlciBkZXZlbG9wbWVudCBhcyBhbiBhbHRlcm5hdGl2ZSB0byBVRFAKICAgYW5k IHByb3ZpZGVzIGEgY29ubmVjdGlvbi1vcmllbnRlZCwgY29uZ2VzdGlvbiBjb250cm9sbGVkLCBk YXRhZ3JhbQogICB0cmFuc3BvcnQgc2VydmljZSB3aXRoIHBhcnRpYWwgY2hlY2tzdW1zLCBtb2Jp bGl0eSwgRG9TIHJlc2lzdGFuY2UsIAogICBhbmQgc3VwcG9ydCBmb3IgZXhwbGljaXQgY29uZ2Vz dGlvbiBub3RpZmljYXRpb24gKEVDTikuIFRoZSB0YXJnZXQKICAgYXBwbGljYXRpb25zIGFyZSB0 aG9zZSB3aXRoIGxvbmctbGl2ZWQgZmxvd3MgdGhhdCBwcmVmZXIgdGltZWxpbmVzcwogICB0byBy ZWxpYWJpbGl0eTogc3RyZWFtaW5nIG1lZGlhLCBJbnRlcm5ldCB0ZWxlcGhvbnksIGdhbWVzLCBl dGMuCgogICBEQ0NQIGFsbG93cyBhcHBsaWNhdGlvbnMgdG8gc2VsZWN0IGZyb20gYSByYW5nZSBv ZiBjb25nZXN0aW9uIGNvbnRyb2wKICAgYWxnb3JpdGhtcyAoZS5nLiBUQ1AtbGlrZSwgVEZSQyku IEl0IGFsc28gZGVjb3VwbGVzIHJlbGlhYmlsaXR5IGZyb20KICAgY29uZ2VzdGlvbiBjb250cm9s LCB0byBhdm9pZCB0aGUgdW5jb25kaXRpb25hbCAiYnVmZmVyIGFuZCByZXRyYW5zbWl0IgogICBi ZWhhdmlvdXIgb2YgVENQLCBhbmQgcHJvdmlkZXMgYSByYW5nZSBvZiBkYXRhIGFja25vd2xlZGdl bWVudCBvcHRpb25zCiAgIGluY2x1ZGluZyB0aGUgYWJpbGl0eSB0byBpbmRpY2F0ZSB0aGF0IGRh dGEgd2FzIGRyb3BwZWQgZHVlIHRvIGJ1ZmZlcgogICBvdmVyZmxvdyBpbiB0aGUgYXBwbGljYXRp b24sIHJhdGhlciB0aGFuIGluIHRoZSBuZXR3b3JrLiAKCiAgIFRoZSBwYXJ0aWFsIGNoZWNrc3Vt IHN1cHBvcnQgaW4gRENDUCBjb3VudHMgdGhlIG51bWJlciBvZiAzMiBiaXQgd29yZHMKICAgb2Yg cGF5bG9hZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgY2hlY2tzdW0sIHVwIHRvIGEgdG90YWwgb2Yg NTYgb2N0ZXRzLiAKICAgRWRkaWUgYXNrZWQgaWYgdGhpcyB3YXMgc3VmZmljaWVudCBmb3IgdGhl IGFwcGxpY2F0aW9ucyBwZW9wbGUgdXNlZD8KICAgVGhvbWFzIFplbmcgcmVwbGllZCB0aGF0IHRo aXMgaXMgcHJvYmFibHkgc3VmZmljaWVudCBmb3IgYXVkaW8sIGJ1dAogICBkb3VidGVkIHRoYXQg aXQgd2FzIGVub3VnaCBmb3IgdmlkZW8gYXBwbGljYXRpb25zLiBNYWdudXMgV2VzdGVybHVuZAog ICBub3RlZCB0aGF0IERDQ1AgYWxzbyBoYXMgYW4gb3B0aW9uYWwgcGF5bG9hZCBjaGVja3N1bSBm ZWF0dXJlLCB3aGljaCAKICAgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBtb3JlIGZsZXhpYmxlIGNo ZWNrc3VtcyBhdCB0aGUgZXhwZW5zZSBvZgogICBhZGRpdGlvbmFsIG92ZXJoZWFkLgoKICAgREND UCBwcm92aWRlcyBhbiBvcHRpb25hbCBBQ0sgdmVjdG9yLCB3aGljaCBhbGxvd3MgYXBwbGljYXRp b25zIHRvIHNlbmQKICAgYSBydW4tbGVuZ3RoIGVuY29kZWQgaGlzdG9yeSBvZiBwYWNrZXRzIHJl Y2VpdmVkLiBJdCBhbHNvIGhhcyBhICJkYXRhCiAgIGRyb3BwZWQiIG9wdGlvbiwgd2hpY2ggYWxs b3dzIGEgcmVjZWl2ZXIgdG8gc2lnbmFsIHRoYXQgY2VydGFpbiBwYWNrZXRzCiAgIHdlcmUgZHJv cHBlZCBkdWUgdG8gbm9uLW5ldHdvcmsgcmVhc29ucyAoZS5nLiBjb3JydXB0aW9uLCBpbnN1ZmZp Y2llbnQKICAgcmVjZWl2ZSBidWZmZXIgc3BhY2UpLiBDb2xpbiBQZXJraW5zIG5vdGVkIHRoYXQg dGhpcyBtaWdodCBkdXBsaWNhdGUKICAgc29tZSBvZiB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQg YnkgUlRDUCB3aXRoIHRoZSByZXBvcnRpbmcgZXh0ZW5zaW9ucwogICBkZXNjcmliZWQgZWFybGll ciBpbiB0aGUgc2Vzc2lvbi4KCiAgIEZpbmFsbHksIEVkZGllIG5vdGVkIHRoYXQgdGhlcmUgaGFz IGJlZW4gc29tZSBkaXNjdXNzaW9uIG9uIHRoZSB1c2Ugb2YKICAgRENDUCB3aXRoIFRGUkMgY29u Z2VzdGlvbiBjb250cm9sIGZvciBWb0lQIGFwcGxpY2F0aW9ucyAoYW5kIHNpbWlsYXIpLgogICBJ biBwYXJ0aWN1bGFyLCB0aGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gb2YgcHJvdG9jb2wg Y29tcGxleGl0eSwKICAgd2hpY2ggaGFzIHJlc3VsdGVkIGluIGEgbG93LWNvbXBsZXhpdHkgc3Vi c2V0IG9mIERDQ1AgKCJDQ0lEMy10aGluIikKICAgYmVpbmcgZGVmaW5lZC4gVGhlcmUgaGFzIGFs c28gYmVlbiBkaXNjdXNzaW9uIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wKICAgYmVoYXZpb3Vy LCB3aXRoIHR3byByZWxhdGVkIGlzc3VlcyBiZWluZyByYWlzZWQ6CgogICAgLSBUaGUgcmVxdWly ZW1lbnQgZm9yIHNsb3ctc3RhcnQgaGFzIGJlZW4gbm90ZWQgdG8gYmUgcHJvYmxlbWF0aWMgZm9y CiAgICAgIHNvbWUgYXBwbGljYXRpb25zLiBFZGRpZSBub3RlZCB0aGF0IERDQ1AgYWxsb3dzIDQg cGFja2V0cyBwZXIgUlRUIHRvCiAgICAgIGJlIHNlbnQgZHVyaW5nIHNsb3cgc3RhcnQsIGFsbG93 aW5nIGEgNDBtcyBwYWNrZXRpc2F0aW9uIGludGVydmFsIGZvcgogICAgICBSVFRzIGxlc3MgdGhh biAxNjBtcy4gSGUgc3VnZ2VzdGVkIHRoYXQgdGhpcyB3YXMgc3VmZmljaWVudCBmb3IgYXVkaW8K ICAgICAgYXBwbGljYXRpb25zLCBhbmQgc29saWNpdGVkIGlucHV0LgoKICAgIC0gVGhlcmUgaXMg YWxzbyBhIGNvbmdlc3Rpb24gaXNzdWUgd2l0aCBhcHBsaWNhdGlvbnMgc2xvd2luZyBkb3duCiAg ICAgIGR1cmluZyBpZGxlIHBlcmlvZHMsIGZvciBleGFtcGxlIHNpbGVuY2Ugc3VwcHJlc3Npb24g Zm9yIHZvaWNlLiAKICAgICAgQXBwbGljYXRpb25zIHdoaWNoIHN0b3Agc2VuZGluZyBjYW5ub3Qg anVzdCByZXN0YXJ0IGFmdGVyIGFuIGlkbGUKICAgICAgcGVyaW9kLCB0aGV5IG11c3Qgc2xvdy1z dGFydC4gQXBwbGljYXRpb25zIHdoaWNoIHNlbmQgc29tZSB0cmFmZmljCiAgICAgIGR1cmluZyBp ZGxlIHBlcmlvZHMgd2lsbCBhbGxvdyBEQ0NQIHRvIG1haW50YWluIGNvbmdlc3Rpb24gc3RhdGUs CiAgICAgIGFsbG93aW5nIHRoZW0gdG8gbGFyZ2VseSBhdm9pZCB0aGlzIGlzc3VlIChzaW5jZSBE Q0NQIGdlbmVyYWxseQogICAgICBhbGxvd3MgYW4gYXBwbGljYXRpb24tbGltaXRlZCBmbG93IHRv IGRvdWJsZSBpdHMgcmF0ZSBlYWNoIFJUVCwgdXAgCiAgICAgIHRvIHRoZSBsaW1pdCBpbXBvc2Vk IGJ5IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wpLiBBZ2FpbiwgRWRkaWUgYXNrZWQgCiAgICAgIGlm IHRoaXMgd2FzIGEgZmVhc2libGUgc29sdXRpb24gZm9yIG11bHRpbWVkaWEgYXBwbGljYXRpb25z LgoKICAgTWFnbnVzIFdlc3Rlcmx1bmQgZXhwcmVzc2VkIGNvbmNlcm4gYWJvdXQgdGhlIHNsb3cg c3RhcnQsIHNpbmNlIGF1ZGlvCiAgIHdpdGggMjBtcyBwYWNrZXRzIGlzIGNvbW1vbiwgYW5kIGZv dXIgcGFja2V0cyBwZXIgUlRUIHJlcXVpcmVzIGFuIFJUVAogICB0aGF0IGlzIGRpZmZpY3VsdCB0 byBvYnRhaW4gZm9yIG1hbnkgYXBwbGljYXRpb25zLiBEYXZlIExpbmRiZXJnIGFza2VkCiAgIGlm IHRoZSBmYWN0b3Igb2YgdHdvIGluY3JlYXNlIGluIHJhdGUgYWxsb3dlZCB3aGVuIG1vdmluZyBm cm9tIGFuCiAgIGFwcGxpY2F0aW9uIGxpbWl0ZWQgcmVnaW1lIHRvIGEgY29uZ2VzdGlvbiBjb250 cm9sbGVkIHJlZ2ltZSBpcyBoYXJkCiAgIGNvZGVkPyBBdCBwcmVzZW50IGl0IGlzLCBidXQgdGhl cmUgbWF5IGJlIGEgc21hbGwgYW1vdW50IG9mIGZsZXhpYmlsaXR5LgogICBUaGUgZmFjdG9yIG9m IHR3byBtYXkgYmUgYSBsaW1pdGluZyBmb3IgdmlkZW8sIHNpbmNlIHRoZSBmaXJzdCBmcmFtZQog ICBhZnRlciBhbiBpZGxlIHBlcmlvZCB3aWxsIGJlIGFuIEktZnJhbWUsIHdoaWNoIGlzIHR5cGlj YWxseSBtdWNoIGxhcmdlcgogICB0aGFuIHRoZSBQLWZyYW1lcyB3aGljaCBmb2xsb3cuCgogICBF ZGRpZSBjb250aW51ZWQgaGlzIHByZXNlbnRhdGlvbiwgbm90aW5nIHRoYXQgdGhlIHJhdGUgZG9l cyBub3QgaW5jcmVhc2UKICAgZHVyaW5nIGFuIGFwcGxpY2F0aW9uIGxpbWl0ZWQgcGVyaW9kLiBB biBhcHBsaWNhdGlvbiBjYW4gb25seSBkZXRlcm1pbmUKICAgaWYgdGhlcmUgaXMgY2FwYWNpdHkg dG8gc3VwcG9ydCBhIGhpZ2hlciByYXRlIGJ5IHRyeWluZyB0byBpbmNyZWFzZSBpdHMKICAgcmF0 ZSAocG9zc2libHkgaW5jdXJyaW5nIGxvc3MsIGlmIHRoZSBoaWdoZXIgcmF0ZSBjYW5ub3QgYmUg c3VwcG9ydGVkKS4KICAgRWRkaWUgYWxzbyBub3RlZCB0aGF0IG1hbnkgYXBwbGljYXRpb25zIGhh dmUgZGlzY3JldGUgcmF0ZXMsIHdoaWNoIG1heQogICBub3QgbmVjZXNzYXJpbHkgbWF0Y2ggdGhl IHJlZmVyZW5jZSByYXRlIHN1Z2dlc3RlZCBieSB0aGUgY29uZ2VzdGlvbgogICBjb250cm9sbGVy LiBBZ2FpbiwgaXQgc2VlbXMgYWNjZXB0YWJsZSBmb3IgYW4gYXBwbGljYXRpb24gdG8gc2VuZCBh dCB0aGUKICAgY2xvc2VzdCBkaXNjcmV0ZSByYXRlIGl0IGNhbiBzdXBwb3J0IHRvIHRoZSByZWZl cmVuY2UgcmF0ZSwgcHJvdmlkZWQgdGhpcwogICBpcyB3aXRoaW4gYSBmYWN0b3Igb2YgdHdvIG9m IHRoZSByZWZlcmVuY2UgcmF0ZS4gW0VkZGllJ3Mgc2xpZGUgc3RhdGVkCiAgICJWYXJpYWJsZSBy YXRlIGNvbnNpZGVyZWQgaGFybWZ1bCIgaGVyZSwgZm9sbG93ZWQgYnkgdGhlIGNsYXJpZmljYXRp b24KICAgIk1lYW5pbmc6IENvbnRpbnVvdXNseSB2YXJpYWJsZSByYXRlIHByb2JsZW1hdGljIGZv ciBhcHBzIHdpdGggZGlzY3JldGUKICAgc2VuZGluZyByYXRlcyIgLSB0aGlzIGNhdXNlZCBzb21l IGRpc2N1c3Npb24vY29uZnVzaW9uIGFzIG5vdGVkIGJlbG93XS4KCiAgIEZpbmFsbHksIEVkZGll IG5vdGVkIHRoYXQgaGUnZCByZWNlaXZlZCBmZWVkYmFjayB0aGF0IGFueSByYXRlIGNoYW5nZSBp cwogICBoYXJtZnVsLiAgVGhlcmUgaGFzIGJlZW4gc29tZSBkaXNjdXNzaW9uIG9mIHVzaW5nIERD Q1Agd2l0aCBhcHBsaWNhdGlvbnMKICAgdGhhdCBzZXR0bGUgb24gb25lIHJhdGUgaW5pdGlhbGx5 LCB0aGVuIG5ldmVyIGNoYW5nZS4KCiAgIERhdmUgTGluZGJlcmcgYXNrZWQgd2h5IHZhcmlhYmxl IHJhdGVzIGFyZSBjb25zaWRlcmVkIGhhcm1mdWwsIGFuZCBub3RlZAogICB0aGF0IHNvbWUgd29y ayBvbiBhdWRpby92aWRlbyBjb2RlY3Mgd2FzIGxlYWRpbmcgdG93YXJkcyB0cnVseSB2YXJpYWJs ZQogICByYXRlIGNvZGVjcy4gRWRkaWUgcmVwbGllZCB0aGF0IHRoZXkgd2VyZW4ndCBwbGFubmlu ZyBvbiBjaGFuZ2luZyB0aGUKICAgcHJvdG9jb2wgdG8gcmVxdWlyZSBmaXhlZCByYXRlIGFwcGxp Y2F0aW9ucywganVzdCB0aGF0IHRoZXkgd2FudGVkIHRvCiAgIHN1cHBvcnQgdGhlbSBpZiBwb3Nz aWJsZSwgYW5kIHZhcmlhYmxlIHJhdGUgY29kZWNzIGFyZSBhIGdvb2QgdGhpbmcuIAogICBUaGVy ZSB3YXMgc29tZSBjb25mdXNpb24sIHdpdGggRGF2ZSByZXBlYXRpbmcgaGlzIHF1ZXN0aW9uIGFu ZCBFZGRpZQogICBleHBsYWluaW5nIHRoZSBpc3N1ZXMgd2l0aCBzdXBwb3J0aW5nIGFwcGxpY2F0 aW9ucyB0aGF0IGNhbiBzZW5kIG9ubHkgCiAgIGF0IGRpc2NyZXRlIHJhdGVzLiBNYXJrIEhhbmRs ZXkgYW5kIE1pY2hhZWwgUmFtYWxobyBub3RlZCB0aGF0IERhdmUgYW5kCiAgIEVkZGllIHdlcmUg dGFsa2luZyBwYXN0IGVhY2ggb3RoZXI6IGl0J3Mgbm90IHRoYXQgdGhlIERDQ1AgcGVvcGxlIHRo aW5rCiAgIHRoYXQgdmFyaWFibGUgcmF0ZSBpcyBoYXJtZnVsLCBpdCdzIHRoYXQgdGhlIHBlb3Bs ZSB3aXRoIGRpc2NyZXRlIHJhdGUKICAgY29kZWNzIHRoaW5rIHRoYXQgYmVpbmcgdG9sZCB0byBh ZGFwdCB0byBhcmJpdHJhcnkgdmFyaWFibGUgcmF0ZXMgZHVlIAogICB0byBjb25nZXN0aW9uIGNv bnRyb2wgaXMgaGFybWZ1bC4gTWFyayBleHBsYWluZWQ6IHRoZSBEQ0NQIGNvbmdlc3Rpb24KICAg Y29udHJvbCBzY2hlbWUgaGFzIGEgdmFyaWFibGUgcmF0ZSB3aGljaCBpdCB3b3VsZCBsaWtlIHlv dSB0byBzZW5kIGF0LAogICB0byBtYXRjaCB0aGUgbmV0d29yayBjYXBhY2l0eS4gVGhlIGNvZGVj IGhhcyBhIGRpZmZlcmVudCAodmFyaWFibGUpCiAgIHJhdGUsIHdoaWNoIGl0IHdvdWxkIGxpa2Ug dG8gc2VuZCBhdC4gVGhlcmUgbWF5IGJlIGEgbWlzbWF0Y2ggYmV0d2VlbgogICB0aGUgdHdvIHJh dGVzLCBhbmQgdGhpcyBtaXNtYXRjaCBoYXMgdG8gYmUgYm91bmRlZC4gUHJvdmlkZWQgdGhlCiAg IG1pc21hdGNoIGlzIHdpdGhpbiBhIGZhY3RvciBvZiB0d28sIHRoaW5ncyBhcmUgb2theS4gSWYg dGhlIG1pc21hdGNoCiAgIGdldHMgbGFyZ2VyIHRoYW4gdGhhdCwgdGhlIGNvZGVjIHNlbmRpbmcg cmF0ZSBoYXMgdG8gYmUgYWRqdXN0ZWQgdG8KICAgbWF0Y2ggdGhlIHJhdGUgdGhlIG5ldHdvcmsg aXMgY2FwYWJsZSBvZiBzdXBwb3J0aW5nLgoKICAgTWljaGFlbCBhY2NlcHRlZCB0aGF0LCBidXQg ZXhwbGFpbmVkIHRoZSBwcm9ibGVtIGZyb20gdGhlIHZpZXdwb2ludCBvZiBhCiAgIGNvZGVjIGRl c2lnbmVyOiBoZSBjb3VsZCBoYXZlIGJlZW4gd2FzdGVmdWwsIGFuZCBzZW50IGF0IHRoZSBmdWxs IHJhdGUKICAgYWxsIHRoZSB0aW1lLCBidXQgaGUncyBkZXZlbG9wZWQgY29kZWNzIHdoaWNoIGFy ZSBlZmZpY2llbnQgYW5kIHVzdWFsbHkKICAgc2VuZCBhdCBsb3cgcmF0ZXMuIEhvd2V2ZXIsIGV2 ZXJ5IG9uY2UgaW4gYSB3aGlsZSwgdGhleSBuZWVkIHRvIHNlbmQgYQogICBsYXJnZSBidXJzdCBv ZiBkYXRhLCBkdWUgdG8gYSBzY2VuZSBjaGFuZ2UuIEhlIHdvdWxkIGNsYWltIHRoYXQgaGUgaXMK ICAgYmVpbmcgYSBnb29kIGNpdGl6ZW4sIGJ5IG5vdCBzZW5kaW5nIGFsbCB0aGUgZGF0YSBhbGwg dGhlIHRpbWUsIGJ1dCBoZQogICBpcyBnZXR0aW5nIHBlbmFsaXNlZCBieSB0aGUgY29uZ2VzdGlv biBjb250cm9sIHdoZW4gdGhlIHNjZW5lIGNoYW5nZQogICBoYXBwZW5zLiBUaGlzIGRvZXNuJ3Qg ZmVlbCBjb3JyZWN0LCBldmVuIHRob3VnaCBoZSB1bmRlcnN0YW5kcyB0aGUKICAgcmVhc29uIGJl aGluZCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobS4KCiAgIFJvbmkgRXZlbiBub3Rl ZCB0aGF0IHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgY2FuIG9ubHkgY2hhbmdlIHRoZWlyIHJhdGUK ICAgYnkgY29tcGxldGVseSBzd2l0Y2hpbmcgY29kZWNzLiBUaGVzZSBhcHBsaWNhdGlvbnMgbmVl ZCB0aGUgY29uZ2VzdGlvbgogICBjb250cm9sIHRvIHNpZ25hbCB0aGVtIHRvIGFkYXB0LCBzbyB0 aGV5IGNhbiBwZXJmb3JtIHRoZSBhcHBsaWNhdGlvbgogICBsZXZlbCBzaWduYWxsaW5nIG5lZWRl ZCB0byBjaGFuZ2UgY29kZWMsIHJhdGhlciB0aGFuIHRyeWluZyB0byBkaXJlY3RseQogICBpbmZs dWVuY2UgdGhlIGZsb3cgZHluYW1pY3MuIEVkZGllIG5vdGVkIHRoYXQgRENDUCBpcyBzdXBwb3Nl ZCB0byBnaXZlCiAgIHRoZSBhcHBsaWNhdGlvbiBlbm91Z2gga25vd2xlZGdlIHRvIHN1cHBvcnQg dGhpcy4KCiAgIFRvbSBQaGVsYW4gbm90ZWQgdGhhdCBoZSdzIGJlZW4gd29ya2luZyBpbiB0aGUg RENDUCB3b3JraW5nIGdyb3VwLCB0bwogICB0cnkgdG8gbWF0Y2ggVm9JUCBhcHBsaWNhdGlvbnMg b250byBEQ0NQLiBTb21lIG9mIGhpcyBjb25jbHVzaW9ucyBhcmUKICAgIm91dCBvZiB0aGUgbm9y bSIgZm9yIHdoYXQgcGVvcGxlIHVzdWFsbHkgY29uc2lkZXIgZ29vZCBiZWhhdmlvdXIgaW4gdGhl CiAgIG5ldHdvcms6IGluc3RlYWQgb2YgImlmIHlvdSBoYXZlIG5vdGhpbmcgdG8gc2F5LCBzYXkg bm90aGluZyIsIGl0IG1heSBiZQogICBtb3JlIGFwcHJvcHJpYXRlIHRvIHNheSAidXNlIGl0IG9y IGxvc2UgaXQiIHNpbmNlIGlmIHlvdSBzZW5kIG5vdGhpbmcsCiAgIGFueSBUQ1AgY3Jvc3MtdHJh ZmZpYyB3aWxsIHRha2UgdGhlIHVudXNlZCBjYXBhY2l0eSBhd2F5IGZyb20geW91LiBUaGVyZQog ICBtYXkgbmVlZCB0byBiZSBhIG1pbmRzZXQgY2hhbmdlIG9uIHRoZSBwYXJ0IG9mIG1lZGlhIGFw cGxpY2F0aW9uIGF1dGhvcnMKICAgdG8gZWZmZWN0aXZlbHkgdXNlIERDQ1AuCgogICBEYXZlIExp bmRiZXJnIG5vdGVkIHRoYXQgdGhlIGJ1cnN0LXRvLWF2ZXJhZ2UgcmF0ZSByYXRpbyBmb3Igc29t ZSB2aWRlbwogICBjb2RlY3MgaXMgaGlnaGVyIHRoYW4gMjoxLCBhbmQgdGhhdCB0byBrZWVwIHRo ZSBxdWFsaXR5IHN0ZWFkeSBvbmUgbmVlZHMKICAgdG8gbW9tZW50YXJpbHkgaW5jcmVhc2UgdGhl IGJpdHJhdGUuIElkZWFsbHksIG9uZSBtaWdodCBjb252ZXkgYSBwcm9maWxlCiAgIG9mIHRoZSBi dXJzdC12ZXJzdXMtYXZlcmFnZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGFwcGxpY2F0aW9uLCBz byB0aGF0CiAgIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgc3lzdGVtIGNhbiB0YWtlIHRoYXQgaW50 byBhY2NvdW50LiBFZGRpZSBub3RlZAogICB0aGUgZGlmZmljdWx0aWVzIGluIGRvaW5nIHRoaXMs IHdoaWNoIERhdmUgYWNjZXB0ZWQuIEhvd2V2ZXIsIGl0IGlzCiAgIGNsZWFyIHRoYXQgbWFueSBj b2RlY3MgYXJlIGJ1cnN0eSwgYW5kIGluIG9yZGVyIHRvIGxvd2VyIHRoZSBhdmVyYWdlCiAgIHJh dGUsIHRoZXNlIGJ1cnN0cyBuZWVkIHRvIGJlIHNvbWVob3cgYWNjb21tb2RhdGVkLgoKICAgTWFy ayBub3RlZCB0aGF0IHRoZXJlIGlzIGEgZnVuZGFtZW50YWwgbWlzbWF0Y2ggYmV0d2VlbiB3aGF0 IGNhbiBzYWZlbHkKICAgYmUgZG9uZSB0byBwcm9iZSB0aGUgY2FwYWNpdHkgb2YgdGhlIG5ldHdv cmssIGFuZCB3aGF0IHRoZSBjb2RlY3Mgd2FudAogICB0byBzdXBwb3J0IGJ1cnN0cy4gVGhlIGJv dW5kcyBpbiBEQ0NQIGFyZSBmdW5kYW1lbnRhbCBmb3IgYmVzdCBlZmZvcnQKICAgbmV0d29ya3Ms IGFuZCByZWZsZWN0IHRoZSBsaW1pdHMgb2Ygd2hhdCB0aGUgbmV0d29yayBjYW4gc3VwcG9ydC4g VGhleQogICBhcmUgbm90IHNvbWV0aGluZyB3ZSBoYXZlIGZsZXhpYmlsaXR5IHRvIGNoYW5nZS4K CiAgIERhdmUgbWVudGlvbmVkIHN0YXRpc3RpY2FsIG11bHRpcGxleGluZywgd2hpY2ggYWxsb3dz IG9uZSB0byBnZXQgYnVyc3RzCiAgIHRocm91Z2ggaW4gbWFueSBjYXNlcy4gSGUgYWxzbyBub3Rl ZCB0aGF0IFRDUCBmbG93cyBhcmUgbm90IHR5cGljYWxseQogICBsYXRlbmN5IHNlbnNpdGl2ZSwg c28gdGhlcmUgbWF5IGJlIHNvbWUgb3Bwb3J0dW5pdHkgZm9yIHNvbWUga2luZCBvZgogICB0cmFk ZS1vZmYuIAoKICAgTmVybWVlbiBJc21haWwgYXNrZWQgaWYgYW4gYXBwbGljYXRpb24gc3RvcHMg c2VuZGluZywgYW5kIGR1cmluZyB0aGF0CiAgIHRpbWUgdGhlcmUgd2FzIG5vIGNvbmdlc3Rpb24g aW4gdGhlIG5ldHdvcmssIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8KICAgYWxsb3cgaXQgcmVzdGFy dCBhdCB0aGUgZnVsbCByYXRlPyBUaGVvcmV0aWNhbGx5LCB5ZXMsIGJ1dCBvbmUgY2FuJ3QKICAg ZmlndXJlIG91dCBpZiB0aGVyZSBpcyBjb25nZXN0aW9uIHVudGlsIG9uZSBzdGFydHMgc2VuZGlu Zywgc28gc2xvdwogICBzdGFydCBpcyBuZWVkZWQgdG8gcHJvdmlkZSBlbm91Z2ggZmVlZGJhY2sg dG8gbWFrZSB0aGUgc3lzdGVtIHN0YWJsZS4gCiAgIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUg aXMgaW5zdWZmaWNpZW50IGtub3dsZWRnZSBpbiB0aGUgbmV0d29yayB0bwogICBrbm93IGlmIGEg Y2hhbmdlIG9mIHJhdGUgaXMgYWNjZXB0YWJsZSB3aXRob3V0IHRyeWluZyBpdC4KCiAgIEl0IHdh cyBub3RlZCB0aGF0IHRoZSBNUEVHIGNvbW11bml0eSBzdHVkaWVkIGludG8gdGhpcyBwcm9ibGVt IGFyb3VuZAogICAxOTk4LTIwMDIsIGFuZCBtYXkgaGF2ZSBwcm9kdWNlZCB1c2VmdWwgcmVmZXJl bmNlcy4gCgogICBNYWdudXMgV2VzdGVybHVuZCBub3RlZCB0aGF0IHNvbWUgYXBwbGljYXRpb25z IGNhbiBzbW9vdGggdGhlIGJ1cnN0cywKICAgZGVwZW5kaW5nIG9uIHRoZWlyIGxhdGVuY3kgcmVx dWlyZW1lbnRzLiAgSG93ZXZlciwgaWYgeW91IG5lZWQgbG93CiAgIGxhdGVuY3ksIGl0IG1heSBi ZSBuZWNlc3NhcnkgdG8gcmVkdWNlIHRoZSBxdWFsaXR5IG9mIGludGVyLWZyYW1lcyBhbmQKICAg dXNlIGEgbW9yZSBpbmNyZW1lbnRhbCByZWZyZXNoIHN0cmF0ZWd5LiBUaGlzIHdpbGwgcmVkdWNl IHRoZSBxdWFsaXR5LAogICBidXQgd2lsbCBmaXQgdGhlIGRpY3RhdGVzIG9mIGNvbmdlc3Rpb24g Y29udHJvbCBhbmQgdGhlIG5ldHdvcmsuCgogICBFZGRpZSBub3RlZCB0aGF0LCB0byB0aGUgZXh0 ZW50IHRoYXQgd2UnbGwgaGF2ZSBhIHNvbHV0aW9uLCBpdCB3aWxsCiAgIHJlcXVpcmUgc2VuZGlu ZyBzb21lIGRhdGEgZHVyaW5nIGlkbGUgcGVyaW9kcyB0byBtYWludGFpbiBjb25nZXN0aW9uCiAg IHN0YXRlIGFuZCBrbm93bGVkZ2Ugb2YgdGhlIG5ldHdvcmsuCgogICBMYWRhbiBHaGFyYWkgbm90 ZWQgdGhhdCB0aGUgaXNzdWUgd2FzIGxhcmdlbHkgd2l0aCBsaXZlIGludGVyYWN0aXZlCiAgIGFw cGxpY2F0aW9ucywgcmF0aGVyIHRoYW4gd2l0aCBzdHJlYW1pbmcgYXBwbGljYXRpb25zIHdoaWNo IGNhbiB1c2UKICAgYnVmZmVyaW5nIHRvIHNtb290aCB0aGVpciByYXRlIHRvIG1hdGNoIHRoYXQg b2YgVEZSQy4gU2hlIHN1Z2dlc3RlZAogICB0aGF0IGl0IG1heSBiZSBhcHByb3ByaWF0ZSB0byBj b25zaWRlciBkaWZmZXJlbnQgY29uZ2VzdGlvbiBjb250cm9sCiAgIGZvciB0aGVzZSB0d28gY2xh c3NlcyBvZiBhcHBsaWNhdGlvbiwgcmF0aGVyIHRoYW4gYXNzdW1pbmcgLSBhcyBoYXMKICAgbXVj aCBvZiB0aGUgZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIHNlc3Npb24gLSB0aGF0IGEgc2luZ2xlIGNv bmdlc3Rpb24KICAgY29udHJvbCBhbGdvcml0aG0gY2FuIGJlIHVzZWQgZm9yIGJvdGguIFRoZSBh cHByb3ByaWF0ZSBjb25nZXN0aW9uCiAgIGNvbnRyb2wgZm9yIGxpdmUgYXBwbGljYXRpb25zIG1h eSBiZSBhIHJlc2VhcmNoIHRvcGljLCByYXRoZXIgdGhhbgogICBzb21ldGhpbmcgd2UgY2FuIGVu Z2luZWVyIHRvZGF5LgoKICAgTWFyayBIYW5kbGV5IG5vdGVkIHRoYXQgYW4gYWR2YW50YWdlIG9m IERDQ1AsIGNvbXBhcmVkIHRvIFVEUCwgaXMgdGhhdAogICBpdCBoYXMgc3VwcG9ydCBmb3IgRUNO IGJ1aWx0LWluLiBUaGlzIGFsbG93cyBhcHBsaWNhdGlvbnMgdG8gcmVhY3QgdG8KICAgY29uZ2Vz dGlvbiwgYmVmb3JlIGl0IGJlY29tZXMgc2V2ZXJlIGVub3VnaCB0byBjYXVzZSBwYWNrZXQgbG9z cywgYW5kCiAgIG1heSBiZSBhIHNpZ25pZmljYW50IGJlbmVmaXQgb2YgRENDUC4KCiAgIEVkZGll IGNvbmNsdWRlZCB0aGUgZGlzY3Vzc2lvbiBieSBnaXZpbmcgcG9pbnRlcnMgdG8gdGhlIGRyYWZ0 cy4KClJUUCBIZWFkZXIgQ29tcHJlc3Npb24gb3ZlciBNdWx0aS1Ib3AgUGF0aHMKPGRyYWZ0LWFz aC1lMmUtdm9pcC1oZHItY29tcC1ycW10cy0wMS50eHQ+CgogICBKZXJyeSBBc2ggZGlzY3Vzc2Vk IHRoZSBtb3RpdmF0aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIFZvSVAgaGVhZGVyCiAgIGNvbXBy ZXNzaW9uIG92ZXIgbXVsdGlwbGUtaG9wIHBhdGhzLCBpbiBwYXJ0aWN1bGFyIEVDUlRQIG92ZXIg TVBMUy4KCiAgIFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHdvcmsgaXMgdGhhdCBjYXJyaWVycyBh cmUgcGxhbm5pbmcgdG8gY29udmVyZ2UKICAgdGhlaXIgbmV0d29ya3MgdG8gdXNlIE1QTFMvSVAg d2l0aCBWb0lQIHNlcnZpY2VzLiBXaGVuIHVzaW5nIFJUUCB0aGVyZQogICBpcyBhIGhpZ2ggb3Zl cmhlYWQgZHVlIHRvIHRoZSBSVFAvVURQL0lQIGhlYWRlcnMsIHNvIHRoZXJlIGlzIGEgZGVzaXJl CiAgIHRvIHVzZSBoZWFkZXIgY29tcHJlc3Npb24uIEhvd2V2ZXIsIHRoZSBjb21wcmVzc2lvbiBp cyBjb21wdXRhdGlvbmFsbHkKICAgY29tcGxleCwgYW5kIGl0IGlzIGRlc2lyYWJsZSB0byBmaW5k IGEgbXVsdGktaG9wIHNvbHV0aW9uLCByYXRoZXIgdGhhbgogICB1c2luZyBob3AtYnktaG9wIGhl YWRlciBjb21wcmVzc2lvbi4gIFRoaXMgbWF5IGludm9sdmUgUlRQIGNvbXByZXNzaW9uCiAgIGFj cm9zcyBhIG11bHRpLWhvcCBNUExTIHBhdGgsIG9yIGNvbXByZXNzaW9uIG92ZXIgYSBzZXJpZXMg b2YgSVAgaG9wcy4KICAgSmVycnkgc3VtbWFyaXNlZCB0aGUgcmVxdWlyZW1lbnRzIGFzOgogICAg LSBhbGxvdyBoZWFkZXIgY29tcHJlc3Npb24gb3ZlciBtdWx0aXBsZS1ob3AgcGF0aHMsIHBvc3Np Ymx5IHRocm91Z2ggCiAgICAgIGFuIE1QTFMgbmV0d29yawogICAgLSBhdm9pZCBob3AtYnktaG9w IGNvbXByZXNzaW9uL2RlY29tcHJlc3Npb24gY3ljbGVzCiAgICAtIGNvbXByZXNzIFJUUC9VRFAv SVAgaGVhZGVyIGJ5IGF0IGxlYXN0IDUwJQogICAgLSBhbGxvdyBWb0lQIGhlYWRlciBjb21wcmVz c2lvbiBvdmVyIG11bHRpcGxlLWhvcCBwYXRocwogICAgICB3aXRoIGRlbGF5IG5vdCB0byBleGNl ZWQgNDAwbXMgCiAgICAtIGFsbG93IFZvSVAgaGVhZGVyIGNvbXByZXNzaW9uIG92ZXIgbXVsdGlw bGUtaG9wIHBhdGhzCiAgICAgIHdpdGggZGVsYXkgdmFyaWF0aW9uIG5vdCB0byBleGNlZWQgdG9t cyAKICAgIC0gYWxsb3cgVm9JUCBoZWFkZXIgY29tcHJlc3Npb24gb3ZlciBtdWx0aXBsZS1ob3Ag cGF0aHMKICAgICAgd2l0aCBwYWNrZXQgbG9zcyBub3QgdG8gZXhjZWVkIDAuMDAxIAogICAgLSBz dXBwb3J0IHZhcmlvdXMgdm9pY2UgZW5jb2Rpbmcgc2NoZW1lcwogICAgLSBiZSBzY2FsYWJsZSB1 cCB0byAyMDAwMCBzaW11bHRhbmVvdXMgZmxvd3MKICAgIC0gYmUgY29tcGF0aWJsZSB3aXRoIGV4 aXN0aW5nIHN0YW5kYXJkcyB3aGVyZSBwb3NzaWJsZQoKICAgQ29saW4gUGVya2lucywgTWljaGFl bCBSYW1hbGhvLCBEYXZlIExpbmRiZXJnIGFuZCBDYXJzdGVuIEJvcm1hbm4gYWxsCiAgIHF1ZXN0 aW9uZWQgaWYgdGhlIG51bWVyaWMgcmVxdWlyZW1lbnRzIHdlcmUgYXBwcm9wcmlhdGUsIGFuZCBo b3cgdGhleQogICBkaWZmZXJlZCBmcm9tIHRob3NlIGZvciBWb0lQIHRyYWZmaWMgd2l0aG91dCBo ZWFkZXIgY29tcHJlc3Npb24uIFRoZXJlCiAgIHdhcyBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHRo ZSBkcmFmdCBtYXkgYmUgYmV0dGVyIGlmIGl0IHNwZWNpZmllcyB0aGUKICAgYWRkaXRpb25hbCBy ZXF1aXJlbWVudHMgY2F1c2VkIGJ5IGhlYWRlciBjb21wcmVzc2lvbiwgcmF0aGVyIHRoYW4KICAg Z2VuZXJpYyByZXF1aXJlbWVudHMgdG8gc3VwcG9ydCB2b2ljZS4KCiAgIERhdmUgTGluZGJlcmcg YXNrZWQgaWYgdGhlcmUgYSByZXF1aXJlbWVudCBmb3IgcGFja2V0IGxvc3MgcmVjb3ZlcnksCiAg IHNpbmNlIG9uZSBvZiB0aGUgaXNzdWVzIHdpdGggQ1JUUCBpcyB0aGF0IGEgc2luZ2xlIHBhY2tl dCBsb3NzIGNhbiBjYXVzZQogICBhIHdob2xlIFJUVCBvZiBkYXRhIHRvIGJlIGxvc3QuICBUaGlz IGlzIHNvbWV0aGluZyB0aGF0IGNvbmNlcm5zIHRoZQogICBhdXRob3JzLCBlc3BlY2lhbGx5IGZv ciBtdWx0aXBsZS1ob3AgcGF0aHMsIGJ1dCB0aGV5IGhvcGUgdGhhdCBFQ1JUUAogICB3aWxsIGJl IHN1ZmZpY2llbnRseSByb2J1c3QuIEdlb3JnZSBTd2FsbG93J3MgInNpbXBsZSIgUlRQIGhlYWRl cgogICBjb21wcmVzc2lvbiBwcm9wb3NhbCBhbHNvIGF2b2lkcyB0aGVzZSBwcm9ibGVtcywgYnV0 IENvbGluIFBlcmtpbnMgbm90ZWQKICAgdGhhdCB0aGUgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0 byB3b3JrIG9uIG5ldyBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGF0CiAgIHRoaXMgdGltZS4KCiAg IE1pY2hhZWwgUmFtYWxobyBhc2tlZCBpZiB0aGUgY29tcHJlc3Npb24gd2FzIGRlYWxpbmcgd2l0 aCBhZ2dyZWdhdGUgb3IKICAgc2luZ2xlIGZsb3dzLCBzaW5jZSBpZiBhZ2dyZWdhdGUgZmxvd3Mg YXJlIHVzZWQgdGhlcmUgbWF5IGJlIGRpZmZlcmVudAogICBzb2x1dGlvbnMgZm9yIHJlY292ZXJ5 IGZyb20gZXJyb3JzLiBCb3RoIHNpbmdsZSBhbmQgYWdncmVnYXRlIGZsb3dzIGFyZQogICBjb25z aWRlcmVkLiAKCiAgIE1hZ251cyBXZXN0ZXJsdW5kIG5vdGVkIHRoYXQgcmVxdWlyZW1lbnRzIGZv ciBoZWFkZXIgY29tcHJlc3Npb24gb3ZlcgogICBtdWx0aS1ob3AgTVBMUyBwYXRocyBtYXkgd2Vs bCBiZSBkaWZmZXJlbnQgdGhhbiB0aGUgcmVxdWlyZW1lbnRzIGZvcgogICBoZWFkZXIgY29tcHJl c3Npb24gb3ZlciBtdWx0aS1ob3AgSVAgcGF0aHMuIFRoZSBkcmFmdCBtYXkgYmUgYmV0dGVyCiAg IHdyaXR0ZW4gc2VwYXJhdGluZyB0aGVzZSBvdXQuIAoKICAgSmVycnkgbm90ZWQgdGhhdCB0aGVy ZSBhcmUgcG90ZW50aWFsIHNjYWxhYmlsaXR5IGlzc3VlcyB3aXRoIFJTVlAgYW5kCiAgIGxhYmVs IHByb2Nlc3NpbmcgYW5kIGJpbmRpbmcgYXQgZXZlcnkgTVBMUyBub2RlIG9uIHRoZSBwYXRoLiBJ dCdzIGFsc28gCiAgIG5vdCBjbGVhciBob3cgdG8gc2lnbmFsIHRoZSBjb250ZXh0IHN0YXRlcyB3 aXRoaW4gdGhlIGxhYmVsIGRpc3RyaWJ1dGlvbgogICBwcm90b2NvbCwgYW5kIGV4dGVuc2lvbnMg dG8gTERQIG1heSBiZSBuZWVkZWQuCgogICBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9mIHRo ZSBuZWVkIHRvIHByb2R1Y2UgYSBzdGFuZGFyZCBmb3IgaGVhZGVyCiAgIGNvbXByZXNzaW9uIG9u IG11bHRpLWhvcCBJUCBwYXRocywgc2luY2Ugcm91dGVycyB3aGljaCBhcmUgY29tcHJlc3NpbmcK ICAgb24gYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MgbGlua3MgY2FuIHVuaWxhdGVyYWxseSBkZWNp ZGUgdG8gbWF0Y2ggQ0lEcwogICBhbmQgcGFzcy10aHJvdWdoIGNvbXByZXNzZWQgZmxvd3Mgd2l0 aG91dCBhIGNvbXByZXNzaW9uLWRlY29tcHJlc3Npb24uCgogICBUaGUgY2hhaXJzIG5vdGVkIHRo YXQgdGhlcmUgYXJlIHNpZ25pZmljYW50IGlzc3VlcyB0byBiZSByZXNvbHZlZCB3aXRoCiAgIHRo ZSBkcmFmdCwgYW5kIGRlbGF5ZWQgYWNjZXB0aW5nIGl0IGFzIGFuIEFWVCB3b3JrIGl0ZW0gdW50 aWwgdGhleSBhcmUKICAgdW5kZXJzdG9vZC4gCgpTRFAgcGFyYW1ldGVycyBmb3Igc3VwcG9ydGlu ZyBILjI2MyBhbmQgSC4yNjEgb3B0aW9ucwo8ZHJhZnQtZXZlbi1hdnQtaDI2My1oMjYxLW9wdGlv bnMtMDAudHh0Pgo8ZHJhZnQtbmlzbWFpbC1tbXVzaWMtc2RwLXZpZGVvLTAwLnR4dD4KCiAgIFJv bmkgRXZlbiBkaXNjdXNzZWQgbmV3IFNEUCBwYXJhbWV0ZXJzIHRvIHN1cHBvcnQgdmFyaW91cyBv cHRpb25hbAogICBmZWF0dXJlcyBpbiBILjI2MSBhbmQgSC4yNjMgY29kZWNzLiBGZWF0dXJlcyB0 byBiZSBzaWduYWxsZWQgaW5jbHVkZQogICBmcmFtZSByYXRlIGFuZCByZXNvbHV0aW9uIGRlcGVu ZGVuY3ksIGFuZCBvcHRpb25hbCBmZWF0dXJlcyBkZWZpbmVkIAogICBpbiB2YXJpb3VzIGFubmV4 ZXMgdG8gdGhlIGNvZGVjcy4gVGhlIGF1dGhvcnMgYXJlIGxvb2tpbmcgZm9yIGlucHV0CiAgIG9u IHRoZSBwYXJhbWV0ZXJzIGNob3NlbiwgdG8gc2VlIGlmIGFsbCBoYXZlIGJlZW4gY292ZXJlZC4K CiAgIFRoZSB0d28gZHJhZnRzIHN1Z2dlc3QgZGlmZmVyZW50IGFwcHJvYWNoZXMsIGJ1dCB0aGUg YXV0aG9ycyBoYXZlIGNvbWUKICAgdG8gY29uc2Vuc3VzIG9uIHVzaW5nICJhPWZtdHA6IiByYXRo ZXIgdGhhbiAiYT1ncG1kOiIgdG8gc2lnbmFsIHRoZXNlCiAgIHBhcmFtZXRlcnMuIFBsYW5zIGZv ciB0aGUgZnV0dXJlIGFyZSB0byBjb21iaW5lIHRoZSBpZGVhcyBmcm9tIHRoZSB0d28KICAgZHJh ZnRzLCBhbmQgcmV2aXNlIHRoZSBwYXlsb2FkIGZvcm1hdHMgZm9yIEguMjYxIGFuZCBILjI2MyB0 byBpbmNsdWRlCiAgIHRoZXNlIG5ldyBNSU1FIHBhcmFtZXRlcnMuIEl0IHdhcyBhbHNvIHN1Z2dl c3RlZCB0byBtb3ZlIFJGQyAyMTkwIHRvCiAgIGhpc3RvcmljIGF0IHRoZSBzYW1lIHRpbWUuCgog ICBFcmljIEJ1cmdlciBub3RlZCB0aGF0IHRoZXJlIGFyZSBzZXZlcmFsIHBhcmFtZXRlcnMgd2hp Y2ggYXJlIG5vdCB1c2VkLAogICBlc3BlY2lhbGx5IGluIEguMjYxLiBXaGljaCByZXZpc2luZyB0 aGUgcGF5bG9hZCBmb3JtYXRzLCB3ZSBzaG91bGQKICAgcmVtb3ZlIHRoZXNlLiBGbGVtbWluZyBh c2tlZCBhYm91dCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgc2luY2UgY2FyZQogICBtdXN0IGJl IHRha2VuIHdoZW4gYWRkaW5nIG5ldyBNSU1FIHBhcmFtZXRlcnMgdGhhdCB3b24ndCBiZSB1bmRl cnN0b29kCiAgIGJ5IG9sZCBpbXBsZW1lbnRhdGlvbnMuCgogICBWaWN0b3IgVmFyc2EgYXNrZWQg aG93IHRoZXNlIG5ldyBwYXJhbWV0ZXJzIHJlbGF0ZSB0byB0aGUgY29uY2VwdHMgb2YKICAgcHJv ZmlsZXMgYW5kIGxldmVscz8gVGhlc2UgYXJlIGFkZGl0aW9uYWwgcGFyYW1ldGVycywgd2hpY2gg c2lnbmFsIAogICBjb21iaW5hdGlvbnMgb2YgcGFyYW1ldGVycyB3aGljaCBjYW5ub3QgYmUgcmVw cmVzZW50ZWQgYnkgdGhlIHByb2ZpbGUKICAgYW5kIGxldmVsIGluZGljYXRpb24uCgogICBJdCB3 YXMgYWNjZXB0ZWQgdG8gb3BlbiB0aGUgSC4yNjEgYW5kIEguMjYzIHBheWxvYWQgZm9ybWF0cyBm b3IgcmV2aXNpb24KICAgYXQgdGhpcyB0aW1lLCB3aXRoIHRoZSBhaW0gb2YgcHJvZHVjaW5nIGRy YWZ0IHN0YW5kYXJkIFJGQ3MuCgpSZXF1aXJlbWVudHMgZm9yIHRyYW5zcG9ydCBvZiB2aWRlbyBj b250cm9sIGNvbW1hbmRzCjxkcmFmdC1iYXNzby1hdnQtdmlkZW9jb25yZXEtMDAudHh0PgoKICAg QW5kcmVhIEJhc3NvIG91dGxpbmVkIHNvbWUgaW5pdGlhbCByZXF1aXJlbWVudHMgd29yayB3aGlj aCBpcyBvbmdvaW5nCiAgIHJlbGF0aW5nIHRvIHRoZSB0cmFuc3BvcnQgb2YgdmlkZW8gY29udHJv bCBjb21tYW5kcy4gVGhpcyBpcyBleHBsb3JhdG9yeQogICB3b3JrLCBhbmQgaXQgaGFzIG5vdCB5 ZXQgYmVlbiBkZWNpZGVkIHdoaWNoIHBhcnRzIG9mIGl0IHdpbGwgY29udGludWUgaW4KICAgQVZU LCB3aGljaCBpbiBNTVVTSUMsIGFuZCB3aGljaCBtYXliZSBlbHNld2hlcmUuCgogICBBbmRyZWEg b3V0bGluZWQgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LCBsZWFkaW5nIHRv IHRoZQogICBuZWVkIGZvciByZWZlcmVuY2UgZnJhbWUgcmVxdWVzdHMsIHNwYXRpby10ZW1wb3Jh bCB0cmFkZW9mZiByZXF1ZXN0cywKICAgZnJlZXplIGZyYW1lIHJlcXVlc3RzLCBtYXgtcmF0ZSBy ZXF1ZXN0cyBhbmQgYWN0dWFsIHJhdGUgbm90aWZpY2F0aW9uLiAKICAgSGUgYWxzbyBkZXNjcmli ZWQgdGhlIHdpZGUgcmFuZ2Ugb2YgcmVxdWlyZW1lbnRzIGZvciB0cmFuc3BvcnQgb2YgdGhlCiAg IGRpZmZlcmVudCBjb21tYW5kcy4KCiAgIE5leHQgc3RlcHMgYXJlIHRvIHRyaW0gdGhlIGNvbW1h bmQgbGlzdCwgdG8gdGlnaHRlbiB1cCB0aGUgbGlzdCBvZgogICB0cmFuc3BvcnQgcmVxdWlyZW1l bnRzLCBhbmQgdG8gZGVjaWRlIGEgaG9tZSBmb3IgdGhlIHZhcmlvdXMgcGFydHMgb2YKICAgdGhl IHdvcmsuIERhdmUgTGluZGJlcmcgbm90ZWQgdGhhdCBILjI0MSBzdXBwb3J0cyBtYW55IG9mIHRo ZXNlCiAgIGNvbW1hbmRzLCBhbmQgc3VnZ2VzdGVkIHRoYXQgdGhlIHdvcmsgYmUgaGFybW9uaXNl ZCBiZXR3ZWVuIHRoZSBJVFUgYW5kCiAgIElFVEYuIEVyaWMgQnVyZ2VyIHN1Z2dlc3RlZCB0aGF0 IHdlIGhhdmUgdG8gYmUgY2FyZWZ1bCBub3QgdG8gYmxpbmRseQogICBkdXBsaWNhdGUgSC4yNDEs IHNpbmNlIG1hbnkgb2YgdGhlIGZlYXR1cmVzIGNhbiBiZSBzaWduYWxsZWQgaW4gb3RoZXIKICAg d2F5cywgb3IgYXJlIG5vdCBtZWFuaW5nZnVsIGZvciBTSVAtYmFzZWQgc3lzdGVtcy4gTW9zdCBp bXBvcnRhbnQgdG8KICAgaGFybW9uaXNlIHRoZSB3b3JrLCBpcnJlc3BlY3RpdmUgb2YgaG93IG9y IHdoZXJlIHRoZSB3b3JrIGlzIGRvbmUuCgogICBUaGUgcmVxdWlyZW1lbnRzIGNhcHR1cmUgYW5k IGluaXRpYWwgZGlzY3Vzc2lvbiBmb3IgdGhlIGNvZGVjIGNvbW1hbmRzCiAgIHdpbGwgYmUgZG9u ZSBpbiBBVlQuICBJdCBpcyBub3QgeWV0IGRlY2lkZWQgd2hlcmUgdGhlIGFjdHVhbCB3b3JrIHdp bGwgCiAgIGJlIGRvbmUsIHRoYXQgd2lsbCBkZXBlbmQgb24gdGhlIG91dGNvbWUgb2YgdGhlIHJl cXVpcmVtZW50cyBkaXNjdXNzaW9uLgoKUHJvcG9zZWQgYWRkaXRpb25zIHRvIFJUUCBNSUIKPGRy YWZ0LWNsYXJrLWF2dC1ydHBtaWJ2Mi0wMC50eHQ+CgogICBUaGUgZmluYWwgcHJlc2VudGF0aW9u IG9mIHRoZSBtZWV0aW5nIHdhcyBmcm9tIEFsYW4gQ2xhcmsgb24gcHJvcG9zZWQKICAgYWRkaXRp b25zIHRvIHRoZSBSVFAgTUlCLiBUaGUgcmF0aW9uYWxlIGZvciB0aGVzZSBhZGRpdGlvbnMgaXMg dG8gYWRkCiAgIHN1cHBvcnQgZm9yIHRoZSBuZXcgUlRDUCBYUiBhbmQgVm9JUCBtZXRyaWNzLiAg VGhlIGRyYWZ0IGRvZXMgdGhpcyBieQogICBhZGRpbmcgYW4gcnRjcFhyVm9pcFRhYmxlIHRvIHRo ZSBleGlzdGluZyBNSUIsIHRvIHN1cHBvcnQgYm90aCBiYXNpYwogICBjYWxsIGluZm9ybWF0aW9u IGFuZCBSVENQIFhSIG1ldHJpY3MuCgogICBTZXZlcmFsIHBlb3BsZSBleHByZXNzZWQgY29uY2Vy biBhYm91dCBhZGRpbmcgbmV3IGZlYXR1cmVzIHRvIFJGQyAyOTU5LAogICBzdWdnZXN0aW5nIGlu c3RlYWQgdGhhdCB0aGUgYWRkaXRpb25zIGFyZSB3cml0dGVuIGFzIGEgc2VwYXJhdGUgZHJhZnQs CiAgIHBlcmhhcHMgdW5kZXIgYSBzZXBhcmF0ZSBNSUIgcm9vdC4gTWFnbnVzIFdlc3Rlcmx1bmQg bm90ZWQgdGhhdCB0aGUgUlRQCiAgIE1JQiBhbHNvIG5lZWRzIHRvIGJlIHVwZGF0ZWQgZm9yIHRo ZSBjaGFuZ2VzIGJldHdlZW4gUkZDIDE4ODkgYW5kIFJGQwogICAzNTUwLCBhbmQgdGhpcyBtYXkg YmUgYW4gYXBwcm9wcmlhdGUgdGltZSB0byBtYWtlIHRoZXNlIGNoYW5nZXMuIAoKCQkJCSAgIC0g KyAtCgo= --Multipart=_Thu__18_Dec_2003_17_57_59_+0000_yT05VQVFJoR/qsPT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 18 13:07:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06288 for ; Thu, 18 Dec 2003 13:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2YQ-0007o0-3H for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 13:07:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBII7Ht0029941 for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 13:07:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2Y9-0007gp-Q8; Thu, 18 Dec 2003 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWYul-0004Y8-56 for avt@optimus.ietf.org; Wed, 17 Dec 2003 05:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02290 for ; Wed, 17 Dec 2003 05:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWYuc-0005l3-00 for avt@ietf.org; Wed, 17 Dec 2003 05:28:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWYuC-0005ku-00 for avt@ietf.org; Wed, 17 Dec 2003 05:27:49 -0500 Received: from drum.kom.e-technik.tu-darmstadt.de ([130.83.139.190] helo=mailserver.KOM.e-technik.tu-darmstadt.de) by ietf-mx with esmtp (Exim 4.12) id 1AWYuC-0005kQ-00 for avt@ietf.org; Wed, 17 Dec 2003 05:27:48 -0500 Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id LAA03382; Wed, 17 Dec 2003 11:26:51 +0100 (MET) Message-ID: <3FE02F68.6000904@kom.tu-darmstadt.de> Date: Wed, 17 Dec 2003 11:26:48 +0100 From: Ivica Rimac User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: avt@ietf.org Subject: Re: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG References: In-Reply-To: X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Rod, thank you for your answer. See my comments inline: Rod.Walsh@nokia.com wrote: > Hi Ivica > > Great to hear you're interested in this field. > > >>Has there been any follow-up discussion? > > > Not much so far. I think the related people are hammering away at other problems at the moment, so this one is queued (at least for me). > > >>Now since Magnus does not think there is a straightforward >>solution, I >>am wondering where I might be wrong? > > > I think Magnus was refering to FEC (for RTP). The references where not ALC FEC references. I (also) am not a FEC expert, but if you have an idea of what your application reliability and network loss characteristics might be, it should be easier to assess what kind of FEC scheme would suit. Fortunately ALC's designed to allow new and old schemes to 'plug-in' staightforwardly. You just need the FEC spec that meets your needs. > > As I interpretted it, Magnus highlighted 3 issues needing solution: > 1. How to achieve synchronisation > 2. How to reference downloaded binary objects > 3. Session description (declaration) of FLUTE sessions (e.g. SDP extension) > > You have addressed (1) with "providing additional timing attributes to the FDT"... > > >>Looking into the FLUTE draft, it seems to already provide the >>necessary >>means for reliable transfer of time-lined static media: providing >>additional timing attributes to the FDT. With the latter and the RTP >>timing information, the application can synchronize both >>media objects. > > > Which makes sense. Essentially I can see three simple solutions for (1): > 1. describe the timing information in the FDT as an extension (your suggestion) > 2. describe the timing information in the FDT in a seperate object (e.g. in a SMIL file - Magnus's suggestion) > 3. use the expires field already in the FDT as the implicit timing field (I not convinced whether this is a good idea) > > If you've got a spec of any of these I'd be happy to distrubte and review it. Thought of SMIL-like attributes: If "Content-Duration" is not provided, the object is displayed until the end of the session or until the beginning of a new FLUTE object with the same TOI. > > Irrespecive of how you solve (1), you need to solve (2) - how to reference "downloaded binary objects" (aka "files"). FLUTE already gives you URIs to identify files so the simple way is to use these. If you want to be globaly unique, I guess you'll choose URLs (rather than URNs) although there's the consideration of whether HTTP://... is going to be resolved to an HTTP GET by your application if it's not savvy with what's being multicast. Could just use relative URLs, or even define a new FLUTE URL. For me everything is fine as is (it's easy to reference a URI and take care that you understand it's uniqueness in whatever domain). If anyone sees some significant problems with this, please highlight them - especially whether we need a FLUTE URL (since that needs an Internet-draft). The idea was to use relative URLs, conforming to your thoughts, since all the objects are locally cached in the end-device. Thus, there is no need for changes. The rest is up to the application. > > Finally, to solve (3) you need to define a FLUTE Session Description Syntax/extension. It's a fair bet that SDP will be with us for some time ahead so an SDP extension seems to be the minimal Internet-draft for general Interent usage. This is on my todo list, unless someone else does it first. Agree, this seems to be an open issue. > > BTW, one of the open source FLUTE implementations is available here: > http://atm.tut.fi/mad/ > > Cheers, Rod -- Best regards, +--- Ivica Rimac -----------------------------------------------+ | KOM - Multimedia Communications | | Department of Electrical Engineering & Information Technology | | Darmstadt University of Technology | | email: Ivica.Rimac@kom.tu-darmstadt.de | | Merckstr. 25 tel.: +49-6151-16-6112 (Fax -6152) | | 64283 Darmstadt http://www.kom.e-technik.tu-darmstadt.de | +---------------------------------------------------------------+ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Dec 18 15:29:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14867 for ; Thu, 18 Dec 2003 15:29:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4le-00063L-My for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 15:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIKT6iU023228 for avt-archive@odin.ietf.org; Thu, 18 Dec 2003 15:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4lZ-00061n-1r; Thu, 18 Dec 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4lH-00061R-Vm for avt@optimus.ietf.org; Thu, 18 Dec 2003 15:28:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14718; Thu, 18 Dec 2003 15:28:41 -0500 (EST) Message-Id: <200312182028.PAA14718@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Dec 2003 15:28:41 -0500 Subject: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --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 : Registration of the text/red MIME Sub-Type Author(s) : P. Jones Filename : draft-ietf-avt-text-red-00.txt Pages : 5 Date : 2003-12-18 This document defines the text/red MIME sub-type. The actual RTP packetization for this MIME type is specified in RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-text-red-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-text-red-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: <2003-12-18142335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-text-red-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-text-red-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142335.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Dec 19 04:36:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00274 for ; Fri, 19 Dec 2003 04:36:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXH3M-0000Ar-M2 for avt-archive@odin.ietf.org; Fri, 19 Dec 2003 04:36:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ9aCEl000626 for avt-archive@odin.ietf.org; Fri, 19 Dec 2003 04:36:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXH3C-00009K-UZ; Fri, 19 Dec 2003 04:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXH2w-00008k-3D for avt@optimus.ietf.org; Fri, 19 Dec 2003 04:35:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00261 for ; Fri, 19 Dec 2003 04:35:43 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXH2t-0002xL-00 for avt@ietf.org; Fri, 19 Dec 2003 04:35:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXH2s-0002xE-00 for avt@ietf.org; Fri, 19 Dec 2003 04:35:42 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AXH2s-0002xB-00 for avt@ietf.org; Fri, 19 Dec 2003 04:35:42 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 490656A16F for ; Fri, 19 Dec 2003 10:35:42 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 4EAF619C58 for ; Fri, 19 Dec 2003 10:35:41 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 2CEA719C80 for ; Fri, 19 Dec 2003 10:35:13 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id KAA15826 for ; Fri, 19 Dec 2003 10:35:11 +0100 (MET) Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt To: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 19 Dec 2003 10:31:54 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 19/12/2003 10:36:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Would not it be useful to explain what "red" stands for ? Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Dec 20 07:03:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06508 for ; Sat, 20 Dec 2003 07:03:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXfpD-0001HV-1n for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 07:03:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKC3Ftg004921 for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 07:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXfoz-0001Gj-7v; Sat, 20 Dec 2003 07:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6PK-0003rz-AB for avt@optimus.ietf.org; Thu, 18 Dec 2003 17:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24562 for ; Thu, 18 Dec 2003 17:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6PI-0005gz-00 for avt@ietf.org; Thu, 18 Dec 2003 17:14:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6PH-0005gs-00 for avt@ietf.org; Thu, 18 Dec 2003 17:14:07 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AX6PG-0005fi-00 for avt@ietf.org; Thu, 18 Dec 2003 17:14:06 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id hBIMDalp086452 for ; Thu, 18 Dec 2003 14:13:36 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Dec 2003 14:13:35 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17E5B@misty.packetvideo.com> From: Thomas Zeng To: "'avt@ietf.org'" Date: Thu, 18 Dec 2003 14:13:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [AVT] Comments on draft-ietf-avt-rtp-h264-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear Steve W. and Other Authors: I have some questions and comments on draft-ietf-avt-rtp-h264-03.txt : * Section 5.4: Packetization Modes There is this statement: The non-interleaved mode is targeted for conversational systems that may not comply with ITU-T Recommendation H.241. I tried to download H.241 spec but since I don't have ITU subscription I am not able to find it. It would be helpful to add a brief explanation (if feasible) on why this " may not comply with ITU-T Recommendation H.241." Reading a later section, I believe that reason is that H.241 does not allow grouping of NAL units in RTP packets. Is that the only reason? * Section 5.7.2: MTAPs There is a statement, quoted below: "This memo does not specify how the NAL units within an MTAP are ordered, but, in most cases, NAL unit decoding order SHOULD be used." There is a case where, when partial checksum is available, from either UDP lite or DCCP, that the best way to order NAL units within a MTAP is by the reverse order of NRI, since NRI indicates the relative importance of a NAL unit, and that NRI=0 means that the NAL unit is not used as reference to any other NAL unit. Hence it makes sense to apply partial checksum on the first group of NAL units, upto but not including the NAL units with NRIs equal to 0. Adding such a use case would show one more advantage of current MTAP structures. * section 8.1. MIME Registration: It seems that the MIME parameters init-buf-time, interleaving-depth and max-don-diff are somehow related, when at least two of them are explicitely singalled. For example, if init-buf-time is too small compares to interleaving-depth (although interleaving-depth is specified not in time units, but in terms of number of NAL units), video images can not be displayed after init-buf-time is reached. So I am wondering: wouldn't it make sense to specify interleaving-depth in terms of time units, rather than number of NAL units? In that case, max-don-diff would provide supplemental information about the interleaving depth in terms of number of NAL objects. Thanks, -Thomas _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Dec 20 17:03:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21190 for ; Sat, 20 Dec 2003 17:03:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXpBm-0002SF-Oi for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 17:03:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKM3Awh009434 for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 17:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXpBc-0002Rd-Lj; Sat, 20 Dec 2003 17:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXpAe-0002QL-6r for avt@optimus.ietf.org; Sat, 20 Dec 2003 17:02:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21138 for ; Sat, 20 Dec 2003 17:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXpAb-0000FR-00 for avt@ietf.org; Sat, 20 Dec 2003 17:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXpAb-0000FK-00 for avt@ietf.org; Sat, 20 Dec 2003 17:01:57 -0500 Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AXpAa-0000FH-00 for avt@ietf.org; Sat, 20 Dec 2003 17:01:56 -0500 Received: from vit (h161n2fls31o265.telia.com [217.208.189.161]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id hBKM1Uen030917; Sat, 20 Dec 2003 23:01:31 +0100 (CET) From: "Gunnar Hellstrom" To: , Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt Date: Sat, 20 Dec 2003 23:01:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Philippe, Question: Would not it be useful to explain what "red" stands for ? Answer: In the introduction, it is for example stated "usage of RFC 2198 and this MIME type for the transport of redundant text data". Is that not clear enough? ---------------------------------------------------------------------------- --------------------------------------------------------------- Do we need to modify the Abstract as well to read: "Abstract This document defines the text/red MIME sub-type for transmission of text with redundancy in order to improve reliability. The actual RTP packetization for this MIME type is specified in RFC 2198." ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of philippe.gentric@philips.com Sent: Friday, December 19, 2003 10:32 AM To: avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt Would not it be useful to explain what "red" stands for ? Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Dec 20 18:08:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22782 for ; Sat, 20 Dec 2003 18:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXqCf-0004Qk-HX for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 18:08:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKN89bR017024 for avt-archive@odin.ietf.org; Sat, 20 Dec 2003 18:08:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXqCX-0004PV-2c; Sat, 20 Dec 2003 18:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXqBb-00048m-Pd for avt@optimus.ietf.org; Sat, 20 Dec 2003 18:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22618 for ; Sat, 20 Dec 2003 18:06:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXqBZ-0001SD-00 for avt@ietf.org; Sat, 20 Dec 2003 18:07:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXqBY-0001S6-00 for avt@ietf.org; Sat, 20 Dec 2003 18:07:00 -0500 Received: from mail.cs.tu-berlin.de ([130.149.17.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AXqBX-0001S3-00 for avt@ietf.org; Sat, 20 Dec 2003 18:06:59 -0500 Received: from hobel.cs.tu-berlin.de (stewe@jeder.cs.tu-berlin.de [130.149.17.59]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id AAA01274; Sun, 21 Dec 2003 00:05:53 +0100 (MET) Message-Id: <6.0.0.22.2.20031220203139.030ff3d8@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 20 Dec 2003 23:55:16 +0100 To: Thomas Zeng From: Stephan Wenger Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-h264-03.txt Cc: "'avt@ietf.org'" In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17E5B@misty.packetvideo .com> References: <72263E8E8622D611975C0002B32C19D805A17E5B@misty.packetvideo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Thomas, with respect to your H.241 related comments: When referencing (informatively) standards of non-IETF bodies, it is always very difficult to find a good balance between being sufficient explanatory and making sure that one is, in the long term, correct. H.241 includes many different sections, only one of which is concerned with the RTP paylaod for H.264. The current language of H.241 specifies (in addition to other, unrelated subjects) an RTP payload format for H.264 which is a small subset of our draft. As for major features, fragmentation, aggregation, the MIME/SDP stuff and a few other aspects are not in H.241. The main reason for being vague is that we may well add, say, aggregation to the next version of H.241. Or we may, once our draft has become an RFC, go ahead and retire the annex where the payload spec is specified in, and add a reference to our then RFC, maybe with some additional language that disables some mechanisms of the RFC. In the ITU-T, we can do this as long as the changes are technically upward compatible, and it is common practice to do so. In the IETF, on the other hand, the payload spec will stay as an RFC unchanged, until a new RFC with a future version of the payload spec is issues (and that spec may or may not be upward/downward compatible). For this reason, I'm a bit reluctant to add more explanatory language to our draft. Instead, I would even consider removing the H.241 discussions altogether. However, doing this is not such a great idea either, because there will be implemetors with previous H.241 implementation experience, which would likely find it beneficial to get some hint that they do not have to start from scratch when implementing our draft. More comments inline. At 11:13 PM 12/18/2003, Thomas Zeng wrote: >* Section 5.7.2: MTAPs >There is a statement, quoted below: > > "This memo does not specify how the NAL units within an MTAP >are ordered, but, in most cases, NAL unit > decoding order SHOULD be used." > > There is a case where, when partial checksum is available, from >either UDP lite or DCCP, that the best way to order NAL units within a MTAP >is by the reverse order of NRI, since NRI indicates the relative importance >of a NAL unit, and that NRI=0 means that the NAL unit is not used as >reference to any other NAL unit. Hence it makes sense to apply partial >checksum on the first group of NAL units, upto but not including the NAL >units with NRIs equal to 0. Adding such a use case would show one more >advantage of current MTAP structures. That is why the language calls for a "SHOULD" and not a "MUST". Doing what you suggests has benefits for the error resilience (when using the protocols you mentioned over bit error prone links) but has a negative impact on the latency. I believe, most implementors of standards like this one should have a rough idea about the tradeoffs, and I don't think we need to spell it out in more detail. Especially not when the only usage examples are not widely deployed (to say the least :-) protocols like UDP lite, or DCCP (or the modified FEC stuff). >* section 8.1. MIME Registration: > It seems that the MIME parameters init-buf-time, >interleaving-depth and max-don-diff are somehow related, when at least two >of them are explicitely singalled. For example, if init-buf-time is too >small compares to interleaving-depth (although interleaving-depth is >specified not in time units, but in terms of number of NAL units), video >images can not be displayed after init-buf-time is reached. > > So I am wondering: wouldn't it make sense to specify >interleaving-depth in terms of time units, rather than number of NAL units? >In that case, max-don-diff would provide supplemental information about the >interleaving depth in terms of number of NAL objects. Using time for specifying interleaving-depth would make sense if most/all of the NAL units of a stream were of roughly the same size. However, this is not the case. NAL units can be very small (i.e. for parameter sets, SEI messages, or Picture Delimiters) or large (slices). A single picture can consist of dozens of NAL units -- this is not a theoretical option, but a very real scenario. Interleaving of such NAL units (even within a picture) makes sense as it changes the error concealment properties. Hence the interleaving is defined on NAL units, and it would not make sense to use time instead. Thanks for your comments, and best regards, Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 21 08:28:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23531 for ; Sun, 21 Dec 2003 08:28:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3ct-00070U-If for avt-archive@odin.ietf.org; Sun, 21 Dec 2003 08:28:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBLDS78P026911 for avt-archive@odin.ietf.org; Sun, 21 Dec 2003 08:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3cn-0006zW-I2; Sun, 21 Dec 2003 08:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3cN-0006zL-Nz for avt@optimus.ietf.org; Sun, 21 Dec 2003 08:27:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23528 for ; Sun, 21 Dec 2003 08:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AY3cM-0005di-00 for avt@ietf.org; Sun, 21 Dec 2003 08:27:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AY3cL-0005db-00 for avt@ietf.org; Sun, 21 Dec 2003 08:27:34 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AY3cL-0005cZ-00 for avt@ietf.org; Sun, 21 Dec 2003 08:27:33 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63060 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AY3bp-0008Cv-00; Sun, 21 Dec 2003 13:27:01 +0000 Date: Sun, 21 Dec 2003 13:27:12 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Subject: Re: [AVT] WG last call: iLBC payload format and codec Message-Id: <20031221132712.4efdb83e.csp@csperkins.org> In-Reply-To: <20031207141839.46a14542.csp@csperkins.org> References: <20031207141839.46a14542.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The last call period for the iLBC payload format and codec has concluded. Since there were no objections, we will now request that these drafts are published. Colin --> Colin Perkins writes: > This is to announce a working group last call on the RTP Payload Format > and codec for iLBC speech: > > draft-ietf-avt-rtp-ilbc-04.txt > draft-ietf-avt-ilbc-codec-04.txt > > Please send any final comments on these drafts to the mailing list by > 19th December 2003. If no substantive comments are received by that > time, we will ask the IESG to publish the codec as an Experimental RFC > and the RTP payload format as a Proposed Standard RFC. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 21 08:30:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23603 for ; Sun, 21 Dec 2003 08:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3en-00078p-VN for avt-archive@odin.ietf.org; Sun, 21 Dec 2003 08:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBLDU5ln027398 for avt-archive@odin.ietf.org; Sun, 21 Dec 2003 08:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3em-00077U-Cj; Sun, 21 Dec 2003 08:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AY3dp-00076U-7P for avt@optimus.ietf.org; Sun, 21 Dec 2003 08:29:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23554 for ; Sun, 21 Dec 2003 08:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AY3dn-0005eu-00 for avt@ietf.org; Sun, 21 Dec 2003 08:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AY3dn-0005en-00 for avt@ietf.org; Sun, 21 Dec 2003 08:29:03 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AY3dm-0005eD-00 for avt@ietf.org; Sun, 21 Dec 2003 08:29:03 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63061 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AY3dI-0008Dd-00; Sun, 21 Dec 2003 13:28:32 +0000 Date: Sun, 21 Dec 2003 13:28:42 +0000 From: Colin Perkins To: avt@ietf.org Cc: magnus.westerlund@ericsson.com Subject: Re: [AVT] WG last call: draft-ietf-avt-rtp-clearmode-04.txt Message-Id: <20031221132842.7ad3aa2d.csp@csperkins.org> In-Reply-To: <20031207142702.41573038.csp@csperkins.org> References: <20031207142702.41573038.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The last call period for the RTP payload format for 64kbps transparant calls has now concluded. Since there were no objections, we will request that the draft be published as a Proposed Standard RFC. Colin --> Colin Perkins writes: > This is to announce a working group last call on the RTP payload format > for 64 kbit/s transparent calls (draft-ietf-avt-rtp-clearmode-04.txt). > Please send any final comments on this draft to the mailing list by 19th > December 2003. If no substantive comments are received by that time, we > will ask the IESG to publish this draft as a Proposed Standard RFC. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 22 03:30:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07423 for ; Mon, 22 Dec 2003 03:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYLS7-00081E-5h for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 03:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBM8UBCf030824 for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 03:30:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYLRy-000809-3r; Mon, 22 Dec 2003 03:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYLRZ-0007zJ-Se for avt@optimus.ietf.org; Mon, 22 Dec 2003 03:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07384 for ; Mon, 22 Dec 2003 03:29:35 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYLRX-0002Ke-00 for avt@ietf.org; Mon, 22 Dec 2003 03:29:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYLRW-0002KX-00 for avt@ietf.org; Mon, 22 Dec 2003 03:29:35 -0500 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AYLRW-0002KH-00 for avt@ietf.org; Mon, 22 Dec 2003 03:29:34 -0500 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 7BBAF6A690; Mon, 22 Dec 2003 09:29:30 +0100 (MET) Received: from smtpscan-nl2.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 316AE19C45; Mon, 22 Dec 2003 09:29:30 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl2.philips.com (Postfix) with ESMTP id 504E619C5D; Mon, 22 Dec 2003 09:29:22 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id JAA17659; Mon, 22 Dec 2003 09:29:21 +0100 (MET) Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt To: "Gunnar Hellstrom" Cc: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 22 Dec 2003 09:26:06 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 22/12/2003 09:31:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >Philippe, >Question: Would not it be useful to explain what "red" stands for ? > >Answer: In the introduction, it is for example stated "usage of RFC 2198 and >this MIME type for > the transport of redundant text data". > >Is that not clear enough? >---------------------------------------------------------------------------- >--------------------------------------------------------------- >Do we need to modify the Abstract as well to read: > >"Abstract > > This document defines the text/red MIME sub-type for transmission of text >with redundancy in order to improve reliability. The actual RTP > packetization for this MIME type is specified in RFC 2198." > actually since one may take "red" as an acronym (hey it is capitalized in the defintion!) why not simply process it as such: "This document defines the text/red (red=redundant) MIME sub-type." ;-) regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com To: Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt "Gunnar Hellstrom" Sent by: avt-admin@ietf.org 20/12/2003 23:01 Philippe, Question: Would not it be useful to explain what "red" stands for ? Answer: In the introduction, it is for example stated "usage of RFC 2198 and this MIME type for the transport of redundant text data". Is that not clear enough? ---------------------------------------------------------------------------- --------------------------------------------------------------- Do we need to modify the Abstract as well to read: "Abstract This document defines the text/red MIME sub-type for transmission of text with redundancy in order to improve reliability. The actual RTP packetization for this MIME type is specified in RFC 2198." ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of philippe.gentric@philips.com Sent: Friday, December 19, 2003 10:32 AM To: avt@ietf.org Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-text-red-00.txt Would not it be useful to explain what "red" stands for ? Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 22 12:10:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25574 for ; Mon, 22 Dec 2003 12:10:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTZL-0001En-UF for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 12:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMHABMj004709 for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 12:10:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTZC-0001DM-GT; Mon, 22 Dec 2003 12:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTYy-0001Cm-FV for avt@optimus.ietf.org; Mon, 22 Dec 2003 12:09:48 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25564 for ; Mon, 22 Dec 2003 12:09:45 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AYTY0-0006TJ-UQ; Mon, 22 Dec 2003 12:08:48 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 22 Dec 2003 12:08:48 -0500 Subject: [AVT] Last Call: 'Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Audio/Video Transport WG to consider the following documents: - 'Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) ' as a Proposed Standard - 'Extended RTP Profile for RTCP-based Feedback - Results of the Timing Rule Simulations ' as an Informational RFC 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 2004-01-09. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-07.txt http://www.ietf.org/internet-drafts/draft-burmeister-avt-rtcp-feedback-sim- 02.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Dec 22 12:23:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25894 for ; Mon, 22 Dec 2003 12:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTln-0001aR-1Q for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 12:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMHN2w4006062 for avt-archive@odin.ietf.org; Mon, 22 Dec 2003 12:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTll-0001Yf-Q4; Mon, 22 Dec 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYTlY-0001YM-Op for avt@optimus.ietf.org; Mon, 22 Dec 2003 12:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25854 for ; Mon, 22 Dec 2003 12:22:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYTlX-0002tb-00 for avt@ietf.org; Mon, 22 Dec 2003 12:22:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYTlV-0002tU-00 for avt@ietf.org; Mon, 22 Dec 2003 12:22:46 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AYTlV-0002tP-00 for avt@ietf.org; Mon, 22 Dec 2003 12:22:45 -0500 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMHMB419737; Mon, 22 Dec 2003 12:22:11 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZMGMPYJ5; Mon, 22 Dec 2003 12:22:11 -0500 Received: from nortelnetworks.com (acart1de.ca.nortel.com [47.129.129.90]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XLPWN1C3; Mon, 22 Dec 2003 12:22:12 -0500 Message-ID: <3FE72843.5000801@nortelnetworks.com> Date: Mon, 22 Dec 2003 12:22:11 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: "'avt@ietf.org'" Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-h264-03.txt References: <72263E8E8622D611975C0002B32C19D805A17E5B@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17E5B@misty.packetvideo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just as a matter of general information, the ITU-T has changed their procedures in recent years to make it easier for other standards groups to cooperate with them. Any individual can order up to three of their documents per year without charge. Select the appropriate option at http://ecs.itu.ch/cgi-bin/ebookshop. Thomas Zeng wrote: ... > > I tried to download H.241 spec but since I don't have ITU > subscription I am not able to find it. It would be helpful to add a brief > explanation (if feasible) on why this " may not comply with ITU-T > Recommendation H.241." > ...> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Dec 27 12:57:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18091 for ; Sat, 27 Dec 2003 12:57:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIgY-0000YH-Q2 for avt-archive@odin.ietf.org; Sat, 27 Dec 2003 12:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBRHvASB002073 for avt-archive@odin.ietf.org; Sat, 27 Dec 2003 12:57:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIgO-0000Wu-RX; Sat, 27 Dec 2003 12:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIgN-0000Wj-Df for avt@optimus.ietf.org; Sat, 27 Dec 2003 12:56:59 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18081 for ; Sat, 27 Dec 2003 12:56:55 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AaIfj-0004zT-6t; Sat, 27 Dec 2003 12:56:19 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Sat, 27 Dec 2003 12:56:19 -0500 Subject: [AVT] Last Call: 'RTP payload format for a 64 kbit/s transparent call' to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Audio/Video Transport WG to consider the following document: - 'RTP payload format for a 64 kbit/s transparent call ' as a Proposed Standard 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 2004-01-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Dec 27 12:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18122 for ; Sat, 27 Dec 2003 12:59:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIiM-0000d4-CS for avt-archive@odin.ietf.org; Sat, 27 Dec 2003 12:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBRHx2JO002391 for avt-archive@odin.ietf.org; Sat, 27 Dec 2003 12:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIiL-0000c2-PG; Sat, 27 Dec 2003 12:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaIiJ-0000br-F3 for avt@optimus.ietf.org; Sat, 27 Dec 2003 12:58:59 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18116 for ; Sat, 27 Dec 2003 12:58:55 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AaIhP-00054B-De; Sat, 27 Dec 2003 12:58:03 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Sat, 27 Dec 2003 12:58:03 -0500 Subject: [AVT] Last Call: 'RTP Payload Format for iLBC Speech' to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Audio/Video Transport WG to consider the following document: - 'RTP Payload Format for iLBC Speech ' as a Proposed Standard The document - 'Internet Low Bit Rate Codec' specifies the codec for which this is the payload format, and will be considered as an Experimental. 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 2004-01-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-04.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Dec 28 15:41:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18155 for ; Sun, 28 Dec 2003 15:41:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aahj1-00060o-PF for avt-archive@odin.ietf.org; Sun, 28 Dec 2003 15:41:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBSKfN7a023062 for avt-archive@odin.ietf.org; Sun, 28 Dec 2003 15:41:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aahig-0005z6-UP; Sun, 28 Dec 2003 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYsFh-0004mR-T5 for avt@optimus.ietf.org; Tue, 23 Dec 2003 14:31:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03170 for ; Tue, 23 Dec 2003 14:31:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYsFf-0005xP-00 for avt@ietf.org; Tue, 23 Dec 2003 14:31:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYsCr-0005QY-00 for avt@ietf.org; Tue, 23 Dec 2003 14:28:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AYs9y-0004rO-00 for avt@ietf.org; Tue, 23 Dec 2003 14:25:38 -0500 Received: from QHNGUYEN-W2K1.cisco.com (dhcp-171-71-97-99.cisco.com [171.71.97.99]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBNJP6C7004061; Tue, 23 Dec 2003 11:25:06 -0800 (PST) Message-Id: <4.3.2.7.2.20031223111502.020af660@mira-sjcm-1.cisco.com> X-Sender: qhnguyen@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Dec 2003 11:25:05 -0800 To: avt@ietf.org From: Quy Nguyen Cc: qhnguyen@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.60 Subject: [AVT] Ask Open source info for RTP/RTSP/MPEG2 Client Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear Experts, I would like to have/find a free/open source code implementing the RTP/RTSP Client and working with MPEG-2 PES. I found one but only work with MJPEG. Best regards MERRY CHRISTMAS and HAPPY NEW YEAR Quy Nguyen email :qhnguyen@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt