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

["Jose Saldana" <[e-mail]>]

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