From: "Jose Saldana" <jsaldana@unizar.es>
To: "'Reinaldo Penno \(repenno\)'" <repenno@cisco.com>, <tcmtf@ietf.org>,
 <tsv-area@ietf.org>, <tsv-area@ietf.org>
References: <008c01cee5e1$9caa4590$d5fed0b0$@unizar.es>
 <CEB23B7B.663B%repenno@cisco.com>
In-Reply-To: <CEB23B7B.663B%repenno@cisco.com>
Date: Wed, 27 Nov 2013 12:58:34 +0100
Organization: Universidad de Zaragoza
Message-ID: <001001ceeb67$fffe2e50$fffa8af0$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIc4popvczXRZEqbJZjJ22WVwoSXJmdCOoA
Content-Language: es
Cc: 'Martin Stiemerling' <mls.ietf@googlemail.com>,
 'Spencer Dawkins' <spencerdawkins.ietf@gmail.com>
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Precedence: list
Reply-To: jsaldana@unizar.es

Hi, Reinaldo.=20

> -----Mensaje original-----
> De: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
> Enviado el: mi=E9rcoles, 20 de noviembre de 2013 19:41
> Para: jsaldana@unizar.es; tcmtf@ietf.org; tsv-area@ietf.org
> CC: Martin Stiemerling; 'Spencer Dawkins'
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
>=20
> Hi,
>=20
> Some comments:
(...)=20
> * "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=B2. My first reaction would be to not try to =
list
> available classification methods since it will get into implementation
> details. And what if traffic is e2e encrypted? Given the whole
surveillance
> thing should we we can expect this to happen? How would you know a =
flow
> is candidate or suitable for compression?

One question about this. Our idea is to list some possibilities to be =
used
for a TCM optimizer in order to select the flows to optimize. Some =
examples:

- DPI. However, some people would say that it is against network =
neutrality,
and it may also be difficult if the flow is encrypted.

- Selecting according to IPs and port numbers. For example, if a flow =
has a
destination IP belonging to a game company, it is a clear candidate. =
This
would be possible if there is an agreement between the ISP and the game
company.

- The packets include specific diffserv values.

- Automatic detection based on statistics of Inter-packet time and =
packet
size have also been proposed. They are not against neutrality:
T. T. Nguyen, G. Armitage, P. Branch, S. Zander, =93Timely and =
continuous
machine-learning-based classification for interactive IP traffic,=94 =
IEEE/ACM
Trans. on Networking, 20(6), pp 1880-1894, 2012.

What do you think about these possibilities?

Thanks,

Jose

> * I wonder if some of the possible scenarios really apply. It seems we =
are
> throwing everything to see what sticks.  Example: Journalist covering =
the
a
> cycling competition do not need write their report real time. And if =
they
> need to do a interview, it seems to be working well right now, HD and
> everything.
> * "- an agreement between two network operators could allow them to
> compress a number of flows they are exchanging between a pair of =
Internet
> Routers=B2. Not sure compressing flows between peering routers is a =
good
> use-case.
>=20
>=20
> On 11/20/13, 3:13 AM, "Jose Saldana" <jsaldana@unizar.es> wrote:
>=20
> >TCM-TF charter draft v8
> >
> >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 wireless Internet connection shared by a number of people in a
> >place with low Internet penetration
> >- a community network, in which a number of people in the same
> >geographical place share their connections in a cooperative way
> >- a satellite connection used for collecting the data of a high =
number
> >of sensors.
> >- a satellite connection used for providing connectivity in a
> >non-connected area during a short period of time (e.g. journalists
> >covering the arrival of a mountain stage of a cycling competition).
> >- an air-to-ground connection providing Internet connectivity to the
> >passengers of an aircraft, multiplexing a number of simultaneous VoIP
> >flows.
> >The same can be applied between a cruise ship and a satellite.
> >
> >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. 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), 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 TCM-optimizer (called TCM-ingress optimizer) can =
build
> >a bigger multiplexed packet in which a number of payloads share a
> >common header. Another TCM-optimizer (called TCM-egress optimizer) 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 of ingress/egress optimizers 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 an ingress =
and
> >an egress-optimizer, also including:
> >- a negotiation mechanism to decide the options to use at each layer
> >(header compression, multiplexing and tunneling) between an ingress =
and
> >an egress-optimizer,
> >
> >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. the loss =
of
> >a multiplexed packet, MTU-related
> >issues) will also have to be addressed.
> >
> >9. The working group may identify additional deliverables that are
> >necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to
> >discover an egress optimizer, 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/
> >
> >Current version of Document (TCM-TF - 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