Subject: Re: [tcmtf] BoF proposal for Berlin. Showing the interest of the Industry

From: "Jose Saldana" <[email-masked]>
Date: Mon, 20 May 2013 12:01:33 +0200

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: [email-masked] [mailto:[email-masked]]
> Enviado el: miércoles, 15 de mayo de 2013 11:10
> Para: [email-masked]
> CC: "'Mirko Su¾njeviæ'"; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] En nombre
> > de Mirko Su¾njevic Enviado el: martes, 14 de mayo de 2013 10:08
> > Para: [email-masked]
> > 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:[email-masked]]
> > Sent: Monday, May 13, 2013 12:25 PM
> > To: [email-masked]
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> >

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 20 May 2013 11:07:33 +0000

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:

> - So why not widening TCRTP's scope in order to:

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

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

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 20 May 2013 13:18:19 +0200

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

> De: Diego R. Lopez [mailto:[email-masked]]
> Enviado el: lunes, 20 de mayo de 2013 13:08
> Para: <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: [tcmtf] BoF proposal for Berlin. Showing the interest of the
> Industry
> 
> Hi Jose,
> 
> > 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.
> >
> >       - ECRTP for header compression, so only services based on RTP
> > are considered
> >       - a lot of applications generating long-term flows with high
> > rates of non-RTP small packets have emerged
> >
> >> De: [email-masked] [mailto:[email-masked]] Enviado el:
> >> miércoles, 15 de mayo de 2013 11:10
> >> Para: [email-masked]
> >> it could be an IRTF activity that comes up with an experimental spec
> >> for people to evaluate.
> >>
> >> Gorry
> >>
> >>> Hi, Mirko.
> >>>
> >>>
> >>>
> >>> 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."
> >>>
> >>>
> >>> 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
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> 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:

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Mon, 20 May 2013 12:46:09 +0000

According the last consideration " do we need a specific document for multiplexing RTP VoIP flows?". Under my point of view "no", although VoIP is an important use case, the document should address generic cases oriented by priority/delay-sensitive and not an individual VoIP case.

Manuel.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: lunes, 20 de mayo de 2013 13:18
Para: Diego R. Lopez
CC: [email-masked]
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

> De: Diego R. Lopez [mailto:[email-masked]] Enviado el: lunes, 20 de mayo
> de 2013 13:08
> Asunto: Re: [tcmtf] BoF proposal for Berlin. Showing the interest of
> the Industry
>
> Hi Jose,
>
> >> it could be an IRTF activity that comes up with an experimental
> >> spec for people to evaluate.
> >>
> >> Gorry
> >>
> >>> Hi, Mirko.
> >>>
> >>>
> >>>
> >>> requests and intelligently delaying them. NSRM provides
> >>> significant signaling reduction and also improves stand-by time."
> >>>
> >>>
> >>> 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.
> >>>
> >>> 2013-06-17 (Monday) is the cutoff date for BOF proposal requests
> >>> to Area Directors. So we still have a month.
> >>>
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> 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: