Subject: [tcmtf] Support to create the working group for TCM-TF

From: "[email-masked]" <[email-masked]>
Date: Thu, 1 Aug 2013 23:52:18 -0400

Dear  Martin Stiemerling, 
Transport Area Director,

I have the honor to approach you about the creation of the working group 
TCM-TF which for us is very interesting for developing countries.For your 
information, our organization '' African Forum for the Promotion of New 
Information and Communication Technologies'' AFP-ICT work to our project  : 
''Training and Connecting Rural People'' (WSIS Project Prizes 2013 : 
E-Learning), which  enters its second phase where we think  the Tunneling, 
Compressing and Multiplexing Traffic Flow (TCM-TF) is interesting and 
better  adapt to the rural areas in general and in particular for 
developing  countries because TCMTF, a proposal for Optimizing the traffic 
of  real-time services and other flows based on small packets. It is based 
on grouping and compressing traffic flows, and it is ble to save 50% or 
even 60% of the bandwidth for some services. 
In many of our countries development project, we have a lot of problems 
regarding the provision of services (traffic flow). Especially in rural 
areas (our workplace for the development of ICT) encompassing a large part 
of the African population TCM-TF is a tool that can facilitate the flow of 
information.The creation of a working group TCM-TF can help reflect further 
on this very important issue and may facilitate some parts of the world 
whose needs are urgent and solve many of the problems we face. We have a 
great challenge that is to reduce the digital divide by promoting ICT. In 
Africa, the major urban centers are more developed, however, sustainable 
development that affects a large number of people must be in rural 
communities.

Best Regards

Nzengeli Papie
Coordinator
African Forum for the Promotion of the New Information and Communication 
Technologies 
(Forum Africain pour la Promotion des Nouvelles Technologies de 
l'Information et de la Communication) 
Mail : [email-masked] 
Web site : www.fap-ntic.org 
Brazzaville/Republic of Congo

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Aug 2013 10:58:21 -0700

Hi, all,

FWIW, I don't understand why this is being requested of the TRANSPORT area.

Tunnels such as this ought to be the purview of INTAREA. I admit I 
remain confused as to why so many tunneling protocols are in ROUTING, 
but regardless neither is TRANSPORT.

Joe

On 8/1/2013 8:52 PM, [email-masked] wrote:
> TCM-TF which for us is very interesting for developing countries.
>
> For your information, our organization '' *African Forum for the
> Promotion of New Information and Communication **Technologies*'' AFP-ICT
> work to our project : *''TrainingandConnecting Rural People''* (WSIS
> Project Prizes 2013 : E-Learning), which enters its second phase where
> we think the Tunneling, Compressing and Multiplexing Traffic Flow
> (TCM-TF) is interesting and better adapt to the rural areas in general
> and in particular for developing countries because TCMTF, a proposal for
> Optimizing the traffic of real-time services and other flows based on
> small packets. It is based on grouping and compressing traffic flows,
> and it is ble to save 50% or even 60% of the bandwidth for some services.
>
> areas (our workplace for the development of ICT) encompassing a large
> part of the African population TCM-TF is a tool that can facilitate the
> flow of information.
>
> The creation of a working group TCM-TF can help reflect further on this
> very important issue and may facilitate some parts of the world whose
> needs are urgent and solve many of the problems we face. We have a great
> challenge that is to reduce the digital divide by promoting ICT. In
> <https://mail.google.com/mail/h/vrv6evnqlyn1/?&v=b&cs=wh&to=[email-masked]>
>
> Web site :www.fap-ntic.org
> <http://www.google.com/url?q=http%3A%2F%2Fwww.fap-ntic.org&sa=D&sntz=1&usg=AFQjCNGMWp7ho2v7_5WCdRpzeUahCSueEw>
>
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 02 Aug 2013 22:04:42 -0400

> but regardless neither is TRANSPORT.

Hi Joe; here are a few reasons I can think of for justifying
transport as the area:

- the intent was not to invent new tunnel protocols, but to use
  existing ones as part of a stack
- all of the possible downsides that people brought up during
  the meeting are impacts to the transport protocol; so there is
  a tight coupling between transport configuration and what the
  recommendation for performing TCMTF on a flow should be
- many of the design considerations are directly related to things
  transport has dealt with in the past like delayed ACKs, ACK
  compression, buffer sizing, etc.
- PILC and PEP documentation were done in the transport area
- RoHC was done in the transport area
- PMTUD was in transport area (since you noted that this is a
  an additional concern)

In my opinion, if this is done, it should be in transport.

-- 
Wes Eddy
MTI Systems

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 03 Aug 2013 10:36:45 +0200

One reason why I think this *COULD* be a transport issue, is that it may 
not primarily require new tunnel encapsulation methods.

The problem space includes how identify how to find/configure the 
compression tunnel endpoints, how to know whether specific transport 
flows should be placed in a compression tunnel, etc. This could well 
include guidance of what not to do from a transport perspective.

Gorry

---

From: "Jose Saldana" <[email-masked]>
Date: Sat, 3 Aug 2013 10:43:55 +0200

I agree with Wes. The question of the area was discussed one year ago (see
slides 24-26 of this presentation at IETF83:
http://www.ietf.org/proceedings/83/slides/slides-83-tsvwg-0.pdf). There have
been no objections about this point during the last 16 months. The drafts
are in tsvwg. The BOF was organized by the Transport Area, and nobody
objected.

So IMHO, this is clear.

Thanks,

Jose 

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de
Wesley Eddy
Enviado el: sábado, 03 de agosto de 2013 4:05
Para: Joe Touch
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [tcmtf] Support to create the working group for TCM-TF

> but regardless neither is TRANSPORT.

Hi Joe; here are a few reasons I can think of for justifying transport as
the area:

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Aug 2013 10:57:44 -0700

>    recommendation for performing TCMTF on a flow should be

But that's true of most tunneling protocols. We rarely measure downsides 
to network protocols in isolation.

> - PILC and PEP documentation were done in the transport area

PILC and PEP were intended as *interactions* between the link and 
transport.

> - PMTUD was in transport area (since you noted that this is a

Yes, but SEAL was not. And SEAL is a better, more complete tunnel in 
which to develop this sort of mechanism - at which point it's not a 
tunnel mechanism so much as a transport compression.

> In my opinion, if this is done, it should be in transport.

Until the "this" is defined, it's impossible to understand where TCMTF 
belongs.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 05 Aug 2013 14:11:09 -0400

Joe - I think we should let the IESG do their job of determining
if a charter is in scope for a particular area or needs to be
shifted.

I trust that no matter what the area is, the same people who are
interested in doing the work will stick around and get the work
done.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Aug 2013 11:18:40 -0700

> are in tsvwg. The BOF was organized by the Transport Area, and nobody

One area "on the table" during the time of a BOF is whether the area is 
appropriate. It shouldn't be considered a "done deal" until it's a WG.

Further, there's clearly a lot of continuing confusion about what this 
work constitutes.

I'm a bit surprised that nobody else spoke up a year ago in Paris; the 
logic in slide 26 is deeply flawed. By that logic, all tunnels are E2E 
and thus all tunnels belong in transport. Regardless, the list is where 
these discussions should happen, and I didn't see any such discussion 
raised here.

Finally, you really ought to look at SEAL.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Aug 2013 11:24:12 -0700

> if a charter is in scope for a particular area or needs to be

I don't think that should happen without open discussion.

> interested in doing the work will stick around and get the work

Maybe, but historically that's exactly the reason the IESG gives to 
move items to particular areas.

Joe

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 6 Aug 2013 09:53:04 +0200

> Joe Touch
> Enviado el: lunes, 05 de agosto de 2013 20:19
> Para: Jose Saldana
> CC: 'Wesley Eddy'; [email-masked]; [email-masked];
> [email-masked]
> > I agree with Wes. The question of the area was discussed one year ago
> > (see slides 24-26 of this presentation at IETF83:
> > http://www.ietf.org/proceedings/83/slides/slides-83-tsvwg-0.pdf).
> > There have been no objections about this point during the last 16
> > months. The drafts are in tsvwg. The BOF was organized by the
> > Transport Area, and nobody objected.
> 
work
> constitutes.
logic in
> slide 26 is deeply flawed. By that logic, all tunnels are E2E and thus all
tunnels
> belong in transport. Regardless, the list is where these discussions
should
> happen, and I didn't see any such discussion raised here.
> 

All,

First of all, thanks for your feedback.

The idea of TCM-TF is to include different options at each layer (header
compression, multiplexing and tunneling). The tunneling layer currently
considers L2TP, GRE and MPLS. In a first approach, I don't see any problem
on considering other tunneling technologies, as SEAL, if we find them
useful.

Regarding the problem of the Area, this is my summary:

- Since TCM includes protocols from different layers, it is really difficult
to assign it to an area. It involves a number of areas, but in fact it must
belong to one of them. The possibilities were RAI, Internet and Transport.
- We first tried with AVTCore (RAI area) and the answer was "I don't think
this proposal really belongs in the WG, most likely not this area even"
(Magnus W).
- So we had two options: Internet and Transport. We thought Transport could
fit, and we tried there and we were accepted.
- We have been for one year and a half in the Transport Area Working Group,
tsvwg (the first version of the draft was submitted Feb 16 2012,
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/history/).
- So the people who have participated in the discussion are mainly in the
Transport Area.
- One year ago (July 8 2012), a specific tcmtf mailing list was created.
This had an advantage: we could specifically discuss about tcmtf. But it
also had a drawback: only people subscribed to the list have participated in
the discussion. As a consequence, in the BoF, people not subscribed to the
list raised many concerns that had not appeared at all in the discussion
before.

And this is my opinion:

- If we try to change to Internet Area now, we would have to start from
scratch after 1.5 years: explaining everything again to people in that area,
looking for a WG in the Internet Area, talking with the ADs, etc.
- So let's be practical and assume that Transport Area can be a good place
for this. We have even organized a BoF in the Transport Area, and no one had
any concern with that. It has been a long way, so we should not rethink
everything again.
- Of course, let's try to get people from other areas involved. We need
them.

Thanks a lot,

Jose

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Aug 2013 09:33:43 -0700

Hi, Jose,

First, I encourage you to revisit the logic in your slides presented last year regarding your primary rationale (at that time) for being in TSV - i.e., that TCM-TF has endpoint state, and E2E belongs in transport. That's simply incorrect; there are many protocols with state and endpoints, and E2E principles should be applied throughout the IETF.

Second, I encourage you to revise your docs and charter to be more clear about the goals of your work in terms of what you intend to create vs. use/configure, e.g., a tunnel, stateful compression, etc.

Finally, I encourage you to explore SEAL more carefully as a tunnel mechanism. It incorporates most of what we have learned about how NOT to do tunnels, much better than any other IETF or de-facto tunnel mechanism (*especially* GRE, FWIW).

In the future, I sincerely hope that the scope of a BOF will be an active area of discussion at the time new multi-area work is introduced. This is NOT the sole purview of the ADs.

Joe