Re: [tcmtf] BoF feedback

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

My opinion...

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> Spencer Dawkins
> Enviado el: lunes, 05 de agosto de 2013 20:02
> Para: Luigi Iannone
> CC: [e-mail]; [e-mail]
> Asunto: Re: [tcmtf] BoF feedback
> 
> Way down in the thread ...
> 
> On 8/5/2013 8:28 AM, Luigi Iannone wrote:
> > 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 <[e-mail]> 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
> >>
> >>
> >> On 03/08/2013 10:52, Jose Saldana wrote:
> >>> 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.
> 
> 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
>

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