From Martin.Stiemerling@neclab.eu Tue Jun 4 02:54:50 2013 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 941B421F9B62 for ; Tue, 4 Jun 2013 02:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 hrLM2JNWDUZm for ; Tue, 4 Jun 2013 02:54:36 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 937D521F9ACB for ; Tue, 4 Jun 2013 01:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8E458104339 for ; Tue, 4 Jun 2013 10:47:28 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdKv7Lix1iRV for ; Tue, 4 Jun 2013 10:47:28 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 748D9104338 for ; Tue, 4 Jun 2013 10:47:23 +0200 (CEST) Received: from [10.1.99.64] (10.1.99.64) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Jun 2013 10:47:35 +0200 Message-ID: <51ADA9A6.4070609@neclab.eu> Date: Tue, 4 Jun 2013 10:47:34 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Subject: Volunteer for Nomcom 2013-14 Volunteering - 2nd Call References: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> In-Reply-To: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> X-Forwarded-Message-Id: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.99.64] 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, 04 Jun 2013 09:54:50 -0000 Please consider volunteering for the NOMCOM. -------- Original Message -------- Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Date: Wed, 29 May 2013 21:08:56 +0000 From: Mankin, Allison Reply-To: Mankin, Allison To: ietf-announce@ietf.org CC: Sorry - my eye was on entering the reply-to field and then I forgot....apologies in advance for pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" wrote: > Hi, everyone, > > Remember that I'm challenging the IETF to come up with 200 volunteers for > the upcoming nomcom. You can volunteer just by hitting Reply to this email. > > What are you waiting for?? The more volunteers we get, the better chance we > have of choosing a random yet representative cross section of the IETF > population. Respond to the 200-volunteer challenge and hit Reply right now. > (Well, much as I want you to do this, please look below at the posts being > filled and be sure you are willing to forgo trying for any of them this year). > > The official information: > The IETF nominating committee (nomcom) process for 2013-14 is under way. The > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG. Ten voting members for the nomcom are selected in a verifiably > random way from a pool of volunteers. > > The details of the selection and operation of the nomcom can be found > in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, > 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. > > Volunteers must have attended 3 of the past 5 IETF meetings. As specified in > RFC 3777, that means three out of the five past meetings up to the time this > email announcement goes out to start the solicitation of volunteers. The five > meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. > > If you qualify, reply to this email and volunteer. > > The list of people and posts whose terms end with the March 2014 IETF > meeting, and thus the positions for which this nomcom is responsible, are > IAOC: > Chris Griffiths > > IAB: > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig > > IESG: > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) > > The primary activity for this nomcom will begin in July 2013 and should be > completed in January 2014. Being a nomcom member will require some time > commitment - there will be interviews with candidates at meetings, regularly > scheduled conference calls to ensure progress, collection and review of > requirements from the commitment, review of candidate questionnaires and > of community feedback. A more detailed timetable for the nomcom tasks > will appear soon. > > Please respond to this email before 11:59 pm EDT (UTC -4 hours) > June 16, 2013. In the body include: > 1. your Given Name as you enter it when you register for the IETF > 2. your Family Name as you enter it when you register for the IETF > 3. your current primary affilation (the information you enter into the Company field) > 4. any/all email addresses you've used to register for IETF meetings > 5. which email address you prefer > 6. your phone number (for our use in confirming you if selected). > > You should expect an email response from me within 3 business days stating > whether or not you are qualified (and added to the list). If you don't receive this > response, please re-send your email adding the tag "RESEND" to the subject line. > > Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. > Please help us meet the 200-volunteer challenge by hitting Reply to this message today. > > Allison > > Allison Mankin > Nomcom Chair 2013-2014 -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From jsaldana@unizar.es Wed Jun 5 03:56:40 2013 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 7156521F9A5A; Wed, 5 Jun 2013 03:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 KnXIUDgwxC3E; Wed, 5 Jun 2013 03:56:34 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3316121F9A40; Wed, 5 Jun 2013 03:56:34 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r55AuLHR002590; Wed, 5 Jun 2013 12:56:26 +0200 From: "Jose Saldana" To: Subject: TCMTF: Documents to be generated. Small modification Date: Wed, 5 Jun 2013 12:56:24 +0200 Organization: Universidad de Zaragoza Message-ID: <004d01ce61db$55415480$ffc3fd80$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5h2eb/R9lrIRTzTmSkhKAFyvT4WQ== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsv-area@ietf.org, Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 10:56:40 -0000 In the conf-call of yesterday it was also clear that for the IETF it is better to split Document A into two documents: - The "TCMTF reference model" (1): the protocol stack and scenarios. It should be said that each protocol at each layer will use its own = signaling mechanisms. - The "TCMTF-specific signaling": there are some things we will need to deploy: - a negotiation mechanism (2) to decide the options to use at each layer (e.g. a mux and demux agree on using ROHC+PPPMux+GRE) - a mechanism to setup/release a TCMTF tunnel (3)between a multiplexer and a de-multiplexer The current draft is the TCMTF "reference model", since it does not talk about specific signaling issues. By now, we don't have to propose the "TCMTF specific signaling". It = would be something to be deployed if the Working Group is created. This same idea was proposed by Ken Carlberg in February. The advantages = of this new distribution of the documents are (quoting Ken): > One thing to keep in mind is that it is possible that (2) and (3) > (below) can change over time and yet (1) (the reference model) does = not, > then it may be best to separate (1) from the other items. > a more encompassing architecture or framework that would include = sample > scenarios upon which your deliverables A & B are aimed at? My = impression > is that you may want to point the reader of documents A & B to the = same > reference model, and instead of repeating the same text, it may be > helpful to separate this into a separate document. Once discussed, I would create a new charter proposal including these changes. Do you like these short names for the documents? - "TCMTF reference model". https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/=20 - "TCMTF-specific signaling". Future work - "TCMTF recommendations". http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Your feedback will be welcome. Thanks! Jose > -----Mensaje original----- > De: ken carlberg [mailto:carlberg@g11.org.uk] > Enviado el: martes, 05 de marzo de 2013 17:07 > Para: jsaldana@unizar.es > CC: 'ken carlberg'; tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF = in > IETF87 >=20 > Hola Jose, >=20 > Thanks for the expanded explanation, and again, apologies for the = tardy > repsonse. Its helpful to understand that document A and B are = sequential to > each other. One thing to keep in mind is that if its possible that 2 = and 3 > (below) can change over time and yet 1 (the reference model) does not, > then it may be best to separate 1 from the other items. >=20 > as for what you outline as a discussion point for future work, it = seems fine. I > just have a personal bias that if you have a clear idea of the things you'd like > to accomplish in the future, then having a requirements document would = be > helpful to focus those thoughts without having to have one particular > solution. But that's a discussion point that could be brought up = during the > BoF, or sometime afterwards. >=20 > cheers, >=20 > -ken >=20 >=20 > > A main document (A) in which we explain the method, the scenarios = and > > the minimum signaling issues in order to make it work. The idea is > > that document > > (A) would be self-contained. Since we are not defining new protocols (i.e. > > already existing compressing, multiplexing and tunneling protocols = are > > to be used), we understand that this can be done in a single = document. > > It would > > include: > > > > 1- Protocol stack (it would be the "reference model") > > 2- a negotiation mechanism to decide the options to use at each = layer > > 3- a mechanism to setup/release a tunnel between a multiplexer and a > > de-multiplexer > > > > Of course, another approach could be separating 1 from 2&3. However, > > we think this is not necessary since the method is not too = complicated. > > > > > > Document (B) would only contain recommendations of how to better use > > the method proposed in document (A), i.e., classification and = maximum > delays. > > > > So clearly document (B) would totally depend on the reference model = of > > document (A). > > > > > > The idea of point 9 is to talk about some other interesting ideas > > which are considered as "future work": > > - a mechanism for a multiplexer to discover a de-multiplexer > > - mechanism to select an optimal multiplexer and a de-multiplexer = when > > there are more than one muxer/de-muxer for a flow > > - dynamically applying TCMTF > > - etc. > > > > What do you think? > > > > Thanks again for your feedback. Thinking and explaining things is > > always a good exercise! > > > > Jose > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > >> de ken carlberg Enviado el: mi=E9rcoles, 27 de febrero de 2013 = 16:23 > >> Para: jsaldana@unizar.es > >> CC: tcmtf@ietf.org; tsv-area@ietf.org > >> Asunto: Re: [tcmtf] About the possibility of having a BOF about = TCMTF > >> in > >> IETF87 > >> > >> Hola Jose, > >> > >> sorry for the tardy reply. The altered text below is helpful, = thanks. > >> > >> With respect to your candidate deliverables, it appears that you = have > > listed > >> two for the proposed group: (A) a document that describes options = and > >> negotiation mechanisms, and (B) a document describing > recommendations > >> of which packet types should be multiplexed and a list fo traffic > > classification > >> methods. Have you considered a third document that presents a more > >> encompassing architecture or framework that would include sample > >> scenarios upon which your deliverables A & B are aimed at? My > >> impression > > is > >> that you may want to point the reader of documents A & B to the = same > >> reference model, and instead of repeating the same text, it may be > >> helpful to separate this into a separate document. > >> > >> Also, would section 9 of your proposed charter lead one to consider = a > >> requirements document? Many times, new groups start with a > >> requirements document, but since you have a good focus of what you > >> want to accomplish, perhaps your last deliverable could be a > >> requirements document that would guide any future work. > >> > >> -ken > >> > >> ps, I don't want to advocate more work, but rather just have you > >> consider other possibilities (and feel free to shoot them down :-) > >> > >> > >> On Feb 22, 2013, at 5:39 AM, Jose Saldana = wrote: > >> > >>> Hi Ken, > >>> > >>> Sorry for the delay. I think you are talking about Paragraph 5: > >>> > >>> 5. So the first objective of this group is to specify the protocol > >>> stack for tunneling, compressing and multiplexing traffic flows > >>> (TCMTF). 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. > >>> > >>> Perhaps this is a bit confusing. When we say "at each layer", we = are > >>> talking about "tunneling, compressing and multiplexing" layers. > >>> Perhaps this can be a bit confusing. What about this?: > >>> > >>> 5. So the first objective of this group is to specify the protocol > >>> stack for tunneling, compressing and multiplexing traffic flows > >>> (TCMTF). Since standard protocols are being used for tunneling, > >>> compressing and multiplexing layers, 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. > >>> > >>> Is this what you were asking? > >>> > >>> Thanks for your feedback. > >>> > >>> Jose > >>> > >>>> -----Mensaje original----- > >>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En > >>>> nombre de ken carlberg Enviado el: martes, 19 de febrero de 2013 > >>>> 14:17 > >>>> Para: jsaldana@unizar.es > >>>> CC: tcmtf@ietf.org; tsv-area@ietf.org > >>>> Asunto: Re: [tcmtf] About the possibility of having a BOF about > >>>> TCMTF in > >>>> IETF87 > >>>> > >>>> Hola Jose, > >>>> > >>>> could you expand a bit more on your text in the proposed charter > >>>> regarding "signaling methods". Are you speaking in the more > >>>> general context of information stored in headers of various > >>>> protocol up and down the stack > >>> (ie, > >>>> layers 3, 4, and 5/app)? Or, are you speaking of concurrent > >>>> resource signaling protocols like RSVP/RSVP-TE, or path > >>>> establishment protocols > >>> like > >>>> MPLS? Or, some combination of both? > >>>> > >>>> -ken > >>>> > >>>> _______________________________________________ > >>>> tcmtf mailing list > >>>> tcmtf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > From jsaldana@unizar.es Thu Jun 13 01:38:02 2013 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 0572421F9A97; Thu, 13 Jun 2013 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 smx6NEDvfzzz; Thu, 13 Jun 2013 01:37:57 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4621F9A7A; Thu, 13 Jun 2013 01:37:56 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5D8bj49003891; Thu, 13 Jun 2013 10:37:46 +0200 From: "Jose Saldana" To: , Subject: Improved version of the tmctf Draft charter (v6) Date: Thu, 13 Jun 2013 10:37:51 +0200 Organization: Universidad de Zaragoza Message-ID: <006401ce6811$4af07b50$e0d171f0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5oEUJh6X32UcmxT3KmocW8KKc14Q== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:38:02 -0000 This is the new proposal, adapted to the new distribution of the = documents. I explain the changes in another e-mail. It is also here, in a formatted version: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf TCMTF charter draft v6 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=E9 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 (TCMTF). 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 (TCMTF - 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 TCMTF = 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 (TCMTF - negotiation protocol) will include: - a mechanism to setup/release a TCMTF 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,=20 8. As a counterpart of the bandwidth saving, TCMTF 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 (TCMTF - 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. If other interesting features are identified, the group would = re-charter and include them, e.g., a mechanism for a multiplexer to discover a de-multiplexer, and vice versa; a mechanism to select an optimal = multiplexer and a de-multiplexer when there are more than one muxer/de-muxer for a = flow; dynamically applying TCMTF: a higher entity in charge of deciding when = and where, applying or not TCMTF, and what kind of TCMTF, and what = multiplexing period. Additional methods for estimating delay would also be required. 10. In addition, specific uses of TCMTF, such as in wireless and = satellite scenarios, could be considered, and it will be studied whether = modifications or extensions are required on the protocol. 11. Interactions with other Working Groups can be expected, since TCMTF = uses already defined protocols for compression, multiplexing and tunneling = (ROHC, PPPMux, MPLS, GRE, L2TP).=20 Goals and Milestones Specification of TCMTF reference model. Specification of TCMTF negotiation protocol. Specification of TCMTF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on = the service. Current version of Document (TCMTF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCMTF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Best regards, Jose From jsaldana@unizar.es Thu Jun 13 01:43:08 2013 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 3DD1221F99B2; Thu, 13 Jun 2013 01:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 IsqlzWQkamJw; Thu, 13 Jun 2013 01:43:03 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5B21F8930; Thu, 13 Jun 2013 01:43:02 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5D8gx0o008469; Thu, 13 Jun 2013 10:43:00 +0200 From: "Jose Saldana" To: , References: <006401ce6811$4af07b50$e0d171f0$@unizar.es> In-Reply-To: <006401ce6811$4af07b50$e0d171f0$@unizar.es> Subject: RE: [tcmtf] Improved version of the tmctf Draft charter (v6) Date: Thu, 13 Jun 2013 10:43:05 +0200 Organization: Universidad de Zaragoza Message-ID: <006501ce6812$060676b0$12136410$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH8N/Xy9eDz5XZCFkPyyAOW2cIPWpjXstnw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:43:08 -0000 These are the main changes included in the draft charter v6 (ordered by paragraphs): 1. I have moved the sentence about the overhead to the end of the = paragraph, in order to say that =93For both the delay-sensitive and = delay-insensitive applications, their small data payloads incur significant overhead=94=20 2. I have put the scenarios in bullets, and I have improved some of the descriptions a bit. 6. I have changed the name of the document: instead of =93document A=94 = it is now =93TCMTF =96 reference model=94. 7. Now we are talking about another document =93TCMTF =96 negotiation = protocol=94. In addition, I have put the two signaling functionalities in bullets. 7. As discussed in the list, we would talk about =93setup/release a = TCMTF session=94. 8. I have changed the name of the document, from =93document B=94 to = =93TCMTF recommendations=94 8. According to Gorry=92s suggestion, I have added this sentence: =93The eventual impact of multiplexing on protocol dynamics (e.g. when = multiplexing TCP flows) will also have to be addressed.=94 Jose=20 > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Jose Saldana > Enviado el: jueves, 13 de junio de 2013 10:38 > Para: tcmtf@ietf.org; tsv-area@ietf.org > Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6) >=20 > This is the new proposal, adapted to the new distribution of the documents. > I explain the changes in another e-mail. > It is also here, in a formatted version: > http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf >=20 >=20 > TCMTF charter draft v6 >=20 > Description of Working Group >=20 > 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. >=20 > 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: >=20 > - 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=E9 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. >=20 > 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. >=20 > 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: >=20 > - 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. >=20 > 5. So the first objective of this group is to specify the protocol = stack for > tunneling, compressing and multiplexing traffic flows (TCMTF). 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. >=20 > 6. As a first objective, a document (TCMTF - 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. >=20 > 7. If a pair multiplexer/de-multiplexer want to establish a TCMTF = 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 (TCMTF - negotiation = protocol) will > include: >=20 > - a mechanism to setup/release a TCMTF 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, >=20 > 8. As a counterpart of the bandwidth saving, TCMTF 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 (TCMTF - 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. >=20 > 9. If other interesting features are identified, the group would re-charter and > include them, e.g., a mechanism for a multiplexer to discover a de- > multiplexer, and vice versa; a mechanism to select an optimal = multiplexer > and a de-multiplexer when there are more than one muxer/de-muxer for a > flow; dynamically applying TCMTF: a higher entity in charge of = deciding when > and where, applying or not TCMTF, and what kind of TCMTF, and what > multiplexing period. Additional methods for estimating delay would = also be > required. >=20 > 10. In addition, specific uses of TCMTF, such as in wireless and = satellite > scenarios, could be considered, and it will be studied whether modifications > or extensions are required on the protocol. >=20 > 11. Interactions with other Working Groups can be expected, since = TCMTF > uses already defined protocols for compression, multiplexing and = tunneling > (ROHC, PPPMux, MPLS, GRE, L2TP). >=20 > Goals and Milestones >=20 > Specification of TCMTF reference model. >=20 > Specification of TCMTF negotiation protocol. >=20 > Specification of TCMTF recommendations of using existing traffic > classification methods, maximum delay and jitter to add, depending on = the > service. >=20 >=20 > Current version of Document (TCMTF - reference model): > https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ >=20 > Current version of Document (TCMTF - recommendations): > http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ >=20 >=20 > Best regards, >=20 > Jose >=20 >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Mon Jun 17 00:32:31 2013 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 E4EDC21F9AA2; Mon, 17 Jun 2013 00:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 3o-1K9J-WY7M; Mon, 17 Jun 2013 00:32:25 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3A721F9A79; Mon, 17 Jun 2013 00:32:23 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5H7VmAl023833; Mon, 17 Jun 2013 09:31:57 +0200 From: "Jose Saldana" To: "'FERNANDO PASCUAL BLANCO'" , , References: <006501ce6812$060676b0$12136410$@unizar.es> In-Reply-To: Subject: RE: [tcmtf] Improved version of the tmctf Draft charter (v6) Date: Mon, 17 Jun 2013 09:31:49 +0200 Organization: Universidad de Zaragoza Message-ID: <004a01ce6b2c$c640ed80$52c2c880$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCxHvivfYQiVdXTBQska4oYY5UEFpt0F+mg Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:32:31 -0000 Hi, Fernando. I agree with you. We are talking about standards so precision is = important. I don't think we should use the "verb" "to TCMTF" nor "TCMTFing" nor "TCMTFed". We cannot invent new English verbs. What about "optimization"?. This concept summarizes the three layers. We = can use it this way: - A TCMTF optimizer - A packet optimized by means of TCMTF - A flow optimized by means of TCMTF - An optimized packet - An optimized flow - A TCMTF-optimized packet - A TCMTF-optimized flow - A TCMTF packet - A TCMTF flow - the TCMTF optimization can be applied to that flow - the impact of TCMTF optimization on protocol dynamics I have another question here: could we use only TCM instead of TCMTF? Remember that TF means "traffic flows", so a TCMTF flow would be a "tunneling compressed multiplexed traffic flows flow". Perhaps a TCM = flow would be enough in those cases. TCM does not have another related = meaning and it is shorter than TCMTF (http://www.acronymfinder.com/TCM.html) - A TCM optimizer - A TCM-optimized flow - A TCM flow What do you think? Jose > -----Mensaje original----- > De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] > Enviado el: viernes, 14 de junio de 2013 21:29 > Para: jsaldana@unizar.es; tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] Improved version of the tmctf Draft charter (v6) >=20 > Hi Jose, >=20 > I like all your changes, they all enrich the WG description. >=20 > Nevertheless I wanted to mention, after read carefully the = text, that > when we talk about layers, we always use the three terms (tunneling, > multiplexing and compression) and I think it is ok. > When we talk about the elements in charge of apply the TCMTF protocol > we have call them multiplexers and demultiplexers, and that may be a little > confusing, given that they use the name of the middle protocol layer, = but I > understand that we have not found a better name (I include myself = here) > and maybe multiplexing is the most representative layer, so it could = be ok. > But in paragraph 8 we talk about multiplexing flows and the = impact of > multiplexing in protocol dynamics, and I think that may be confusing, given > that using "multiplexing" we are referring to apply the whole TCMTF protocol > or not and not only to apply the multiplexing layer or not. I=B4m just saying that > this term here may be confusing and someone could get a bad = interpretation > from the text. I see three option: a) we pre-define the term "multiplexing" > as the application of the TCMTF protocol itself, b) we invent the verb = "to > TCMTF" and use the participle "TCMTFed" when something is passed = trough > our protocol stack or c) (and maybe the most convenient we use the = long > form "the TCMTF protocol can be applied to that flow" or "the impact = of > TCMTF protocol on protocol dynamics". My suggestion is to use option = c). >=20 > What do you think? >=20 > Thank you for your great effort! >=20 > Best, >=20 > Fernando Pascual Blanco > Telef=F3nica Global Resources > Network Automation and Dynamization > TECHNOLOGY PEOPLE GROUP > F +34913128779 > M +34682005168 > fpb@tid.es >=20 >=20 >=20 >=20 > On 13/06/13 10:43, "Jose Saldana" wrote: >=20 > >These are the main changes included in the draft charter v6 (ordered = by > >paragraphs): > > > >1. I have moved the sentence about the overhead to the end of the > >paragraph, in order to say that =B3For both the delay-sensitive and > >delay-insensitive applications, their small data payloads incur > >significant overhead=B2 > > > >2. I have put the scenarios in bullets, and I have improved some of = the > >descriptions a bit. > > > >6. I have changed the name of the document: instead of =B3document = A=B2 it > >is now =B3TCMTF =AD reference model=B2. > > > >7. Now we are talking about another document =B3TCMTF =AD negotiation > >protocol=B2. > >In addition, I have put the two signaling functionalities in bullets. > > > >7. As discussed in the list, we would talk about =B3setup/release a = TCMTF > >session=B2. > > > >8. I have changed the name of the document, from =B3document B=B2 to > =B3TCMTF > >recommendations=B2 > > > >8. According to Gorry=B9s suggestion, I have added this sentence: = =B3The > >eventual impact of multiplexing on protocol dynamics (e.g. when > >multiplexing TCP flows) will also have to be addressed.=B2 > > > >Jose > > > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > >> de Jose Saldana Enviado el: jueves, 13 de junio de 2013 10:38 > >> Para: tcmtf@ietf.org; tsv-area@ietf.org > >> Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6) > >> > >> This is the new proposal, adapted to the new distribution of the > >documents. > >> I explain the changes in another e-mail. > >> It is also here, in a formatted version: > >> = http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf > >> > >> > >> TCMTF charter draft v6 > >> > >> 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=E9 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 (TCMTF). = 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 (TCMTF - 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 TCMTF > >>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 (TCMTF - = negotiation > >> protocol) > >will > >> include: > >> > >> - a mechanism to setup/release a TCMTF 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, TCMTF 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 (TCMTF - 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. If other interesting features are identified, the group would > >re-charter and > >> include them, e.g., a mechanism for a multiplexer to discover a de- > >>multiplexer, and vice versa; a mechanism to select an optimal > >>multiplexer and a de-multiplexer when there are more than one > >>muxer/de-muxer for a flow; dynamically applying TCMTF: a higher > >>entity in charge of deciding > >when > >> and where, applying or not TCMTF, and what kind of TCMTF, and what > >>multiplexing period. Additional methods for estimating delay would > >>also be required. > >> > >> 10. In addition, specific uses of TCMTF, such as in wireless and > >>satellite scenarios, could be considered, and it will be studied > >>whether > >modifications > >> or extensions are required on the protocol. > >> > >> 11. Interactions with other Working Groups can be expected, since > >>TCMTF uses already defined protocols for compression, multiplexing > >>and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). > >> > >> Goals and Milestones > >> > >> Specification of TCMTF reference model. > >> > >> Specification of TCMTF negotiation protocol. > >> > >> Specification of TCMTF recommendations of using existing traffic > >>classification methods, maximum delay and jitter to add, depending = on > >>the service. > >> > >> > >> Current version of Document (TCMTF - reference model): > >> https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ > >> > >> Current version of Document (TCMTF - recommendations): > >> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ > >> > >> > >> Best regards, > >> > >> Jose > >> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > >_______________________________________________ > >tcmtf mailing list > >tcmtf@ietf.org > >https://www.ietf.org/mailman/listinfo/tcmtf >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace > situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send = and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx From diego@tid.es Mon Jun 17 06:40:38 2013 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 EB91921F91CE; Mon, 17 Jun 2013 06:40:38 -0700 (PDT) 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 BAOd9aZAUMIR; Mon, 17 Jun 2013 06:40:35 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7C21F8E8C; Mon, 17 Jun 2013 06:40:33 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MOJ00I1MHZILH@tid.hi.inet>; Mon, 17 Jun 2013 15:40:31 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id BA.1A.05654.FC11FB15; Mon, 17 Jun 2013 15:40:31 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MOJ00I1PHZJLH@tid.hi.inet>; Mon, 17 Jun 2013 15:40:31 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 15:40:30 +0200 Date: Mon, 17 Jun 2013 13:39:35 +0000 From: "Diego R. Lopez" Subject: Re: [tcmtf] Improved version of the tmctf Draft charter (v6) In-reply-to: <004a01ce6b2c$c640ed80$52c2c880$@unizar.es> X-Originating-IP: [10.95.64.115] To: "" Message-id: Content-id: <0D78D1ED9A64DA4096C16C0A820445EE@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [tcmtf] Improved version of the tmctf Draft charter (v6) Thread-index: Ac5oEUJh6X32UcmxT3KmocW8KKc14f//3/+AgAJobQCAA8z8gIAANnKA X-AuditID: 0a5f4e69-b7f4b6d000001616-bc-51bf11cf2ae6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42Lhivcz1D0vuD/Q4EWPmMWuzxsYLRa8Wczs wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mx7c+sBf0VFQ8nv6YqYFxTmIXIyeHhICJxIT7n1kg bDGJC/fWs4HYQgLbGSVa31lB2M8YJVats+9i5AKyNzBKzN+xjR0kwSKgKtHw8hsTiM0GZD9q /g0WFxZwlfjw8QfYIE4BC4nJ9w8zQyxQkPhz7jHYMhEBfYkbjyHqmQWqJPZs3c8IYvMKeEus vvKDESJuJnF33392iLigxI/J91gg4joSvd+/MUPY4hLNrTeh4toST95dYAWxGQVkJd7Nn88K sctN4tOEI3D2psu32CDuEZBYsuc81G2iEi8f/2OFeHI5o8TWtp2MExglZiG5YxaSO2YhuWMW kjtmIbljASPrKkax4qSizPSMktzEzJx0AyO9jEy9zLzUkk2MkAjM3MG4fKfKIUYBDkYlHl6O un2BQqyJZcWVuYcYJTiYlUR4YycChXhTEiurUovy44tKc1KLDzEycXBKNTCyHTGMvxN1zSO+ 8dfLswsfi/uf+mU73yZDnNFocVzczzlMLNx+k87VH55uql29dPnxKods3eglyXdWHmg7/5aF uykkdFLUsiUfWdwvXrvwfuLLf39sEx6qnTLZ9ENns+yH5b9+c7TmHJw5qWOZh/Grd1dE720M 2VxszD3pl+XcraYFyzJr8s8tUWIpzkg01GIuKk4EANGeGBKeAgAA References: <006501ce6812$060676b0$12136410$@unizar.es> <004a01ce6b2c$c640ed80$52c2c880$@unizar.es> Cc: "" , "" , FERNANDO PASCUAL BLANCO 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: Mon, 17 Jun 2013 13:40:39 -0000 Hi Jose, I like your latter proposal. TCM-* should be enough: TCMTF technology is pr= ovided (and leveraged) by TCM-* elements. Only a comment on your first statement: we *can* invent new English verbs. = English does not have stupid institutions like our Academy, but this is a c= ompletely different discussion... Be goode, On 17 Jun 2013, at 09:31 , Jose Saldana wrote: > Hi, Fernando. > > I agree with you. We are talking about standards so precision is importan= t. > > I don't think we should use the "verb" "to TCMTF" nor "TCMTFing" nor > "TCMTFed". We cannot invent new English verbs. > > What about "optimization"?. This concept summarizes the three layers. We = can > use it this way: > > - A TCMTF optimizer > > - A packet optimized by means of TCMTF > - A flow optimized by means of TCMTF > - An optimized packet > - An optimized flow > - A TCMTF-optimized packet > - A TCMTF-optimized flow > - A TCMTF packet > - A TCMTF flow > > - the TCMTF optimization can be applied to that flow > - the impact of TCMTF optimization on protocol dynamics > > I have another question here: could we use only TCM instead of TCMTF? > Remember that TF means "traffic flows", so a TCMTF flow would be a > "tunneling compressed multiplexed traffic flows flow". Perhaps a TCM flow > would be enough in those cases. TCM does not have another related meaning > and it is shorter than TCMTF (http://www.acronymfinder.com/TCM.html) > > - A TCM optimizer > - A TCM-optimized flow > - A TCM flow > > What do you think? > > Jose > >> -----Mensaje original----- >> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] >> Enviado el: viernes, 14 de junio de 2013 21:29 >> Para: jsaldana@unizar.es; tcmtf@ietf.org; tsv-area@ietf.org >> Asunto: Re: [tcmtf] Improved version of the tmctf Draft charter (v6) >> >> Hi Jose, >> >> I like all your changes, they all enrich the WG description. >> >> Nevertheless I wanted to mention, after read carefully the text, > that >> when we talk about layers, we always use the three terms (tunneling, >> multiplexing and compression) and I think it is ok. >> When we talk about the elements in charge of apply the TCMTF > protocol >> we have call them multiplexers and demultiplexers, and that may be a > little >> confusing, given that they use the name of the middle protocol layer, bu= t > I >> understand that we have not found a better name (I include myself here) >> and maybe multiplexing is the most representative layer, so it could be > ok. >> But in paragraph 8 we talk about multiplexing flows and the impac= t > of >> multiplexing in protocol dynamics, and I think that may be confusing, > given >> that using "multiplexing" we are referring to apply the whole TCMTF > protocol >> or not and not only to apply the multiplexing layer or not. I=B4m just > saying that >> this term here may be confusing and someone could get a bad interpretati= on >> from the text. I see three option: a) we pre-define the term > "multiplexing" >> as the application of the TCMTF protocol itself, b) we invent the verb "= to >> TCMTF" and use the participle "TCMTFed" when something is passed trough >> our protocol stack or c) (and maybe the most convenient we use the long >> form "the TCMTF protocol can be applied to that flow" or "the impact of >> TCMTF protocol on protocol dynamics". My suggestion is to use option c). >> >> What do you think? >> >> Thank you for your great effort! >> >> Best, >> >> Fernando Pascual Blanco >> Telef=F3nica Global Resources >> Network Automation and Dynamization >> TECHNOLOGY PEOPLE GROUP >> F +34913128779 >> M +34682005168 >> fpb@tid.es >> >> >> >> >> On 13/06/13 10:43, "Jose Saldana" wrote: >> >>> These are the main changes included in the draft charter v6 (ordered by >>> paragraphs): >>> >>> 1. I have moved the sentence about the overhead to the end of the >>> paragraph, in order to say that =B3For both the delay-sensitive and >>> delay-insensitive applications, their small data payloads incur >>> significant overhead=B2 >>> >>> 2. I have put the scenarios in bullets, and I have improved some of the >>> descriptions a bit. >>> >>> 6. I have changed the name of the document: instead of =B3document A=B2= it >>> is now =B3TCMTF =AD reference model=B2. >>> >>> 7. Now we are talking about another document =B3TCMTF =AD negotiation >>> protocol=B2. >>> In addition, I have put the two signaling functionalities in bullets. >>> >>> 7. As discussed in the list, we would talk about =B3setup/release a TCM= TF >>> session=B2. >>> >>> 8. I have changed the name of the document, from =B3document B=B2 to >> =B3TCMTF >>> recommendations=B2 >>> >>> 8. According to Gorry=B9s suggestion, I have added this sentence: =B3Th= e >>> eventual impact of multiplexing on protocol dynamics (e.g. when >>> multiplexing TCP flows) will also have to be addressed.=B2 >>> >>> Jose >>> >>> >>>> -----Mensaje original----- >>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre >>>> de Jose Saldana Enviado el: jueves, 13 de junio de 2013 10:38 >>>> Para: tcmtf@ietf.org; tsv-area@ietf.org >>>> Asunto: [tcmtf] Improved version of the tmctf Draft charter (v6) >>>> >>>> This is the new proposal, adapted to the new distribution of the >>> documents. >>>> I explain the changes in another e-mail. >>>> It is also here, in a formatted version: >>>> http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf >>>> >>>> >>>> TCMTF charter draft v6 >>>> >>>> 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=E9 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 (TCMTF). 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 (TCMTF - 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 TCMTF >>>> 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 (TCMTF - negotiation >>>> protocol) >>> will >>>> include: >>>> >>>> - a mechanism to setup/release a TCMTF 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, TCMTF 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 (TCMTF - 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. If other interesting features are identified, the group would >>> re-charter and >>>> include them, e.g., a mechanism for a multiplexer to discover a de- >>>> multiplexer, and vice versa; a mechanism to select an optimal >>>> multiplexer and a de-multiplexer when there are more than one >>>> muxer/de-muxer for a flow; dynamically applying TCMTF: a higher >>>> entity in charge of deciding >>> when >>>> and where, applying or not TCMTF, and what kind of TCMTF, and what >>>> multiplexing period. Additional methods for estimating delay would >>>> also be required. >>>> >>>> 10. In addition, specific uses of TCMTF, such as in wireless and >>>> satellite scenarios, could be considered, and it will be studied >>>> whether >>> modifications >>>> or extensions are required on the protocol. >>>> >>>> 11. Interactions with other Working Groups can be expected, since >>>> TCMTF uses already defined protocols for compression, multiplexing >>>> and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). >>>> >>>> Goals and Milestones >>>> >>>> Specification of TCMTF reference model. >>>> >>>> Specification of TCMTF negotiation protocol. >>>> >>>> Specification of TCMTF recommendations of using existing traffic >>>> classification methods, maximum delay and jitter to add, depending on >>>> the service. >>>> >>>> >>>> Current version of Document (TCMTF - reference model): >>>> https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ >>>> >>>> Current version of Document (TCMTF - recommendations): >>>> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ >>>> >>>> >>>> Best regards, >>>> >>>> Jose >>>> >>>> >>>> _______________________________________________ >>>> tcmtf mailing list >>>> tcmtf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> _______________________________________________ >>> tcmtf mailing list >>> tcmtf@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcmtf >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx