From mallman@icir.org Wed Jan 11 05:52:56 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7F21F86E5; Wed, 11 Jan 2012 05:52:56 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "Cc" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC6QtZZ+aBk7; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1E21F86E1; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q0BDqopm018330; Wed, 11 Jan 2012 05:52:51 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5052515DBEA0; Wed, 11 Jan 2012 08:52:50 -0500 (EST) To: ietf@ietf.org From: Mark Allman Subject: tsv-dir review of draft-ietf-mile-rfc4046-bis-05 Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA X-URL-0: http://www.icir.org/mallman-files/Document62102.doc X-URL-1: http://www.icir.org/mallman-files/Document97827.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37937-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Jan 2012 08:52:50 -0500 Sender: mallman@icir.org Message-Id: <20120111135250.5052515DBEA0@lawyers.icir.org> Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:52:56 -0000 ----------ma37937-1 Content-Type: text/plain Content-Disposition: inline I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is basically ready for publication, but has nits that should be fixed before publication. In reading this document I flagged two issues. Neither of them huge, but I'd think perhaps they should be addressed before publication. (1) The language is a little wonky in my opinion. The document is laying out a 'transport protocol'. But, while this protocol does transport bits of data this is absolutely not a layer 4 protocol and so I was initially a bit confused. This draft lays out an application layer protocol (a slightly tweaked version of HTTP to be exact). It would seem useful to me to clean this up. (2) I wondered why the document said hosts MUST use port 4590. Certainly having a well know port is useful in many cases. But, I don't see why some consortium couldn't decide they were going to use port 4545 or whatever. Likewise, when setting up a callback it'd seem straightforward to give a port number, as well. I am not sure it is the biggest deal in the world, but a solution that leveraged late binding would strikes me as more flexible and hence better. allman ----------ma37937-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8NlDEACgkQWyrrWs4yIs7S3ACfSB5LMu62jT5ifhdpLmX7lt0o jV0AoJkq8Wdd97cNuYqvOI89sPGEWMVQ =iqhf -----END PGP SIGNATURE----- ----------ma37937-1-- From mallman@icir.org Thu Jan 12 09:35:00 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB21721F8501; Thu, 12 Jan 2012 09:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb+okXLP1REH; Thu, 12 Jan 2012 09:35:00 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3A52421F84B3; Thu, 12 Jan 2012 09:34:59 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q0CHYrPB006197; Thu, 12 Jan 2012 09:34:56 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 651B9160A581; Thu, 12 Jan 2012 12:34:53 -0500 (EST) To: Brian Trammell From: Mark Allman Subject: Re: [mile] tsv-dir review of draft-ietf-mile-rfc4046-bis-05 In-Reply-To: <9D040FF6-6F6F-48EF-B7DA-CA73318C859F@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Going to California X-URL-0: http://www.icir.org/mallman-files/Document58554.doc X-URL-1: http://www.icir.org/mallman-files/Document76114.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma6587-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 12 Jan 2012 12:34:53 -0500 Sender: mallman@icir.org Message-Id: <20120112173453.651B9160A581@lawyers.icir.org> Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:35:00 -0000 ----------ma6587-1 Content-Type: text/plain Content-Disposition: inline > > (2) I wondered why the document said hosts MUST use port 4590. > > Certainly having a well know port is useful in many cases. But, I > > don't see why some consortium couldn't decide they were going to use > > port 4545 or whatever. Likewise, when setting up a callback it'd > > seem straightforward to give a port number, as well. > > > > I am not sure it is the biggest deal in the world, but a solution > > that leveraged late binding would strikes me as more flexible and > > hence better. > > Agreed that the restriction is too strict. However, I think it's > simpler at this point to declare the use of ports other than the > well-known port to be configurable out of band, as other RID system > and consortium configuration issues are out of scope for this document > as well. That is what I was thinking. I.e., I was not suggesting some way to discover the port or whatnot. Just not mandating that all communication happen on the assigned port (which of course you could never do regardless of what the RFC says). Sounds like a good set of changes to me. allman ----------ma6587-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8PGbwACgkQWyrrWs4yIs4PHgCgl/wzh1Thsxo4G+MMge7SZIAQ yu4AmQF+oUUdVps3HrvuoKSOcNbv1R7u =fLdq -----END PGP SIGNATURE----- ----------ma6587-1-- From trammell@tik.ee.ethz.ch Thu Jan 12 08:22:31 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546EF21F859A; Thu, 12 Jan 2012 08:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhZcZn4RlPbt; Thu, 12 Jan 2012 08:22:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E055821F8539; Thu, 12 Jan 2012 08:22:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3E872D9315; Thu, 12 Jan 2012 17:22:28 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KawT6YBn2O6c; Thu, 12 Jan 2012 17:22:28 +0100 (MET) Received: from [10.216.2.109] (unknown [38.67.0.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0C4E0D9310; Thu, 12 Jan 2012 17:22:26 +0100 (MET) Subject: Re: [mile] tsv-dir review of draft-ietf-mile-rfc4046-bis-05 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <20120111135250.5052515DBEA0@lawyers.icir.org> Date: Thu, 12 Jan 2012 10:22:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D040FF6-6F6F-48EF-B7DA-CA73318C859F@tik.ee.ethz.ch> References: <20120111135250.5052515DBEA0@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 13 Jan 2012 09:10:46 -0800 Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 16:22:31 -0000 Hi, Mark, Thanks for the review; I've addressed these issues in an -06 revision to = be submitted after last call is complete. Comments thereon, inline... On Jan 11, 2012, at 7:52 AM, Mark Allman wrote: >=20 > I've reviewed this document as part of the transport area = directorate's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address > any issues raised. The authors should consider this review together = with > any other last-call comments they receive. Please always CC > tsv-dir@ietf.org if you reply to or forward this review.=20 >=20 > This draft is basically ready for publication, but has nits that = should > be fixed before publication.=20 >=20 > In reading this document I flagged two issues. Neither of them huge, > but I'd think perhaps they should be addressed before publication. >=20 > (1) The language is a little wonky in my opinion. The document is > laying out a 'transport protocol'. But, while this protocol does > transport bits of data this is absolutely not a layer 4 protocol = and > so I was initially a bit confused. This draft lays out an > application layer protocol (a slightly tweaked version of HTTP to = be > exact). It would seem useful to me to clean this up. Agreed completely, and done. > (2) I wondered why the document said hosts MUST use port 4590. > Certainly having a well know port is useful in many cases. But, I > don't see why some consortium couldn't decide they were going to = use > port 4545 or whatever. Likewise, when setting up a callback it'd > seem straightforward to give a port number, as well. >=20 > I am not sure it is the biggest deal in the world, but a solution > that leveraged late binding would strikes me as more flexible and > hence better. Agreed that the restriction is too strict. However, I think it's simpler = at this point to declare the use of ports other than the well-known port = to be configurable out of band, as other RID system and consortium = configuration issues are out of scope for this document as well. So, the = clarifying text would be as follows: Every RID system participating in a consortium SHOULD listen for HTTP/TLS connections on the assigned = port. RID systems MAY be configurable to listen on ports other than the well-known port; this configuration is out of band and out of scope = for this specification. and When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; = there is no mechanism in RID for redirected callback. This callback SHOULD = use TCP port 4590 unless configured out of band to use a different port. Many thanks, best regards, Brian (as 6046-bis author)= From jsaldana@unizar.es Tue Jan 17 10:24:30 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87C11E8088 for ; Tue, 17 Jan 2012 10:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0HvXaNUkZwm for ; Tue, 17 Jan 2012 10:24:29 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89911E8072 for ; Tue, 17 Jan 2012 10:24:28 -0800 (PST) Received: from unizar.es (mesa.unizar.es [155.210.1.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q0HIOLrg011249 for ; Tue, 17 Jan 2012 19:24:21 +0100 Received: from wsip-70-165-225-204.lv.lv.cox.net (wsip-70-165-225-204.lv.lv.cox.net [70.165.225.204]) by webmail.unizar.es (Horde MIME library) with HTTP; Tue, 17 Jan 2012 19:24:20 +0100 Message-ID: <20120117192420.6ozvxwvhwcs8sww4@webmail.unizar.es> Date: Tue, 17 Jan 2012 19:24:20 +0100 From: jsaldana@unizar.es To: tsv-area@ietf.org Subject: Proposal for updating TCRTP (RFC 4170)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:24:31 -0000 Hello all. My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new in this area. I would like to share with Transport Area a proposal, in case it could be considered interesting. The main idea is to update TCRTP. This is a "Best current practice" RFC =20 (http://datatracker.ietf.org/doc/rfc4170/) which was developed in =20 Audio/Video Transport working group in 2005-11. It "describes a method =20 to improve the bandwidth utilization of RTP streams over network paths =20 that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path." (from the introduction of RFC4170). I have first sent this proposal to avtcore working group, but Magnus =20 Westerlund has answered this: ________ Hi, As you are proposing to go towards a more generic scheme I don't think this proposal really belongs in the WG, most likely not this area even. I think this is a topic that primarily are related to Intarea and Transport. Intarea as the owner of the tunneling work in IETF and Transport as the actual aggregation and header compression is primarily transport topics. A question I would have is where this type of mechanism would make sense. Where do you have scarce bandwidth capacity and are willing to pay the downsides of the ingress egress complexities and the impact on the traffic in regards to additional delay. Cheers Magnus ___________________ So I would like to know if the work can better fit this area. The scheme of TCRTP is: RTP/UDP/IP | | ECRTP (compressing layer). Compresses RTP/UDP/IP headers | | PPPMux (multiplexing layer). Includes a number of compressed packets into a bigger one | | L2TP (tunneling layer). Permits its use end-to-end | | IP However, there exist many real-time flows that do not use RTP: - Online "First Person Shooter" (FPS) games use UDP datagrams, and they are one of the most "real-time" applications nowadays. Some examples: Counter Strike, Halo, Quake, etc.[1]. - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): They use TCP, but can be considered "real-time", since the actions of the players have to be transmitted very quickly to the server. It should be taken into account that player vs player fights are one of the possible activities of the game. Some examples: World of Warcraft (more than 10 million subscribers) [2]. - TCP is also getting used for media delivery. For many reasons, such as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. - Another interesting scenario is satellite communication links. Multiplexing small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex small TCP packets into one packet - this could be especially interesting for compressing TCP ACKs. In our recent research activities, we have adapted TCRTP scheme for its use when the traffic is not RTP. The idea is to substitute ECRTP by other compression scheme which can be used for UDP or TCP headers. In 2006, the IETF formed the Robust Header Compression (ROHC) working group which created specifications for header compression over links for RTP, UDP and TCP. These specifications were extended to compress headers over other networks. For most RTP flows, ROHC is more bandwidth efficient than ECRTP, at the cost of implementation complexity. It has a special care of context synchronization, defining some states at the compressor and decompressor. Once the effort for designing ROHC has been conducted, it is worth including it in the compressing and multiplexing standard. In a recent paper in Nov. issue of IEEE Communications Magazine, it was shown that 30% of bandwidth saving can be achieved for 8 FPS different games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent study, which is still under review, has estimated 45% bandwidth saving for World of Warcraft. After talking to other researchers, including some of the authors of RFC4170, the possible scheme of the proposal could be this one: G.711.0 payload compression TCP UDP UDP/RTP | | | | | \ | / | \ | / | nothing or ROHC or ECRTP | | \ / \ / multiplexing layer (other or PPPMUX) | | tunneling layer (other or GRE or L2TP) | | IP It should be more "open" than TCRTP. I mean, it could be "orthogonal" to different protocols: different header compression algorithms could be used, depending on the application and the scenario; also different multiplexing and tunneling protocols could be included. Finally, we have also included the G.711.0 "branch": it could be interesting to convert G.711 to G.711.0 (a lossless encoding of G.711) and back, using a similar tunneling mechanism. In a similar way to TCRTP, the G.711 to G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP signaling with the endpoints, since G.711 has a fixed RTP payload number. Regarding the scenarios, we have considered some of them: - A provider of a real-time service (e.g. game or voip) can have an =20 infrastructure with a number of proxies that can group traffic from different users and send =20 it to the server. - An Internet caf=E9, where a number (sometimes big) of players share =20 the same access link. Bandwidth is scarce in that scenario. - A satellite link, where the bandwidth and the pps have to be saved. We have not written a draft. This is only the first idea, so we look forward to hearing the opinion of the Area. Thank you very much, and sorry for writing such a long message, Jose Saldana University of Zaragoza ______________ [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnumber= =3D5562482 [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for World of Warcraft," ICC '07. IEEE International Conference on Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnumber= =3D4288671 [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role for Wireless Entertainment Centers at Home," IEEE Transactions on Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnumber= =3D5681060 [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. Viruete and L. Casadesus, "First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, Consumer Communications and Networking Series, vol. 49, no. 11, pp. 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnumber= =3D6069696 From wes@mti-systems.com Thu Jan 19 18:38:33 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE54F21F8557 for ; Thu, 19 Jan 2012 18:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU3I60Dkc27z for ; Thu, 19 Jan 2012 18:38:33 -0800 (PST) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61521F854E for ; Thu, 19 Jan 2012 18:38:33 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q0K2cWbA004596 for ; Thu, 19 Jan 2012 21:38:32 -0500 Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.101.251] ([174.130.101.251:36291] helo=[192.168.1.102]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 2A/3A-12338-8A3D81F4; Thu, 19 Jan 2012 21:38:32 -0500 Message-ID: <4F18D3A9.7010901@mti-systems.com> Date: Thu, 19 Jan 2012 21:38:33 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tsv-area@ietf.org Subject: Re: IETF-83/Paris TSVAREA planning References: <4EF40C5C.4070807@mti-systems.com> In-Reply-To: <4EF40C5C.4070807@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 02:38:33 -0000 On 12/23/2011 12:06 AM, Wesley Eddy wrote: > Hello, as we plan for a potential TSVAREA meeting in Paris at > IETF-83 (http://www.ietf.org/meeting/83/index.html), please > let David and myself know of any topics you would like to > discuss in a TSVAREA meeting, so that we can plan for the time > appropriately. Just a reminder; the meeting scheduling cut-off is approaching (on 1/30), so please get your requests in if there are topics of area-wide interest that you'd like to discuss in-person. -- Wes Eddy MTI Systems From carlberg@g11.org.uk Tue Jan 24 12:53:37 2012 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE27621F84B6 for ; Tue, 24 Jan 2012 12:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flKzji6IyGJx for ; Tue, 24 Jan 2012 12:53:36 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 038C021F84B5 for ; Tue, 24 Jan 2012 12:53:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=DpJcJu1NErGiRBBusqKFon23LQWOpYN96UpzZ2fQ/GjvqbrLdQ2Ybk0oWRZqO4Y9H4DhnlcJySx4TB939dyGtCjULPssMrrsuF/Bticv1oNlOkgGxe9ulDTyxdaEJ9b0; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49914 helo=miro-2.private) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1RpnMw-0006yI-1R; Tue, 24 Jan 2012 20:53:30 +0000 Subject: Re: Proposal for updating TCRTP (RFC 4170)) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: <20120117192420.6ozvxwvhwcs8sww4@webmail.unizar.es> Date: Tue, 24 Jan 2012 15:53:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <74A4BF09-2D41-4A33-A0E0-A9CB4C9FA05A@g11.org.uk> References: <20120117192420.6ozvxwvhwcs8sww4@webmail.unizar.es> To: jsaldana@unizar.es X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:53:37 -0000 I would agree with Magnus that the TSV Area would be a good place to = start with a more detailed discussion of the topic, although the = Transport Area Directors would be able to provide a more definitive = opinion. The one word of caution I would bring up is that the IETF = tends to have a difficult time finding a home for architecture work that = spans layers of the stack. I don't know if this aspect is a requirement = or a one potential use case scenario of your proposed work, but its = something to keep in mind if you end up giving a presentation at the TSV = area meeting. -ken On Jan 17, 2012, at 1:24 PM, jsaldana@unizar.es wrote: > Hello all. >=20 > My name is Jose Saldana, from the University of Zaragoza, in Spain. I = am > new in this area. >=20 > I would like to share with Transport Area a proposal, in case it > could be considered interesting. The main idea is to update TCRTP. = This > is a "Best current practice" RFC = (http://datatracker.ietf.org/doc/rfc4170/) which was developed in = Audio/Video Transport working group in 2005-11. It "describes a method = to improve the bandwidth utilization of RTP streams over network paths = that carry multiple Real-time Transport Protocol (RTP) streams in > parallel between two endpoints, as in voice trunking. The method > combines standard protocols that provide compression, multiplexing, = and > tunneling over a network path for the purpose of reducing the = bandwidth > used when multiple RTP streams are carried over that path." (from the > introduction of RFC4170). >=20 > I have first sent this proposal to avtcore working group, but Magnus = Westerlund has answered this: >=20 > ________ >=20 > Hi, >=20 > As you are proposing to go towards a more generic scheme I don't think > this proposal really belongs in the WG, most likely not this area = even. >=20 > I think this is a topic that primarily are related to Intarea and > Transport. Intarea as the owner of the tunneling work in IETF and > Transport as the actual aggregation and header compression is = primarily > transport topics. >=20 > A question I would have is where this type of mechanism would make > sense. Where do you have scarce bandwidth capacity and are willing to > pay the downsides of the ingress egress complexities and the impact on > the traffic in regards to additional delay. >=20 > Cheers >=20 > Magnus > ___________________ >=20 > So I would like to know if the work can better fit this area. >=20 > The scheme of TCRTP is: >=20 > RTP/UDP/IP > | > | > ECRTP (compressing layer). Compresses RTP/UDP/IP headers > | > | > PPPMux (multiplexing layer). Includes a number of compressed = packets > into a bigger one > | > | > L2TP (tunneling layer). Permits its use end-to-end > | > | > IP >=20 > However, there exist many real-time flows that do not use RTP: >=20 > - Online "First Person Shooter" (FPS) games use UDP datagrams, and = they > are one of the most "real-time" applications nowadays. Some examples: > Counter Strike, Halo, Quake, etc.[1]. >=20 > - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): > They use TCP, but can be considered "real-time", since the actions of > the players have to be transmitted very quickly to the server. It = should > be taken into account that player vs player fights are one of the > possible activities of the game. Some examples: World of Warcraft = (more > than 10 million subscribers) [2]. >=20 > - TCP is also getting used for media delivery. For many reasons, such = as > avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is > substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. >=20 > - Another interesting scenario is satellite communication links. > Multiplexing small packets into one packet for transmission would > improve the efficiency. Satellite links would also find it useful to > multiplex small TCP packets into one packet - this could be especially > interesting for compressing TCP ACKs. >=20 >=20 > In our recent research activities, we have adapted TCRTP scheme for = its > use when the traffic is not RTP. The idea is to substitute ECRTP by > other compression scheme which can be used for UDP or TCP headers. In > 2006, the IETF formed the Robust Header Compression (ROHC) working = group > which created specifications for header compression over links for = RTP, > UDP and TCP. These specifications were extended to compress headers > over other networks. For most RTP flows, ROHC is more bandwidth > efficient than ECRTP, at the cost of implementation complexity. It has = a > special care of context synchronization, defining some states at the > compressor and decompressor. Once the effort for designing ROHC has = been > conducted, it is worth including it in the compressing and = multiplexing > standard. >=20 >=20 > In a recent paper in Nov. issue of IEEE Communications Magazine, it = was > shown that 30% of bandwidth saving can be achieved for 8 FPS different > games using IPv4. If IPv6 is used, savings can be up to 54% [4]. = Another > recent study, which is still under review, has estimated 45% bandwidth > saving for World of Warcraft. >=20 >=20 > After talking to other researchers, including some of the authors of > RFC4170, the possible scheme of the proposal could be this one: >=20 >=20 > G.711.0 payload compression TCP UDP UDP/RTP > | | | | > | \ | / > | \ | / > | nothing or ROHC or ECRTP > | | > \ / > \ / > multiplexing layer (other or PPPMUX) > | > | > tunneling layer (other or GRE or L2TP) > | > | > IP >=20 > It should be more "open" than TCRTP. I mean, it could be "orthogonal" = to > different protocols: different header compression algorithms could be > used, depending on the application and the scenario; also different > multiplexing and tunneling protocols could be included. Finally, we = have > also included the G.711.0 "branch": it could be interesting to convert > G.711 to G.711.0 (a lossless encoding of G.711) and back, using a > similar tunneling mechanism. In a similar way to TCRTP, the G.711 to > G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP > signaling with the endpoints, since G.711 has a fixed RTP payload = number. >=20 > Regarding the scenarios, we have considered some of them: >=20 > - A provider of a real-time service (e.g. game or voip) can have an = infrastructure with a > number of proxies that can group traffic from different users and send = it to the server. >=20 > - An Internet caf=E9, where a number (sometimes big) of players share = the same access link. > Bandwidth is scarce in that scenario. >=20 > - A satellite link, where the bandwidth and the pps have to be saved. >=20 >=20 > We have not written a draft. This is only the first idea, so we look > forward to hearing the opinion of the Area. >=20 >=20 > Thank you very much, and sorry for writing such a long message, >=20 > Jose Saldana >=20 > University of Zaragoza >=20 > ______________ >=20 > [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of = First-Person > Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , > vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnumb= er=3D5562482 > = >=20 > [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling = for > World of Warcraft," ICC '07. IEEE International Conference on > Communications, pp.1612-1617, 24-28, Jun. 2007. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnumb= er=3D4288671 > = >=20 > [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role > for Wireless Entertainment Centers at Home," IEEE Transactions on > Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnumb= er=3D5681060 > = >=20 > [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. > Viruete and L. Casadesus, "First Person Shooters: Can a Smarter = Network > Save Bandwidth without Annoying the Players?," IEEE Communications > Magazine, Consumer Communications and Networking Series, vol. 49, no. > 11, pp. 190-198, Nov. 2011. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnumb= er=3D6069696 > = >=20 >=20 >=20