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

["Jose Saldana" <[e-mail]>]

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.

> -----Mensaje original-----
> De: tcmtf [mailto:[e-mail]] En nombre de Brian Trammell
> Enviado el: miércoles, 12 de marzo de 2014 10:00
> Para: Jose Saldana
> CC: [e-mail]; 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. :)
> )
> 
> 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>

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

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

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

Cheers,

Jose