Subject: [tcmtf] BoF feedback

From: Luigi Iannone <[email-masked]>
Date: Fri, 2 Aug 2013 06:34:54 -0400

Hi,

I was thinking a little bit about the turn the BoF took yesterday, going a bit off topic IMHO.

At a certain point people were going to the mic to explain yet another scenario where TCMTF would not work or is not useful.

It is obvious to me that such scenarios exist, but  the goal of TCMTF is not to provide something that will be applied to all packets under a certain size.  

It is also obvious to me that scenarios where TCMTF is beneficial exist as well. Goal of TCMTF should be to provide the right mechanism for those scenarios.

A key point to discuss in TCMTF is how we identify and select the flow we want to be multiplexed on a single compressed tunnel.

All of this to say that we should not focus or scenarios where TCMTF doesn't help but rather to answer the following question:

Are there scenarios and use cases where TCMTF provides benefits?

The answer IMHO is YES so some work should be done.

Just let me add that,  before thinking how to encapsulate we should answer: How do we select the flows we want to encamp? 

So that we are sure that we do not touch traffic that will suffer because of TCMTF.

Just my thoughts after the BoF.

ciao

Luigi

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Aug 2013 11:00:13 -0700

FWIW, I'd like to see how/whether this can be cast as an extension to SEAL.

It'd be useful not to have to reinvent the many wheel-like parts of this 
that could leverage existing tunneling capabilities.

Joe

On 8/2/2013 3:34 AM, Luigi Iannone wrote:
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 2 Aug 2013 20:25:02 +0000

TCMTF has clear and demonstrated benefits for VoIP and online gaming. CRTP/ECRTP has already enjoyed some success in reducing VoIP bandwidth over point-to-point WAN links, especially in those regions where access bandwidth is considerably expensive. TCMFT is a natural extension that encompasses better compression and tunneling technologies to achieve similar goals. 

The concerns raised during the BoF seemed in relation to generalizing it for other kinds of traffic and TCP in particular. This generalization though important (especially in the context of Internet of Things as echoed by Michael Ramalho during the BoF) could probably be deferred for future work (TCMTF2.0?) and the scope limited to VoIP and online gaming to begin with, IMO. As we work through the limited scope, how (and how not) to apply it for other kinds of traffic should become more clear, I think.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Luigi Iannone
|Sent: Friday, August 02, 2013 4:05 PM
|To: [email-masked]
|Subject: [tcmtf] BoF feedback
|
|Hi,
|
|I was thinking a little bit about the turn the BoF took yesterday, going a bit off topic IMHO.
|
|At a certain point people were going to the mic to explain yet another scenario where TCMTF would not
|work or is not useful.
|
|It is obvious to me that such scenarios exist, but  the goal of TCMTF is not to provide something that
|will be applied to all packets under a certain size.
|
|It is also obvious to me that scenarios where TCMTF is beneficial exist as well. Goal of TCMTF should
|be to provide the right mechanism for those scenarios.
|
|A key point to discuss in TCMTF is how we identify and select the flow we want to be multiplexed on a
|single compressed tunnel.
|
|All of this to say that we should not focus or scenarios where TCMTF doesn't help but rather to answer
|the following question:
|
|Are there scenarios and use cases where TCMTF provides benefits?
|
|The answer IMHO is YES so some work should be done.
|
|Just let me add that,  before thinking how to encapsulate we should answer: How do we select the flows
|we want to encamp?
|
|So that we are sure that we do not touch traffic that will suffer because of TCMTF.
|
|Just my thoughts after the BoF.
|
|ciao
|
|Luigi
|
|
|_______________________________________________
|tcmtf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/tcmtf

---

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

Muthu, Luigi,

Perhaps you are right. The inclusion of the TCP branch of the protocol
raised many objections. But perhaps if we remove that branch (or leave it
for further study), we can carry on with RTP/UDP/IP and UDP/IP flows. In
fact, RTP/UDP/IP is already a standard (RFC4170, 2005) and nobody objected.
At least we should replace ECRTP with ROHC in RFC4170.

Another option would be to create a specific document about the things to
take into account when multiplexing TCP flows. Or perhaps this could be
included in the "TCM-TF recommendations" draft.

Thanks,

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de
Muthu Arul Mozhi Perumal (mperumal)
Enviado el: viernes, 02 de agosto de 2013 22:25
Para: Luigi Iannone; [email-masked]
Asunto: Re: [tcmtf] BoF feedback

TCMTF has clear and demonstrated benefits for VoIP and online gaming.
CRTP/ECRTP has already enjoyed some success in reducing VoIP bandwidth over
point-to-point WAN links, especially in those regions where access bandwidth
is considerably expensive. TCMFT is a natural extension that encompasses
better compression and tunneling technologies to achieve similar goals. 

The concerns raised during the BoF seemed in relation to generalizing it for
other kinds of traffic and TCP in particular. This generalization though
important (especially in the context of Internet of Things as echoed by
Michael Ramalho during the BoF) could probably be deferred for future work
(TCMTF2.0?) and the scope limited to VoIP and online gaming to begin with,
IMO. As we work through the limited scope, how (and how not) to apply it for
other kinds of traffic should become more clear, I think.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf 
|Of Luigi Iannone
|Sent: Friday, August 02, 2013 4:05 PM
|To: [email-masked]
|Subject: [tcmtf] BoF feedback
|
|Hi,
|
|I was thinking a little bit about the turn the BoF took yesterday, going a
bit off topic IMHO.
|
|At a certain point people were going to the mic to explain yet another 
|scenario where TCMTF would not work or is not useful.
|
|It is obvious to me that such scenarios exist, but  the goal of TCMTF 
|is not to provide something that will be applied to all packets under a
certain size.
|
|It is also obvious to me that scenarios where TCMTF is beneficial exist 
|as well. Goal of TCMTF should be to provide the right mechanism for those
scenarios.
|
|A key point to discuss in TCMTF is how we identify and select the flow 
|we want to be multiplexed on a single compressed tunnel.
|
|All of this to say that we should not focus or scenarios where TCMTF 
|doesn't help but rather to answer the following question:
|
|Are there scenarios and use cases where TCMTF provides benefits?
|
|The answer IMHO is YES so some work should be done.
|
|Just let me add that,  before thinking how to encapsulate we should 
|answer: How do we select the flows we want to encamp?
|
|So that we are sure that we do not touch traffic that will suffer because
of TCMTF.
|
|Just my thoughts after the BoF.
|
|ciao
|
|Luigi
|
|
|_______________________________________________
|tcmtf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/tcmtf
_______________________________________________
tcmtf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 03 Aug 2013 11:11:51 +0200

Indeed, I suspect a separate draft on TCP/SCTP would be helpful. There 
are separate issues that emerge if this is important to consider.

A separate draft could help capture the key issues, present experience 
of using this, results from implementation, etc. RFC 3449 already gives 
some guidance on compression methods for TCP return streams, especially 
the "compaction" approach, and section 5.3.3 hints at the problem of 
forming bursts of TCP segments.

A separate document would also help divide the problem into activities 
where expertise can be focused.

Gorry

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 5 Aug 2013 15:28:21 +0200

Hi,

I also support the creation of a different document for TCP/SCTP. 

As Gorry points out, this would help  to separate the issues. I think that on this side there is much more work to do in understanding where and how TCMTF can be applied.

Work on RTP/UDP/IP can advance faster since there are already clear scenarios.

I would also re-iterate my point of view. To be blunt I do not believe in a "generalised" use of TCMTF, yet I believe that there are strong benefits (already demonstrated) in various scenarios. So, IMHO, TCMTF should provide the community with the right set of tools to take advantage of those benefits.

ciao

Luigi

On 3 Aug. 2013, at 11:11 , Gorry Fairhurst <[email-masked]> wrote:

> Indeed, I suspect a separate draft on TCP/SCTP would be helpful. There are separate issues that emerge if this is important to consider.
> 
> A separate draft could help capture the key issues, present experience of using this, results from implementation, etc. RFC 3449 already gives some guidance on compression methods for TCP return streams, especially the "compaction" approach, and section 5.3.3 hints at the problem of forming bursts of TCP segments.
> 
> A separate document would also help divide the problem into activities where expertise can be focused.
> 
> Gorry
> 
>

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 05 Aug 2013 13:02:16 -0500

Way down in the thread ...

>>> included in the "TCM-TF recommendations" draft.

So, Martin and I were talking this morning, and a question came up that 
you folks might want to ponder, if you haven't already done so ...

Re: UDP/IP flows, the theory here would be to say that UDP/IP flows are 
more like RTP flows than TCP flows, so the concerns about TCP in TCM-TF 
don't apply, but the nice people in RTCWeb are defining their data 
channel over SCTP/DTLS/UDP, and my guess would be that their data 
channel would behave exactly like TCP for bulk transfers.

Have people already considered that?

Thanks,

Spencer

---

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

> Have people already considered that?

I think the answer is that instead of searching for particular
protocol layerings that could be harmed, the rules for invoking
TCMTF on a flow would be such that it only operates on things
that it is configured to (e.g. UDP to a game server IP and port),
and that it would "fail off" and not do anything for types of
flows that it isn't sure how to optimize, time release for, or
otherwise not break.

That should be the answer for TCP, UDP, SCTP, DCCP, SCTP over UDP,
etc etc etc.

-- 
Wes Eddy
MTI Systems

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 05 Aug 2013 15:23:53 -0500

> flows that it isn't sure how to optimize, time release for, or

Right. That might not have been clear, but that matches what I was 
thinking - opt-in.

So I think my next question if if people expect the spec to give 
guidance about how to decide what gets configured "in".

Thanks,

Spencer

---

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

My opinion...

> Spencer Dawkins
> Enviado el: lunes, 05 de agosto de 2013 20:02
> Para: Luigi Iannone
> CC: [email-masked]; [email-masked]
> > As Gorry points out, this would help  to separate the issues. I think
that on
> this side there is much more work to do in understanding where and how
> TCMTF can be applied.
> >
> > I would also re-iterate my point of view. To be blunt I do not believe
in a
> "generalised" use of TCMTF, yet I believe that there are strong benefits
> (already demonstrated) in various scenarios. So, IMHO, TCMTF should
> provide the community with the right set of tools to take advantage of
those
> benefits.
of
> using this, results from implementation, etc. RFC 3449 already gives some
> guidance on compression methods for TCP return streams, especially the
> "compaction" approach, and section 5.3.3 hints at the problem of forming
> bursts of TCP segments.
> >>
> >>> Perhaps you are right. The inclusion of the TCP branch of the
> >>> protocol raised many objections. But perhaps if we remove that
> >>> branch (or leave it for further study), we can carry on with
> >>> RTP/UDP/IP and UDP/IP flows. In fact, RTP/UDP/IP is already a standard
> (RFC4170, 2005) and nobody objected.
> >>> Another option would be to create a specific document about the
> >>> things to take into account when multiplexing TCP flows. Or perhaps
> >>> this could be included in the "TCM-TF recommendations" draft.
> 
you
> folks might want to ponder, if you haven't already done so ...
> 
> don't apply, but the nice people in RTCWeb are defining their data channel
> over SCTP/DTLS/UDP, and my guess would be that their data channel would
> behave exactly like TCP for bulk transfers.
> 

The UDP/IP flows we are considering are not (in general) RTCWeb, since they
do not end in a web browser, but in a specific application (e.g. a game
client, a sample of a M2M metering application). Dan and Muthu are also very
active with RTCWeb, so I would like to hear their opinion about this.

Thanks!

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 6 Aug 2013 10:00:59 +0200

> Enviado el: lunes, 05 de agosto de 2013 22:24
> Para: Wesley Eddy
> CC: Luigi Iannone; [email-masked]; Spencer Dawkins; [email-masked]
> >> So, Martin and I were talking this morning, and a question came up
> >> that you folks might want to ponder, if you haven't already done so ...
> >>
> >> Re: UDP/IP flows, the theory here would be to say that UDP/IP flows
> >> are more like RTP flows than TCP flows, so the concerns about TCP in
> >> TCM-TF don't apply, but the nice people in RTCWeb are defining their
> >> data channel over SCTP/DTLS/UDP, and my guess would be that their
> >> data channel would behave exactly like TCP for bulk transfers.
> >>
> > protocol layerings that could be harmed, the rules for invoking TCMTF
> > on a flow would be such that it only operates on things that it is
> > configured to (e.g. UDP to a game server IP and port), and that it
> > would "fail off" and not do anything for types of flows that it isn't
> > sure how to optimize, time release for, or otherwise not break.
> 
thinking -
> opt-in.
> 
> So I think my next question if if people expect the spec to give guidance
> about how to decide what gets configured "in".
> 
> Thanks,
> 
> Spencer

If you look at the abstract of the "Recommendations draft"
(http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/) , this is
exactly what we intend to do in that document:

   This document contains recommendations to be taken into account when
   using methods which optimize bandwidth utilization through
   compression, multiplexing, and tunneling traffic flows (TCMTF) over a
   network path.  Different multiplexing policies and implementation
   issues which are service and link specific are discussed.
   Additionally, this document describes *policies which can be used for
   detecting, classifying, and choosing the network flows suitable for
   optimization by using TCMTF*.  Finally, recommendations of maximum
   tolerable delays to be added by optimization techniques are reported.
   Recommendations are presented only for network services for which
   such bandwidth optimization techniques are applicable (i.e., services
   with low payload to header size ratio, which will also be denoted as
   "small-packet flows").

Spencer, are you talking about the "policies which can be used for
detecting, classifying, and choosing the network flows suitable for
optimization by using TCMTF"?

Perhaps this was not clear enough in the BoF, but of course this is very
important: you can only use TCM-TF for the TCM-suitable flows, and this spec
must clearly define which flows are TCM-suitable and in what conditions.

Thanks,

Jose

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 06 Aug 2013 07:26:38 -0500

> optimization by using TCMTF"?

I think so. And it's possible that a word choice is confusing me. 
"detecting" sounded pretty on-the-fly/dynamic to me (as in, you might 
detect that any random packet going past would be a packet that TCM-TF 
would process), but my understanding of recent e-mails is that 
"detecting" is much less dynamic ("I want to use TCMTF on WoW, and 
here's how you would know a packet is a WoW packet, and anything I 
didn't say how to recognize as a packet that TCM-TF should process is 
forwarded with no changes").

If my understanding based on these recent e-mails is more in line with 
what you're thinking, that answers my question.

Thanks!

Spencer