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

[Brian Trammell <[e-mail]>]

Greetings, all,

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

A couple of points, inline...

On 12 Mar 2014, at 09:23, Jose Saldana <[e-mail]> wrote:

> 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:[e-mail]] En nombre de Brian Trammell
>> Enviado el: miércoles, 05 de marzo de 2014 14:51
>> Para: [e-mail]
>> 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:
>> 
>> (1) make it clear that backward compatibility with RFC 4170 is a goal.
> 
> 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

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>

>> This should address interactions between
>>    TCMTF tunnels and TCP cross traffic sharing a bottleneck link.
> 
> 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.

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.

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

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

Cheers,

Brian