Subject: [tcmtf] Thank you for a great BoF!

From: Brian Trammell <[email-masked]>
Date: Wed, 5 Mar 2014 13:51:11 +0000

Greetings, all,

Thanks to everyone for yesterday's BoF. We got lots of good input, and a better handle on what a future TCMTF WG might look like.

There are a few issues we identified that we'll have to take into consideration for a new draft of the charter:

(1) make it clear that backward compatibility with RFC 4170 is a goal.

(2) an applicability statement, which explains applications that benefit from 
    TCMTF and the situations for which it is likely useful, and applications 
    and situations for which it is not. This should address interactions between 
    TCMTF tunnels and TCP cross traffic sharing a bottleneck link.

(3) interactions with how this interacts with diverse lower layers, especially
    with respect to different delay tolerances, will have to be considered.

And we'd really more input from vendors already building boxes in this space, and operators deploying them, as input to scoping and applicability.

Best regards,

Mirja and Brian (second TCMTF BoF chairs)

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 12 Mar 2014 09:23:18 +0100

Hi, Martin,

According to the summary of Brian and Mirja, there are three potential
improvements for the TCM-TF charter draft. I have added some comments below.

Should we prepare a new version of the charter?

> -----Mensaje original-----
> De: tcmtf [mailto:[email-masked]] En nombre de Brian Trammell
> Enviado el: miércoles, 05 de marzo de 2014 14:51
> Para: [email-masked]
> Asunto: [tcmtf] Thank you for a great BoF!
> 
> Greetings, all,
> 
> Thanks to everyone for yesterday's BoF. We got lots of good input, and a
> better handle on what a future TCMTF WG might look like.
> 
> There are a few issues we identified that we'll have to take into
> consideration for a new draft of the charter:
> 

I think there is no problem with maintaining backwards compatibility. I sent
some suggestions for improving the charter:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html

>     and situations for which it is not.

The current n.4 of the charter is about this
(http://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html) Should we
improve it?:

4. New scenarios where bandwidth savings are desirable have been identified,
in addition to those considered in RFC4170. In these scenarios, there are
moments or places where network capacity gets scarce, so 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 when/where
required is a one-time investment. These scenarios can be classified into:

* Multidomain, the TCMT-TF tunnel goes all the way from one network edge to
another, and can therefore cross several domains.
* Single Domain, TCM-TF is only activated inside an ISP, from the edge to
border inside the network operator.
* Private Solutions. TCM-TF is used to connect private networks
geographically apart (e.g. corporation headquarters and subsidiaries),
without the ISP being aware or having to manage those flows.
* Mixed Scenarios, any combination of the previous ones.

> This should address interactions between

This should have to be added to the charter, but I don't clearly understand
what is this problem about. If we compress UDP flows, then we have more
bandwidth for TCP flows sharing the bottleneck. Where is the problem?
Perhaps I missed something in the discussion.

>     with respect to different delay tolerances, will have to be
considered.

Is this covered by n.7? Perhaps some sentences could be added:

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

> And we'd really more input from vendors already building boxes in this
> space, and operators deploying them, as input to scoping and
applicability.
We have some messages in the list:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00490.html
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00497.html
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00491.html
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html

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

Thanks a lot,

Jose

---

From: Brian Trammell <[email-masked]>
Date: Wed, 12 Mar 2014 09:59:53 +0100

Greetings, all,

(as individual contributor, BoF chair hat off since, indeed, the BoF is over. :) )

A couple of points, inline...

> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html

While it was _somewhat_ clear that backward compatibility was desired, it wasn't explicit in the charter, and some people found that confusing. Simply making it explicit (i.e., ensuring the phrase "backward compatible with 4170" appears in the charter text) fixes this problem.

<snip>

> Perhaps I missed something in the discussion.

If you're compressing UDP flows to get them out of the way of concurrent TCP traffic, this is what you want. It's a problem if the reason you're doing UDP header compression is to get more bandwidth for UDP flows, or to reduce losses on the UDP flows on a congested link, since concurrent TCP traffic will always use all the bandwidth it can while inducing packet loss (necessary for the operation of loss-based congestion control) on all flows sharing the bottleneck link.

This is a key point to account for when running TCP and TCM across the same bottleneck link: congestion control will induce loss, implying that any header compression scheme in such a scenario will have to be relatively loss tolerant. I'm not really up on the details of the compression technologies proposed, but we'll have to have a good understanding of the packet loss amplification properties thereof. RFC 3545 seems to imply that ECRTP is relatively loss and reordering tolerant. ROHC is rather a complicated specification so a five-minute analysis of its loss tolerance is not really possible, but I presume they thought of it. A quick read of RFC 2057 section 3.3 seems to imply that IPHC can amplify loss with high rates of context change, but I have no idea how this actually works or does not work in practice. The point is that the point will have to be addressed, either by ensuring that all header compression is relatively loss tolerant for common CC-induced loss rates, or by using lower-layer tricks to segregate TCM from TCP traffic.

This is definitely content for the applicability statement, and the ability to meet these goals for a given use case should be a criteria for determining whether or not that use case is in or out of scope for TCMTF.

> http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html

Indications of interest are great. Contributions to eventual documents are even better. :)

Cheers,

Brian

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 13 Mar 2014 12:03:35 +0100

Thanks, Brian!

I will send a new charter in five minutes including these things:
modifications in n. 3, 5 and milestones; a new n.8.

Comments inline.

> Enviado el: miércoles, 12 de marzo de 2014 10:00
> Para: Jose Saldana
> CC: [email-masked]; Martin Stiemerling; Spencer Dawkins
> Asunto: Re: [tcmtf] Thank you for a great BoF!
> 
> Greetings, all,
> 
> (as individual contributor, BoF chair hat off since, indeed, the BoF is
over. :)
> )
> >> Thanks to everyone for yesterday's BoF. We got lots of good input,
> >> and a better handle on what a future TCMTF WG might look like.
> >>
> > I think there is no problem with maintaining backwards compatibility.
> > I sent some suggestions for improving the charter:
> While it was _somewhat_ clear that backward compatibility was desired, it
> wasn't explicit in the charter, and some people found that confusing.
Simply
> making it explicit (i.e., ensuring the phrase "backward compatible with
> 4170" appears in the charter text) fixes this problem.
> 
> <snip>

I have modified points 3, 5 and milestones so as to maintain backwards
compatibility with RFC4170.

> > This should have to be added to the charter, but I don't clearly
> > understand what is this problem about. If we compress UDP flows, then
> > we have more bandwidth for TCP flows sharing the bottleneck. Where is
> the problem?
> If you're compressing UDP flows to get them out of the way of concurrent
> TCP traffic, this is what you want. It's a problem if the reason you're
doing
> UDP header compression is to get more bandwidth for UDP flows, or to
> reduce losses on the UDP flows on a congested link, since concurrent TCP
> traffic will always use all the bandwidth it can while inducing packet
loss
> (necessary for the operation of loss-based congestion control) on all
flows
> sharing the bottleneck link.
> 
> This is a key point to account for when running TCP and TCM across the
same
> bottleneck link: congestion control will induce loss, implying that any
> header compression scheme in such a scenario will have to be relatively
> loss tolerant. I'm not really up on the details of the compression
> technologies proposed, but we'll have to have a good understanding of the
> packet loss amplification properties thereof. RFC 3545 seems to imply that
> ECRTP is relatively loss and reordering tolerant. ROHC is rather a
> complicated specification so a five-minute analysis of its loss tolerance
is
> not really possible, but I presume they thought of it. A quick read of RFC
> 2057 section 3.3 seems to imply that IPHC can amplify loss with high rates
of
> context change, but I have no idea how this actually works or does not
work
> in practice. The point is that the point will have to be addressed, either
by
> ensuring that all header compression is relatively loss tolerant for
common
> CC-induced loss rates, or by using lower-layer tricks to segregate TCM
from
> TCP traffic.

The objective of ROHC was to build a "robust" header compression mechanism,
i.e. robust against context desynchronization. So the main idea is that it
can work over lossy links, much better than older header compression
mechanisms (ECRTP, IPHC). So we could perhaps suggest that the loss rate has
to be taken into account during the negotiation of the header compression
protocol to be used. I mean:

- If we are considering a congested link, or a wireless link, ROHC can be
the best choice.
- If the link is not too congested, or it is wired (very low packet loss
rate), other options can be considered, since they present less
computational requirements.

We could add this text to the charter. Something like this:

8. The TCM-TF – recommendations document will also provide information about
the best suited header compression protocol for each scenario. When traffic
is being compressed over a lossy link (wireless, high amount of background
traffic, etc.), an algorithm with better robustness against context
desynchronization (i.e. ROHC) will be desirable; however, if compression is
being deployed in a link presenting a low packet loss rate (dedicated links,
wired scenarios), simpler algorithms (i.e. IPHC, ECRTP) can be used, since
they present less processing requirements.

> 
> This is definitely content for the applicability statement, and the
ability to
> meet these goals for a given use case should be a criteria for determining
> whether or not that use case is in or out of scope for TCMTF.
> 
> >> And we'd really more input from vendors already building boxes in
> >> this space, and operators deploying them, as input to scoping and
> > applicability.
> >>

Cheers,

Jose