Subject: [tcmtf] Improved version of the TCMTF Charter proposal (v3)

From: "Jose Saldana" <[email-masked]>
Date: Wed, 23 Jan 2013 12:58:54 +0100

Hello all.

After reading the messages in the mailing list, I think we have arrived to a
solution. Each of the documents has been discussed in a separate thread, so
I have tried to take everything into account. Documents (A) and (B) would be
in the Charter. Documents (C) and (D) would only be announced as
possibilities for re-chartering, and Document (E) can wait a little.

We can now try to polish this text. If you agree, please report it in the
list.

So this is the new charter proposal:

*Description of Working Group* v3

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
to the other extreme of the communication. Therefore, its overhead is
significant, and it becomes even higher when IPv6 is used, since the basic
IPv6 header is twice the size of the IPv4 one. 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).

2. In order to improve network efficiency, packets can be grouped when a
number of flows share a path, considering three different layers:

- 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 a number of payloads into a single packet. 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.

3. So the first objective of this group is to develop a document (A) that
will specify the protocol stack for tunneling, compressing and multiplexing
traffic flows (TCMTF). Since other standard protocols are being used, each
layer will use the signaling methods of those protocols. In addition, since
document (A) would include, as one of the options, the current RFC 4170,
this RFC could be obsoleted.

4. The objective of this first document (A) is to define the different
options which can be used at each layer, not the definition of new
compressing, multiplexing or tunneling protocols. 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.

5. If a pair multiplexer/de- multiplexer want to establish a tunnel, 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 each of them implements at each level, and in the
scenario. So document (A) will also include a negotiation mechanism to
decide the options at each layer (header compression, multiplexing and
tunneling) between multiplexer and de-multiplexer, and a mechanism to
setup/release a tunnel between a multiplexer and a de-multiplexer.

6. 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 (B) with useful recommendations in order to decide
which packet flows can or can not be multiplexed and how: the use of
available traffic classification methods; the maximum delay and jitter to be
added to each kind of service or application. Other recommendations will be
included if necessary. Empirical studies will be necessary in order to
establish this set of recommendations.

7. 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.

8. In addition, specific uses of TCMTF, such as wireless and satellite
scenarios could be considered and addressed if some modifications are
required on the protocol.

9. Interactions with other groups can be expected, since TCMTF uses already
defined protocols (ROHC, PPPMux, MPLS, GRE, L2TP).

*Goals and Milestones*

Specification of TCMTF protocol stack (A) and signaling mechanisms.

Recommendations (B) of using existing traffic classification methods,
maximum delay and jitter to add, depending on the service.

------------------------------------

Best regards, and thanks for your wonderful work,

Jose

---

From: <[email-masked]>
Date: Wed, 23 Jan 2013 12:24:04 +0000

Point 8 is ok for us.
Here a slight modification:

8. 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.

Regards,

Matteo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: 23 January 2013 12:59
To: [email-masked]
Cc: Wesley Eddy; Gonzalo Camarillo; Martin Stiemerling
Subject: [tcmtf] Improved version of the TCMTF Charter proposal (v3)

Hello all.

After reading the messages in the mailing list, I think we have arrived to a solution. Each of the documents has been discussed in a separate thread, so I have tried to take everything into account. Documents (A) and (B) would be in the Charter. Documents (C) and (D) would only be announced as possibilities for re-chartering, and Document (E) can wait a little.

We can now try to polish this text. If you agree, please report it in the list.

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 to the other extreme of the communication. Therefore, its overhead is significant, and it becomes even higher when IPv6 is used, since the basic IPv6 header is twice the size of the IPv4 one. 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).

2. In order to improve network efficiency, packets can be grouped when a number of flows share a path, considering three different layers:
- 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 a number of payloads into a single packet. 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.

3. So the first objective of this group is to develop a document (A) that will specify the protocol stack for tunneling, compressing and multiplexing traffic flows (TCMTF). Since other standard protocols are being used, each layer will use the signaling methods of those protocols. In addition, since document (A) would include, as one of the options, the current RFC 4170, this RFC could be obsoleted.

4. The objective of this first document (A) is to define the different options which can be used at each layer, not the definition of new compressing, multiplexing or tunneling protocols. 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.

5. If a pair multiplexer/de- multiplexer want to establish a tunnel, 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 each of them implements at each level, and in the scenario. So document (A) will also include a negotiation mechanism to decide the options at each layer (header compression, multiplexing and tunneling) between multiplexer and de-multiplexer, and a mechanism to setup/release a tunnel between a multiplexer and a de-multiplexer.

6. 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 (B) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how: the use of available traffic classification methods; the maximum delay and jitter to be added to each kind of service or application. Other recommendations will be included if necessary. Empirical studies will be necessary in order to establish this set of recommendations.

7. 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.

8. In addition, specific uses of TCMTF, such as wireless and satellite scenarios could be considered and addressed if some modifications are required on the protocol.

9. Interactions with other groups can be expected, since TCMTF uses already defined protocols (ROHC, PPPMux, MPLS, GRE, L2TP).

*Goals and Milestones*

Recommendations (B) of using existing traffic classification methods, maximum delay and jitter to add, depending on the service.

Jose

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 23 Jan 2013 13:59:40 +0000

Hi,

I see nothing to object. I'd propose to go for it…

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más 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: Mirko Sužnjević <[email-masked]>
Date: Wed, 23 Jan 2013 16:05:48 +0100

Hello everybody,

The document seems fine to me.

Only this sentence seems a bit confusing. I had to re-read it a couple of times:

"However, regarding delay-sensitive services, the Working Group will also develop a document (B) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how: the use of available traffic classification methods; the maximum delay and jitter to be added to each kind of service or application. " 

Maybe it can be split into multiple sentences? 

E.g., However, regarding delay-sensitive services, the Working Group will also develop a document (B) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document (B) will present a list of available traffic classification methods which can be used for identification of the service or application of a particular flow, as well as the recommendations of  the maximum delay and jitter to be added depending of the identified service or application.

Cheers!

Mirko.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, January 23, 2013 12:59 PM
To: [email-masked]
Cc: Wesley Eddy; Gonzalo Camarillo; Martin Stiemerling
Subject: [tcmtf] Improved version of the TCMTF Charter proposal (v3)

Hello all.

*Goals and Milestones*

Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 23 Jan 2013 17:06:13 +0000

It is ok for me too.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: miércoles, 23 de enero de 2013 12:58
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Wesley Eddy <[email-masked]<mailto:[email-masked]>>, 'Gonzalo Camarillo' <[email-masked]<mailto:[email-masked]>>, Martin Stiemerling <[email-masked]<mailto:[email-masked]>>
Subject: [tcmtf] Improved version of the TCMTF Charter proposal (v3)

Hello all.

*Goals and Milestones*

Jose

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 24 Jan 2013 00:16:20 -0500

On 1/23/2013 6:58 AM, Jose Saldana wrote:
> Hello all.
> 
>  
> 
> After reading the messages in the mailing list, I think we have arrived
> to a solution. Each of the documents has been discussed in a separate
> thread, so I have tried to take everything into account. Documents (A)
> and (B) would be in the Charter. Documents (C) and (D) would only be
> announced as possibilities for re-chartering, and Document (E) can wait
> a little.
> 
> ...

In my opinion, this is decent, though here are two criticisms:

(1) In my opinion, it focuses too much on documents to be produced,
    rather than fully and clearly motivating why the working group
    is needed (i.e. to solve a problem, not to develop documents),
    how it's scope is delimited (i.e. what it *won't* touch isn't
    clear to me, along with what other areas/WGs need to be
    coordinated with), and what the end-goal is.

(2) There's a focus on defining technical solutions prior to the
    mention of fleshing out and totally defining the use cases /
    requirements.  In my opinion, that appears backwards :).

That said, I'm generally supportive of this work.  In my opinion,
as an AD, we would normally feel better having a BoF before forming
a WG, for two reasons (1) to get other areas (e.g. RAI) to be aware
of what's being proposed, and (2) to vet that there really is a
community of stakeholders that are engaged to do the work.  In this
case, I think the 2nd point is evident from the mailing list, and
I don't have a concern about it at all.  I think the 1st point can
be addressed through the responsible AD coordinating with the IESG
and the directorates or area mailing lists that related areas have.
Since I'm going away as an AD though, what really matters at the
moment is what Martin thinks :).

-- 
Wes Eddy
MTI Systems

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Jan 2013 08:12:16 +0200

Hi Wes,

> (1) to get other areas (e.g. RAI) to be aware
> of what's being proposed

there are already quite a few RAI people following and participating in
this work. In any case, as an alternative to having a full-blown BOF to
make RAI (in particular) as a whole aware of this effort, I can just
drop an email to the DISPATCH list and will achieve the same results.

Cheers,

Gonzalo

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 24 Jan 2013 10:40:53 +0100

Hi,

> After reading the messages in the mailing list, I think we have arrived to a solution. Each of the documents has been discussed in a separate thread, so I have tried to take everything into account…

For the sake of planning, let's consider document (E) as a discussion item when re-chartering.

> *Description of Working Group* v3

Looks good to me.

Luigi

> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: <[email-masked]>
Date: Tue, 29 Jan 2013 08:17:45 +0000

Dear all,

I don't have a huge experience in IETF, but feel it is important to express my opinion this time.
I have the feeling building a new WG is a bit premature, considering that we just have an Internet draft.
I also find the discussion a bit documents-driven, rather than problems-driven.
IMHO we could wait a bit, before creating the WG, to see whether the ideas we have really solve real-world problems.

That's it. Hope this helps.

Matteo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: 24 January 2013 06:16
To: [email-masked]
Cc: [email-masked]; Gonzalo Camarillo; Martin Stiemerling
Subject: Re: [tcmtf] Improved version of the TCMTF Charter proposal (v3)

On 1/23/2013 6:58 AM, Jose Saldana wrote:
> Hello all.
> 
>  
> 
> After reading the messages in the mailing list, I think we have 
> arrived to a solution. Each of the documents has been discussed in a 
> separate thread, so I have tried to take everything into account. 
> Documents (A) and (B) would be in the Charter. Documents (C) and (D) 
> would only be announced as possibilities for re-chartering, and 
> Document (E) can wait a little.
> 
> ...

That said, I'm generally supportive of this work.  In my opinion, as an AD, we would normally feel better having a BoF before forming a WG, for two reasons (1) to get other areas (e.g. RAI) to be aware of what's being proposed, and (2) to vet that there really is a community of stakeholders that are engaged to do the work.  In this case, I think the 2nd point is evident from the mailing list, and I don't have a concern about it at all.  I think the 1st point can be addressed through the responsible AD coordinating with the IESG and the directorates or area mailing lists that related areas have.
Since I'm going away as an AD though, what really matters at the moment is what Martin thinks :).

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 29 Jan 2013 10:56:19 +0100

Matteo,

Thanks a lot. Well, in this case, I don't agree with you (only in this
case).

The idea with TCMTF was to create a "small" Working Group, the same way as
they are created in other Areas (e.g. RAI). 

As Wes said in November, " In my opinion, it is something a separate WG
should be created to handle, and not something to try to do inside the
TSVWG, since there are already a handful of things TSVWG is wrestling with,
and it creates too much "context switching" to have a lot of unrelated
topics under work there."

The question is that the TSVWG group has a lot of interesting things now,
and it would be better to discuss TCMTF separately. In fact, since the
Summer, we are discussing it in another mailing list. This is good, but in
fact many people from TSVWG have not followed our discussion.

In addition, a lot of time has passed. TCMTF draft was presented in Paris 10
months ago. A lot of people from many institutions have become interested on
it. We have two drafts and three more possibilities.

Neither am I an expert on IETF, but I understand that things have some
"momentum": if you let time go by, people may lose their interest. And
curently interest does exist, as we have seen in the list. So why not now?

In addition, the new version of the Charter is more problem-centered (I
hope).

Thanks and best regards,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> [email-masked]
> Enviado el: martes, 29 de enero de 2013 9:18
> Para: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked];
> [email-masked]
> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal (v3)
> 
> Dear all,
> 
> I don't have a huge experience in IETF, but feel it is important to
express my
> opinion this time.
> I have the feeling building a new WG is a bit premature, considering that
we
> just have an Internet draft.
> IMHO we could wait a bit, before creating the WG, to see whether the ideas
> we have really solve real-world problems.
> 
> That said, I'm generally supportive of this work.  In my opinion, as an
AD, we
> would normally feel better having a BoF before forming a WG, for two
> reasons (1) to get other areas (e.g. RAI) to be aware of what's being
> proposed, and (2) to vet that there really is a community of stakeholders
> that are engaged to do the work.  In this case, I think the 2nd point is
> evident from the mailing list, and I don't have a concern about it at all.
I
> think the 1st point can be addressed through the responsible AD
> coordinating with the IESG and the directorates or area mailing lists that
> related areas have.

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 29 Jan 2013 10:13:52 +0000

Hi all,

        In my opinion the WG is needed. TCMTF discussion have reach enough
interest and enough roadmap to have a room for itself, at least an small
room. As Jose said, there are two enough active drafts and there is
potentially room for three more, and I think this is a justification by
itself.
        On the other hand, I also think that we are problem centered. At least
being in a network operation feet I find TCMTF useful enough.

Regards,

Fernando Pascual Blanco

On 29/01/13 10:56, "Jose Saldana" <[email-masked]> wrote:

>> Since I'm going away as an AD though, what really matters at the moment
>>is
>> what Martin thinks :).
>>
>> --
>> Wes Eddy
>> MTI Systems

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Jan 2013 11:38:55 +0100

Hi all,

The BoF deadline for the upcoming meeting was Jan 28.

Further, my understanding is the relevant proponents cannot make it to 
the IETF meeting in March in Orlando, but that there is a plan for the 
IETF meeting in Berlin in July 2013.

   Martin

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 29 Jan 2013 11:57:40 +0100

Yes, Martin. The idea is that many interested people may attend IETF Berlin
in July: at least I know about interested people from U. Zaragoza, DLR,
Telefonica, U. Zagreb, U. Stuttgart, who could attend that BoF. And also
co-authors from Cisco (Dan, Michael, and perhaps Muthu) may be there. Well,
these are the news I have. In addition, Mirko and I would also be able to
organize the "online games traffic tutorial there".

So is your idea to have a BoF for discussing the TCMTF WG in Berlin? Do you
prefer that possibility instead of the "DISPATCH" option that Gonzalo
suggested? If you confirm that, we would take it into account in order to
organize the summer calendar.

Thanks a lot,

Jose
PS: This is the option that Gonzalo suggested to Wes (November 29th):
"Hi Wes,

sure. When the proponents have a charter proposal ready, feel free to send
it to the TSVAREA list for comments while informing all the other lists. If
you want, I can take care of informing the DISPATCH list pointing to the
relevant message in the TSVAREA list when you send it.

With respect to where discussions should take place, DISPATCH participants
will find it easier to send comments on the DISPATCH list.
However, if sending comments requires subscribing to a different list and
sending comments to a different crowd, many may not bother commenting. I can
monitor the discussions in DISPATCH and send you a summary if needed. Since
we are talking about very few lists, it should be relatively easy to keep
things under control.

Cheers,

Gonzalo"
> Martin Stiemerling
> Enviado el: martes, 29 de enero de 2013 11:39
> Para: FERNANDO PASCUAL BLANCO
> CC: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Further, my understanding is the relevant proponents cannot make it to the
> IETF meeting in March in Orlando, but that there is a plan for the IETF
> meeting in Berlin in July 2013.
> 
>    Martin
> 
> >          In my opinion the WG is needed. TCMTF discussion have reach
> > enough interest and enough roadmap to have a room for itself, at least
> > an small room. As Jose said, there are two enough active drafts and
> > there is potentially room for three more, and I think this is a
> > justification by itself.
> >          On the other hand, I also think that we are problem centered.
> > At least being in a network operation feet I find TCMTF useful enough.
> >
> > Regards,
> >
> > Fernando Pascual Blanco
> >> Thanks a lot. Well, in this case, I don't agree with you (only in
> >> this case).
> >>
> >> The idea with TCMTF was to create a "small" Working Group, the same
> >> way as they are created in other Areas (e.g. RAI).
> >>
> >> As Wes said in November, " In my opinion, it is something a separate
> >> WG should be created to handle, and not something to try to do inside
> >> the TSVWG, since there are already a handful of things TSVWG is
> >> wrestling with, and it creates too much "context switching" to have a
> >> lot of unrelated topics under work there."
> >>
> >> The question is that the TSVWG group has a lot of interesting things
> >> now, and it would be better to discuss TCMTF separately. In fact,
> >> since the Summer, we are discussing it in another mailing list. This
> >> is good, but in fact many people from TSVWG have not followed our
> discussion.
> >>
> >> In addition, a lot of time has passed. TCMTF draft was presented in
> >> Paris
> >> 10
> >> months ago. A lot of people from many institutions have become
> >> interested on it. We have two drafts and three more possibilities.
> >>
> >> "momentum": if you let time go by, people may lose their interest.
> >> And curently interest does exist, as we have seen in the list. So why
not
> now?
> >>
> >> In addition, the new version of the Charter is more problem-centered
> >> (I hope).
> >>
> >> Thanks and best regards,
> >>
> >> Jose
> >>
> >>
> >>> De: [email-masked] [mailto:[email-masked]] En
> nombre
> >>> de [email-masked] Enviado el: martes, 29 de enero de 2013
> >>> 9:18
> >>> I also find the discussion a bit documents-driven, rather than
> >>> problems- driven.
> >>> IMHO we could wait a bit, before creating the WG, to see whether the
> >>> ideas we have really solve real-world problems.
> >>>
> >>>> arrived to a solution. Each of the documents has been discussed in
> >>>> a separate thread, so I have tried to take everything into account.
> >>>> Documents (A) and (B) would be in the Charter. Documents (C) and
> >>>> (D) would only be announced as possibilities for re-chartering, and
> >>> reasons (1) to get other areas (e.g. RAI) to be aware of what's
> >>> being proposed, and (2) to vet that there really is a community of
> >>> stakeholders that are engaged to do the work.  In this case, I think
> >>> the 2nd point is evident from the mailing list, and I don't have a
> >>> concern about it at all.
> >> I
> >>> coordinating with the IESG and the directorates or area mailing
> >>> lists that related areas have.
> > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> > This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in
> England 283 _______________________________________________
> tcmtf mailing list
> [email-masked]

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Jan 2013 12:54:03 +0100

Hi Jose,

> organize the "online games traffic tutorial there".

So Berlin is the place to make a BoF.

> organize the summer calendar.

We do not have the DISPATCH option in the Transport Area.

My proposal is to start socializing the idea within the IETF and to aim 
for a BoF in Berlin. Sending the proposal to the TSVAREA list might be a 
good start.

   Martin