[tcmtf] TCMTF: A minor improvement for the charter proposal

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

Hi all,

Related to the ideas discussed in the thread below, we could say this in the
draft: after the approval of RFC4170 in 2005, new header compression schemes
have been proposed and standardized. So we should also stress the
convenience of updating RFC4170 in order to consider not only ECRTP (RFC
3545, July 2003) but also ROHC (RFC 5795, March 2010).

Perhaps we could slightly modify this paragraph of the charter proposal:

Current version:

4. However, in the last years, emerging real-time services which do not use
UDP/RTP have 
become popular: some of them use UDP or even TCP. So there is a need of
widening the 
scope of RFC4170 in order to consider not only UDP/RTP but also other
protocols. The same 
structure of three layers will be considered:
(...)


New proposal:

4. However, in the last years, emerging real-time services which do not use
UDP/RTP have 
become popular: some of them use UDP or even TCP. *In addition, new header
compression
methods have been defined (ROHC)*. So there is a need of widening the scope
of RFC4170
in order to consider not only UDP/RTP but also other protocols. The same
structure of three
layers will be considered:
(...)


What do you think? Thanks,

Jose

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> Jose Saldana
> Enviado el: lunes, 20 de mayo de 2013 13:18
> Para: 'Diego R. Lopez'
> CC: [e-mail]
> Asunto: Re: [tcmtf] BoF proposal for Berlin. Showing the interest of the
> Industry
> 
> RFC4170 only considers ECRTP for header compression, which is older than
> ROHC. In that sense, RFC4170 needed an update from the moment ROHC
> was released.
> 
> In addition, as long as the plan is "including" RFC4170 as one of the
> "branches" of TCMTF, I suppose it would be obsoleted.
> 
> But I don't think we would have to rewrite it. If TCMTF includes it as an
> option, do we need a specific document for multiplexing RTP VoIP flows?
> 
> Jose
> 
> > -----Mensaje original-----
> > De: Diego R. Lopez [mailto:[e-mail]] Enviado el: lunes, 20 de mayo
> > de 2013 13:08
> > Para: <[e-mail]>
> > CC: <[e-mail]>
> > Asunto: Re: [tcmtf] BoF proposal for Berlin. Showing the interest of
> > the Industry
> >
> > Hi Jose,
> >
> > So this would imply to review or obsolete RFC4170? An additional
> > document to the list, isn't it?
> >
> > Be goode,
> >
> > On 20 May 2013, at 12:01 , Jose Saldana wrote:
> >
> > > Another idea we should include in the first presentation (why do we
> > > need to standardize TCMTF) is this:
> > >
> > > - A standard already exists (RFC4170), written by three people from
> > > Cisco in 2005.
> > >
> > > - However, this standard only considers a single option at each layer:
> > >       - ECRTP for header compression, so only services based on RTP
> > > are considered
> > >       - PPPMux for multiplexing
> > >       - L2TP for tunneling
> > >
> > > - From 2005 to now:
> > >       - a significant effort has been devoted in the IETF for
> > > standardizing ROHC (which performs better than ECRTP in many
> scenarios)
> > >       - a lot of applications generating long-term flows with high
> > > rates of non-RTP small packets have emerged
> > >
> > > - So why not widening TCRTP's scope in order to:
> > >       - Allow other traffics different from RTP
> > >       - Allow these new developed header compression techniques
> > >
> > > Do you find this coherent?
> > >
> > > Jose
> > >
> > >> -----Mensaje original-----
> > >> De: [e-mail] [mailto:[e-mail]] Enviado el:
> > >> miércoles, 15 de mayo de 2013 11:10
> > >> Para: [e-mail]
> > >> CC: "'Mirko Su¾njeviæ'"; [e-mail]
> > >> Asunto: Re: [tcmtf] BoF proposal for Berlin. Possible scheme
> > >>
> > >> My guess is that many people at the IETF would "like" to see people
> > >> say
> > > they
> > >> plan to implement for a product, or that they plan to devote
> > >> significant
> > > effort
> > >> to seeing the standard matches their need for a particular use case
> (e.g.
> > >> operators or equipment vendors). This can be a strong indication
> > >> that
> > > there is
> > >> a need for a standard.  This can be in a slide, or at the Mic or on
> > >> the
> > > list, slides,
> > >> etc...
> > >>
> > >> If it's just researchers wanting toi agree a spec that may also be
> > >> OK, but
> > > then
> > >> it could be an IRTF activity that comes up with an experimental
> > >> spec for people to evaluate.
> > >>
> > >> Gorry
> > >>
> > >>> Hi, Mirko.
> > >>>
> > >>>
> > >>>
> > >>> The idea of energy savings is also interesting. People are getting
> > >>> more and more concerned with the energy consumption. Not only
> > >> European
> > >>> Commission, but also smartphone and tablet manufacturers: the
> > >>> duration of the battery is critical there.
> > >>>
> > >>>
> > >>>
> > >>> For example, "Qualcomm has developed a solution called Network
> > >>> Socket Request Manager (NSRM) for efficient application
> management.
> > >>> NSRM reduces smart phone signaling traffic by bundling application
> > >>> requests and intelligently delaying them. NSRM provides
> > >>> significant signaling reduction and also improves stand-by time."
> > >>>
> > >>>
> > >>> <http://www.qualcomm.com/media/documents/qualcomm-
> research-
> > >> managing-ba
> > >>> ckgrou
> > >>> nd-data-traffic-mobile-devices>
> > >>> http://www.qualcomm.com/media/documents/qualcomm-research-
> > >> managing-bac
> > >>> kgroun
> > >>> d-data-traffic-mobile-devices
> > >>>
> > >>>
> > >>>
> > >>> Perhaps we could also include this idea in the presentations. The
> > >>> benefits of packet grouping are 3 instead of 2:
> > >>>
> > >>>
> > >>>
> > >>> 1- Bandwidth saving
> > >>>
> > >>> 2- PPS reduction
> > >>>
> > >>> 3- Energy savings
> > >>>
> > >>>
> > >>>
> > >>> What do you think? Will people at the IETF like energy savings?
> > >>>
> > >>>
> > >>>
> > >>> Best regards,
> > >>>
> > >>>
> > >>>
> > >>> Jose
> > >>>
> > >>>
> > >>>
> > >>> De: [e-mail] [mailto:[e-mail]] En
> > nombre
> > >>> de Mirko Su¾njevic Enviado el: martes, 14 de mayo de 2013 10:08
> > >>> Para: [e-mail]
> > >>> Asunto: Re: [tcmtf] BoF proposal for Berlin. Possible scheme
> > >>>
> > >>>
> > >>>
> > >>> Hello everybody,
> > >>>
> > >>> Well I concur with the structure. I believe that the main thing is
> > >>> to do is to well formulate and explain the problem. We must prove
> > >>> in a coherent way that the problem we are addressing here is a
> > >>> problem worth putting effort to and worth solving. In short we
> > >>> must present all the benefits the  solving of our problem might
> > >>> bring. We more or less covered the network aspects of the TCMTF.
> > >>> Maybe one of the previously not emphasized things is the notion of
> > >>> energy savings which TCMTF implementation might bring.  I am not
> > >>> certain would such topics be interesting in the IETF, but it was
> > >>> interesting for the European Commission.
> > >>>
> > >>> Ofcourse I will create the presentation regarding my part.
> > >>>
> > >>>
> > >>> Cheers!
> > >>>
> > >>> Mirko Suznjevic
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> From: Jose Saldana [mailto:[e-mail]]
> > >>> Sent: Monday, May 13, 2013 12:25 PM
> > >>> To: [e-mail]
> > >>> Cc: Martin Stiemerling; Dan Wing; Mirko Su¾njeviæ
> > >>> Subject: BoF proposal for Berlin. Possible scheme
> > >>>
> > >>>
> > >>>
> > >>> Hi all.
> > >>>
> > >>>
> > >>>
> > >>> According to
> > >>> http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87,
> > >>> 2013-06-17 (Monday) is the cutoff date for BOF proposal requests
> > >>> to Area Directors. So we still have a month.
> > >>>
> > >>>
> > >>>
> > >>> we could discuss a bit the possible scheme for the BoF proposal.
> > >>>
> > >>>
> > >>>
> > >>> According to Martin's suggestion, we could begin the session with
> > >>> a teaser presentation describing what the exact issues are and
> > >>> what is the need for standardization.
> > >>>
> > >>>
> > >>>
> > >>> So we could follow this structure:
> > >>>
> > >>>
> > >>>
> > >>> 1- Teaser presentation: describing the problem and the need for
> > >>> standardization
> > >>>
> > >>>
> > >>>
> > >>> 2- Charter: Documents to be generated within this potential WG
> > >>>
> > >>>
> > >>>
> > >>> 3- Draft A: Explaining the current TCMTF proposal
> > >>>
> > >>>
> > >>>
> > >>> 4- Draft B: Explaining the content of the draft about delay
> > >>> requirements, classification methods, etc.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Dan Wing could be in charge of (1). This would be good, since he
> > >>> is one of the authors of RFC4170 (the RFC we should "update" with
> > >>> TCMTF), so he knows the whole story. In addition, he has been in
> > >>> the TCMTF draft from the very beginning.
> > >>>
> > >>>
> > >>>
> > >>> I could be in charge of (2), mainly explaining the charter.
> > >>>
> > >>>
> > >>>
> > >>> Perhaps someone from Telefonica could be in charge of (3).
> > >>>
> > >>>
> > >>>
> > >>> Mirko Suznjevic could present (4), since he is the first author.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> What do you think? Any ideas?
> > >>>
> > >>>
> > >>>
> > >>> Thanks a lot and best regards!,
> > >>>
> > >>>
> > >>>
> > >>> Jose
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> tcmtf mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/tcmtf
> > >>>
> > >
> > >
> > > _______________________________________________
> > > tcmtf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tcmtf
> >
> >
> > --
> > "Esta vez no fallaremos, Doctor Infierno"
> >
> > Dr Diego R. Lopez
> > Telefonica I+D
> > http://people.tid.es/diego.lopez/
> >
> > e-mail: [e-mail]
> > Tel:    [phone]
> > Mobile: [phone]
> > -----------------------------------------
> >
> >
> > ________________________________
> >
> > Este mensaje se dirige exclusivamente a su destinatario. Puede
> > consultar nuestra política de envío y recepción de correo electrónico
> > en el enlace situado más abajo.
> > This message is intended exclusively for its addressee. We only send
> > and receive email on the basis of the terms set out at:
> > http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> 
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf