[tcmtf] Improved version of the TCM-TF Charter draft (v7)
"Jose Saldana" <jsaldana@unizar.es> Fri, 12 July 2013 18:02 UTC
Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B521F9CB9 for <tcmtf@ietfa.amsl.com>; Fri, 12 Jul 2013 11:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PmEyc+THOyHe for <tcmtf@ietfa.amsl.com>; Fri, 12 Jul 2013 11:01:57 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id D74FE21F991E for <tcmtf@ietf.org>; Fri, 12 Jul 2013 11:01:56 -0700 (PDT)
Received: from jsaldanapc (41.Red-88-4-241.dynamicIP.rima-tde.net [88.4.241.41]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r6CI1jq1021378; Fri, 12 Jul 2013 20:01:46 +0200
From: Jose Saldana <jsaldana@unizar.es>
To: tcmtf@ietf.org
Date: Fri, 12 Jul 2013 20:01:50 +0200
Message-ID: <000c01ce7f29$e2f9ee20$a8edca60$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CE7F3A.A6850810"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5/Jx2Wu1M5wcMCQUCVjA377ZvkVQ==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: 'Gorry Fairhurst' <gorry@erg.abdn.ac.uk>, Janardhan Iyengar <janardhan.iyengar@fandm.edu>, 'Spencer Dawkins' <spencerdawkins.ietf@gmail.com>, Martin Stiemerling <Martin.Stiemerling@neclab.eu>
Subject: [tcmtf] Improved version of the TCM-TF Charter draft (v7)
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2013 18:02:02 -0000
According to Spencers advice, I have just re-built the charter draft. This is the new proposal, in which number 9 and 10 have been improved, with the aim of clearly stating the objectives. This is the charter that will be discussed in the BOF in IETF87, Berlin. A formatted version can also be found here: <http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf> http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf TCM-TF charter draft v7 Description of Working Group 1. In the last years we are witnessing the raise of new real-time services that use the Internet for the delivery of interactive multimedia applications: VoIP, videoconferencing, telemedicine, video vigilance, online gaming, etc. Due to the need of interactivity, many of these services use small packets (some tens of bytes), since they have to send frequent updates between the extremes of the communication. In addition, some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets sending collected data in sensor networks using wireless or satellite scenarios). For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead, and it becomes even higher when IPv6 is used, since the basic IPv6 header is twice the size of the IPv4 one. 2. The efficiency cannot be increased by the inclusion of a higher number of samples in a single packet, since this would harm the delay requirements of the service. But there exist some scenarios in which a number of flows share the same path. In this case, packets belonging to different flows can be grouped together, adding a small multiplexing delay as a counterpart of bandwidth saving. This delay will have to be maintained under some threshold in order to grant the delay requirements. Some examples of the scenarios where grouping packets is possible are: - aggregation networks of a network operator; - an end-to-end tunnel between appliances located in two different offices of the same company; - the access connection of an Internet Café including a high number of VoIP/gaming flows; - an agreement between two network operators could allow them to compress a number of flows they are exchanging between a pair of Internet Routers; - a satellite connection used for collecting the data of a high number of sensors. 3. VoIP using RTP is a clear example of a real-time service using small packets with high overhead. In order to improve efficiency, RFC4170 (TCRTP) defined a method for grouping packets when a number of flows share a path, considering three different layers: header compression by means of ECRTP; multiplexing by means of PPPMux; tunneling by means of L2TPv3. 4. However, in the last years, emerging real-time services which do not use UDP/RTP have become popular: some of them use UDP or even TCP. In addition, new header compression methods have been defined (ROHC). So there is a need of widening the scope of RFC4170 in order to consider not only UDP/RTP but also other protocols. The same structure of three layers will be considered: - Header compression: Taking into account that real-time applications use different headers (RTP/UDP, UDP or even TCP), different protocols can be used: no compression, ECRTP, IPHC and ROHC. - Multiplexing: If a number of flows share a path between an origin and a destination, a multiplexer can build a bigger packet in which a number of payloads share a common header. A demultiplexer is then necessary at the end of the common path, so as to rebuild the packets as they were originally sent. PPPMux will be the main option. Other ones are not discarded. - Tunneling will be used to send the multiplexed packets end-to-end. The options in this layer are L2TP, GRE and MPLS. 5. So the first objective of this group is to specify the protocol stack for tunneling, compressing and multiplexing traffic flows (TCM-TF). Since standard protocols are being used at each layer, the signaling methods of those protocols will be used. Interactions with the Working Groups and Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is not an objective of this Working Group. In addition, since the current RFC 4170 would be considered as one of the options, this RFC could be obsoleted. 6. As a first objective, a document (TCM-TF - reference model) will define the different options which can be used at each layer. Specific problems caused by the interaction between layers will have to be issued, and suitable extensions may have to be added to the involved protocols. 7. If a pair multiplexer/de-multiplexer want to establish a TCM-TF session, they have first to use a mechanism to negotiate which concrete option would they use in each layer: header compression, multiplexing and tunneling. This will depend on the protocols that each extreme implements at each level, and in the scenario. So another document (TCM-TF - negotiation protocol) will include: - a mechanism to setup/release a TCM-TF session between a multiplexer and a de-multiplexer, also including: - a negotiation mechanism to decide the options to use at each layer (header compression, multiplexing and tunneling) between multiplexer and de-multiplexer, 8. As a counterpart of the bandwidth saving, TCM-TF may add some delay and jitter. This is not a problem for the services which are not sensitive to delay. However, regarding delay-sensitive services, the Working Group will also develop a document (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document will present a list of available traffic classification methods which can be used for identification of the service or application to which a particular flow belongs, as well as recommendations of the maximum delay and jitter to be added depending of the identified service or application. The eventual impact of multiplexing on protocol dynamics (e.g., when multiplexing TCP flows) will also have to be addressed. 9. The working group may identify additional deliverables that are necessary/useful, e.g., a mechanism for a multiplexer to discover a de-multiplexer, and vice versa. The working group would re-charter to add them before working on them. 10. In addition, specific uses of TCM-TF, such as in wireless and satellite scenarios, could be considered, and it might be studied whether modifications or extensions are required on the protocol. The working group would re-charter to work on those modifications/extensions. 11. Interactions with other Working Groups can be expected, since TCM-TF uses already defined protocols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). Goals and Milestones Specification of TCM-TF reference model. Specification of TCM-TF negotiation protocol. Specification of TCM-TF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. Current version of Document (TCM-TF - reference model): <https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/> https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): <http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Best regards, Jose
- [tcmtf] Improved version of the TCM-TF Charter dr… Jose Saldana