Re: [tcmtf] BoF feedback

> -----Mensaje original-----
> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de
> Spencer Dawkins
> Enviado el: lunes, 05 de agosto de 2013 22:24
> Para: Wesley Eddy
> CC: Luigi Iannone; gorry@erg.abdn.ac.uk; Spencer Dawkins; tcmtf@ietf.org
> Asunto: Re: [tcmtf] BoF feedback
> 
> On 8/5/2013 1:15 PM, Wesley Eddy wrote:
> > On 8/5/2013 2:02 PM, Spencer Dawkins wrote:
> >> 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?
> >>
> >
> > 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.
> 
> 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

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

> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf