Re: [tcmtf] Improved version of the tmctf Draft charter (v6)

[Julián Fernández-Navajas <[e-mail]>]

Jose and Gorry and all,
In order to clarify the delay-sensitive application term, i think that 
there are more than two options: sensitive and nonsensitive. I'd prefer 
say delay-very-sensitive's application, delay-sensitive, 
delay-some-sensitive, delay-nonsensitive or something similar
Julián

El 13/06/2013 10:43, Jose Saldana escribió:
> 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 “For both the delay-sensitive and delay-insensitive
> applications, their small data payloads incur significant overhead”
>
> 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 “document A” it is
> now “TCMTF – reference model”.
>
> 7. Now we are talking about another document “TCMTF – negotiation protocol”.
> In addition, I have put the two signaling functionalities in bullets.
>
> 7. As discussed in the list, we would talk about “setup/release a TCMTF
> session”.
>
> 8. I have changed the name of the document, from “document B” to “TCMTF
> recommendations”
>
> 8. According to Gorry’s suggestion, I have added this sentence: “The
> eventual impact of multiplexing on protocol dynamics (e.g. when multiplexing
> TCP flows) will also have to be addressed.”
>
> Jose
>
>
>> -----Mensaje original-----
>> De: [e-mail] [mailto:[e-mail]] En nombre de
>> Jose Saldana
>> Enviado el: jueves, 13 de junio de 2013 10:38
>> Para: [e-mail]; [e-mail]
>> 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é 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcmtf
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf
>
>