Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London

From: "Black, David" <[email-masked]>
Date: Fri, 3 Jan 2014 22:04:58 -0500

A second BoF has the explicit goal of forming a WG, as a third BoF
is not permitted.  In that regard, the new charter seems long and
somewhat lacking in focus.  Two key things I look for in a proposed
charter are what problem (or problems) the proposed WG is looking to
solve and an initial approach to the problem or problems.

In the new draft charter, the problem statement appears to be in
paragraph 4 with paragraph 1 providing important background.  The
focus of the work appears to be on extending TCRTP (RFC 4170) to
UDP and to include new compression protocols.  In contrast, I have
a hard time discerning the initial approach from the new draft charter.

In light of this, there are a few things that I wish the new
draft charter had definitive proposals for:

      a) Whether to replace RFC 4170 vs. write a new RFC (could be
            UDP-only or UDP + RTP/UDP) as a complement to RFC 4170.
      b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 ?).
            Non-use of ECRTP would be a major change to 4170, and I
wonder about IPHC, as opposed to the ROHCv2 profiles.
      c) Analogies to b) for the Mux and Tunnel layers of the stack.

Overall, it looks like the first task of the WG is to select the protocol
stack to standardize - I have misgivings about that, and would prefer to
see a concrete proposal in a crisp charter that ran along the following
lines, naming the protocols to be used:

1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z.
2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C.

A specific proposal or proposals for the protocol stack or stacks
would also narrow the scope of item 9 in the charter on the negotiation
mechanism.  I also don't see a goal/milestone listed for an extension to
or replacement for RFC 4170.

I'd prefer to see a much shorter more focused draft charter.  There's a
bunch of background material that does not seem crucial to the charter,
starting w/paragraphs 2 and 3.

Thanks,
--David

From: tsv-area [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 4:26 AM
To: [email-masked]; [email-masked]
Cc: Martin Stiemerling
Subject: TCMTF-Feedback about a possible BoF in London

Hi all,

After the feedback received in the BoF in Berlin, we have updated the TCM-TF charter and the two drafts. We have tried to solve all the problems raised during the session.

Our plan is to request a new BoF in London next March, so we would like to know your opinion about these two questions:

1.  Is the new, reduced scope of TCM-TF suitable to form a working group?

2. We would like to kindly ask people who think that a TCM-TF Working group should be formed, to come forward and send an e-mail to the [email-masked]<mailto:[email-masked]>  mailing list stating it.

This feedback will allow us to get a better idea of the convenience of a BoF.

The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html
This is the old one (presented in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html

In these links you can see the differences between the new versions of the drafts and the old ones:
http://tools.ietf.org/rfcdiff?url1=draft-saldana-tsvwg-tcmtf-06.txt&url2=draft-saldana-tsvwg-tcmtf-05.txt
http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt&url2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt

The main improvements are:

- TCP optimization has been removed
- The classification of the scenarios has been refined and improved. Some of them have been removed
- A section about energy consumption has been added to the main draft
- A reference to the potential problem of the MTU and packet loss has been added
- The problem of the added delays is studied in detail in the second draft

- The improvements of the charter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html

Best regards,

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Sun, 5 Jan 2014 19:47:24 +0100

David,

Thanks for your valuable comments!

I will improve the charter according to your suggestions and release a new
version.

Thanks again,

Jose

De: Black, David [mailto:[email-masked]] 
Enviado el: sábado, 04 de enero de 2014 4:05
Para: Jose Saldana; [email-masked]; [email-masked]
CC: Martin Stiemerling; Black, David
Asunto: RE: TCMTF-Feedback about a possible BoF in London

mechanism.  I also don’t see a goal/milestone listed for an extension to

I’d prefer to see a much shorter more focused draft charter.  There’s a

Thanks,
--David

Hi all,

After the feedback received in the BoF in Berlin, we have updated the TCM-TF
charter and the two drafts. We have tried to solve all the problems raised
during the session.

Our plan is to request a new BoF in London next March, so we would like to
know your opinion about these two questions:

 

2. We would like to kindly ask people who think that a TCM-TF Working group
should be formed, to come forward and send an e-mail to the
[email-masked]  mailing list stating it.

This feedback will allow us to get a better idea of the convenience of a
BoF.

The new charter is here:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html

This is the old one (presented in Berlin):
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html

In these links you can see the differences between the new versions of the
drafts and the old ones:

<http://tools.ietf.org/rfcdiff?url1=draft-saldana-tsvwg-tcmtf-06.txt&url2=dr
aft-saldana-tsvwg-tcmtf-05.txt>
http://tools.ietf.org/rfcdiff?url1=draft-saldana-tsvwg-tcmtf-06.txt&url2=dra
ft-saldana-tsvwg-tcmtf-05.txt

http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt
<http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt&u
rl2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt>
&url2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt

- The classification of the scenarios has been refined and improved. Some of
them have been removed

- A reference to the potential problem of the MTU and packet loss has been
added

- The improvements of the charter are summarized here:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html

Best regards,

Jose

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 6 Jan 2014 11:41:32 +0100

Hi All,

I agree with David that the charter is a bit prolix.

IMHO it can be shortened in the following way:

- Merge abd reduce paragraphs 2 and 3. I think that the main message that the new paragraph should deliver is “RFC4170 does not cover new emerging scenarios”, which will be completed by the current paragraph 4.

- Shorten paragraph 5. The charter should (IMHO) offer a list of sample scenarios where bandwidth saving is desirable but the analysis of such scenarios has to be done elsewhere. In the current form there is too much details. 

- Paragraph 6: I am not sure if we really need to keep such precise figures in a charter. If people prefer to keep the text it should appear earlier on in the charter (in the new second paragraph ???) to provide motivation on using TCM solutions. 

Having said that, I support the formation of the WG.

ciao

Luigi

On 4 Jan. 2014, at 04:04 , Black, David <[email-masked]> wrote:

> 2. We would like to kindly ask people who think that a TCM-TF Working group should be formed, to come forward and send an e-mail to the [email-masked]  mailing list stating it.
>  
>  
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 9 Jan 2014 01:10:48 +0100

Hi all.

First of all, thanks to David and Luigi for their valuable comments.

I will wait for a while in order to include David’s comments (perhaps some
other people has more suggestions).

These are the improvements of version 10 with respect to v9 (
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.html)

- I have shortened paragraph 1.

- I have shortened and merged paragraphs 2 and 3.

- I have moved paragraph 4 to the third place, in order to set clearer what
we want: replacing RFC4170 with a widened proposal. As David suggested, I
have also shortened the text and it is now more straightforward.

- I have clearly stated which protocols will be used on each layer. The
negotiation mechanism is still necessary, since different options are
considered e.g. for header compression. The one to be used will depend on
the scenario and the processing capacity of the two optimizers.

- I have significantly shortened the description of the scenarios.

- I have removed paragraph 6, which included the savings figures.

- I have included the replacement of RFC4170 in the first milestone.

Thanks!

Jose

De: Black, David [ <mailto:[email-masked]> mailto:[email-masked]] 
Enviado el: sábado, 04 de enero de 2014 4:05
Para: Jose Saldana;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]
CC: Martin Stiemerling; Black, David
Asunto: RE: TCMTF-Feedback about a possible BoF in London

Thanks,
--David

From: tsv-area [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 4:26 AM
To:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked]
Cc: Martin Stiemerling
Subject: TCMTF-Feedback about a possible BoF in London

Hi all,

 

 

2. We would like to kindly ask people who think that a TCM-TF Working group
should be formed, to come forward and send an e-mail to the
<mailto:[email-masked]> [email-masked]  mailing list stating it.

The new charter is here:
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html

This is the old one (presented in Berlin):
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html

<http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt&u
rl2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt>
http://tools.ietf.org/rfcdiff?url1=draft-suznjevic-tsvwg-mtd-tcmtf-02.txt&ur
l2=draft-suznjevic-tsvwg-mtd-tcmtf-01.txt

- The improvements of the charter are summarized here:
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html

Best regards,

Jose

---

From: Tina TSOU <[email-masked]>
Date: Thu, 9 Jan 2014 00:49:41 +0000

Dear all,
I'm in favor of having a BoF in London, as the following problem statement seems valid and needs protocol work in IETF.
---
In addition to VoIP, in the last years we are witnessing the raise of new real-time services e.g. 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. 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.

In the moments or places where network capacity gets scarce, allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic (reducing bandwidth and packets per second) when/where required is a one-time investment. We can do these three things:

a) header compression algorithms (e.g. ROHC) can be used for reducing the overhead of each flow;
b) at the same time, tunneling can be used in order to allow the header-compressed packets to travel end-to-end
c) compressed packets belonging to different flows can be multiplexed together, in order to share the tunnel overhead.

These emerging real-time services which use bare UDP instead of UDP/RTP have become popular. In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC). So there is a need of widening the scope of RFC4170 in order to consider these new header compression methods, and also UDP in addition to UDP/RTP.

As a result, the next objectives can be achieved:

* Significant bandwidth reductions (as an example, bandwidth savings of 55% can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For certain online games, 33% of the bandwidth can be saved for IPv4, and 55% when using IPv6).

* A reduction of the amount of packets per second managed by the network. A reduction factor of 10 or 20 can easily be achieved. This can be translated into smaller processing delays and energy savings in intermediate routers.
---

Thank you,
Tina

On Jan 8, 2014, at 4:11 PM, "Jose Saldana" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all.

I will wait for a while in order to include David’s comments (perhaps some other people has more suggestions).

These are the improvements of version 10 with respect to v9 (http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.html)

- I have shortened paragraph 1.
- I have shortened and merged paragraphs 2 and 3.
- I have moved paragraph 4 to the third place, in order to set clearer what we want: replacing RFC4170 with a widened proposal. As David suggested, I have also shortened the text and it is now more straightforward.
- I have clearly stated which protocols will be used on each layer. The negotiation mechanism is still necessary, since different options are considered e.g. for header compression. The one to be used will depend on the scenario and the processing capacity of the two optimizers.
- I have significantly shortened the description of the scenarios.
- I have removed paragraph 6, which included the savings figures.
- I have included the replacement of RFC4170 in the first milestone.

Thanks!

Jose

Para: Jose Saldana; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,
--David

From: tsv-area [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 4:26 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Martin Stiemerling
Subject: TCMTF-Feedback about a possible BoF in London

Hi all,

Best regards,

Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 09 Jan 2014 17:49:59 +0000

Hi all,

Just to say that I also completely support the creation of the WG. There is no doubt that network protocols have evolved, and not always as we thought, and TCRTP needs to be wider.

Regards,
Fernando

On 09/01/2014, at 01:49, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Thank you,
Tina

Hi all.

Thanks!

Jose

Thanks,
--David

Hi all,

Best regards,

Jose

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

________________________________

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: Wesley Eddy <[email-masked]>
Date: Thu, 09 Jan 2014 13:03:42 -0500

On 1/8/2014 7:49 PM, Tina TSOU wrote:
> Dear all,
> I'm in favor of having a BoF in London, as the following problem
> statement seems valid and needs protocol work in IETF.
> ...

I'm in agreement as well.  Parts of the problem statement and the
scope of the work might still be tweakable, but I think that
overall there is important work for the IETF to do in this area.

Due to the things Tina described very well, there will be (and are)
products available that attempt to optimize traffic in poorly
documented and often poorly conceived ways.  These can do more harm
and have other mysterious effects on traffic than whatever this
working group would create, since it would provide open specifications
that could be developed and tested against the concerns of relevant
layers and other IETF protocols, and problems and concerns could be
addressed.

If there are people willing to write the specs *and* people are
also able to express interest in writing/deploying/selling code and
products that use those specs, then we should certainly be doing
this work in the IETF.

This will allow:
- multiple vendor boxes to interoperate on different sides of a
  challenged network/link (currently this is beyond the state of
  the art!)
- simplified/standardized management of such boxes
- well-understood behavior profiles of such middleboxes and their
  protocols algorithms

If the IETF does not do this work, then I don't believe any of those
three benefits/results are likely at all, and the (poor) status quo
will continue.

-- 
Wes Eddy
MTI Systems

---

From: "Mehmet Karaca (Alumni)" <[email-masked]>
Date: Thu, 23 Jan 2014 17:05:37 +0200

Dear All,

I completely support the formation of the WG for TCMMF.  I believe that
such protocols in TCMMF will be also  beneficial from  MAC layer point of
view since whenever QoS is required and traffic is not tagged at MAC layer
(in cases where 802.11e is not supported or traffic is not tagged at the
source), traffic classification at  higher layer (Layer 3 or above) will be
very crucial for some level of  QoS at MAC layer.

Best Regards and  thanks!

Mehmet.

On Thu, Jan 9, 2014 at 7:49 PM, FERNANDO PASCUAL BLANCO <[email-masked]> wrote:

>  Hi all,
>
>  Just to say that I also completely support the creation of the WG. There
> is no doubt that network protocols have evolved, and not always as we
> thought, and TCRTP needs to be wider.
>
> Regards,
> Fernando
>
>
>  On 09/01/2014, at 01:49, Tina TSOU <[email-masked]> wrote:
>
>  Dear all,
> I'm in favor of having a BoF in London, as the following problem statement
> seems valid and needs protocol work in IETF.
> ---
>  In addition to VoIP, in the last years we are witnessing the raise of
> new real-time services e.g. 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. 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.
>
>
>  In the moments or places where network capacity gets scarce, allocating
> more bandwidth is a possible solution, but it implies a recurring cost.
> However, the inclusion of a pair of boxes able to optimize the traffic
> (reducing bandwidth and packets per second) when/where required is a
> one-time investment. We can do these three things:
>
>
>  b) at the same time, tunneling can be used in order to allow the
> header-compressed packets to travel end-to-end
>  c) compressed packets belonging to different flows can be multiplexed
> together, in order to share the tunnel overhead.
>
>
>  These emerging real-time services which use bare UDP instead of UDP/RTP
> have become popular. In addition, a significant effort has been devoted
> to the deployment of new header compression methods with improved
> robustness (ROHC). So there is a need of widening the scope of RFC4170 in
> order to consider these new header compression methods, and also UDP in
> addition to UDP/RTP.
>
>
>  * Significant bandwidth reductions (as an example, bandwidth savings of
> 55% can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For
> certain online games, 33% of the bandwidth can be saved for IPv4, and 55%
> when using IPv6).
>
>
>  * A reduction of the amount of packets per second managed by the
> network. A reduction factor of 10 or 20 can easily be achieved. This can be
> translated into smaller processing delays and energy savings in
> intermediate routers.
>  ---
>
>  Thank you,
> Tina
>
> On Jan 8, 2014, at 4:11 PM, "Jose Saldana" <[email-masked]> wrote:
>
>   Hi all.
>
>  - I have moved paragraph 4 to the third place, in order to set clearer
> what we want: replacing RFC4170 with a widened proposal. As David
> suggested, I have also shortened the text and it is now more
> straightforward.
>   *De:* Black, David [mailto:[email-masked] <[email-masked]>]
> *Enviado el:* sábado, 04 de enero de 2014 4:05
> *Para:* Jose Saldana; [email-masked]; [email-masked]
> *CC:* Martin Stiemerling; Black, David
> *Asunto:* RE: TCMTF-Feedback about a possible BoF in London
>
>   *From:* tsv-area [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Jose Saldana
> *Sent:* Friday, December 20, 2013 4:26 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* Martin Stiemerling
> *Subject:* TCMTF-Feedback about a possible BoF in London
>
>  Hi all,
>
>  After the feedback received in the BoF in Berlin, we have updated the
> TCM-TF charter and the two drafts. We have tried to solve all the problems
> raised during the session.
>
>  Our plan is to request a new BoF in London next March, so we would like
> to know your opinion about these two questions:
>
>
>  2. We would like to kindly ask people who think that a TCM-TF Working
> group should be formed, to come forward and send an e-mail to the
> ------------------------------
>
> 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:

---

From: Ece Gelal <[email-masked]>
Date: Thu, 23 Jan 2014 19:33:49 +0200

*>> If there are people willing to write the specs *and* people are also
able to express interest in writing/deploying/selling code and products
that use those specs, then we should certainly be doingthis work in the
IETF.*

To follow up on Wesley's comment above, as AirTies we *are* interested in
writing/deploying code and selling products including this code. We believe
that significant performance improvements in the home network can be
achieved by multiplexing small-payload packets into a greater one. In
particular in the wireless environment where nodes contend for channel
access, even multiplexing two packets reduces the effort for accessing the
channel by half. We think that any company that is focused on improving the
Wi-Fi performance for various applications would be excited about TCM-TF.

Regards,
Ece

-- 

Ece Gelal, PhD

Product Manager

AirTies Wireless Networks (www.airties.com)

M: +90 (533) 431 2773

E: [email-masked]

Information in this email including any attachments may be privileged,
confidential and is intended exclusively for the addressee. The views
expressed may not be official policy, but the personal views of the
originator. If you have received it in error, please notify the sender by
return e-mail and delete it from your system. You should not reproduce,
distribute, store, retransmit, use or disclose its contents to anyone.

-- 

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views 
expressed may not be official policy, but the personal views of the 
originator. If you have received it in error, please notify the sender by 
return e-mail and delete it from your system. You should not reproduce, 
distribute, store, retransmit, use or disclose its contents to anyone.