Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1

Hi all, I agree with Dan. The first kind of signaling ("auto-negotiation") is needed from the beginning if we don't want an extremely static protocol and therefore possibly difficult to get it working, especially when in most of cases the peers belong to different entities/companies.

I think the second kind of signaling (dynamic (de)activation) is very useful in many scenarios (e.g. unexpected congestion in a segment of the network, or in the service provider that would accept that extra delay or jitter in those circumstances), but it could be an extension that can be added later.

Regards

-----Mensaje original-----
De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Dan Wing
Enviado el: miércoles, 09 de enero de 2013 17:24
Para: jsaldana@unizar.es; tcmtf@ietf.org
Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1

> -----Original Message-----
> From: Jose Saldana [mailto:jsaldana@unizar.es]
> Sent: Wednesday, January 09, 2013 8:08 AM
> To: 'Dan Wing'; tcmtf@ietf.org
> Subject: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
> 1
>
> Dan,
>
> The question is if we should include in the charter this objective:
> writing a document about two things which have somewhat appeared
> during the
> discussion:
>
> - Negotiation mechanisms to decide the options at each layer
> (compression, multiplexing and tunneling) between mux and demux.
> Perhaps the mux has ROHC, ECRTP and IPHC, and the demux only has ECRTP
> and IPHC, so the two machines will have to negotiate in order to
> decide which compression protocol use.

We need that -- it is capabilities negotiation.  It is needed because the protocol will fail if one side mistakenly thinks the other side has certain functionality, and because we will want to add some fancy new compression in the year 2020 and will need to negotiate it.

I don't think it needs to be a separate milestone or a separate document, though.

> - dynamically establishing, modifying and releasing tunnels

-d

> Best regards,
>
> Jose
>
> > -----Mensaje original-----
> > De: Dan Wing [mailto:dwing@cisco.com] Enviado el: miércoles, 09 de
> > enero de 2013 16:38
> > Para: jsaldana@unizar.es; tcmtf@ietf.org
> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
> > 1
> >
> > > -----Original Message-----
> > > From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On
> > > Behalf Of Jose Saldana
> > > Sent: Wednesday, January 09, 2013 1:48 AM
> > > To: tcmtf@ietf.org
> > > Subject: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
> > > 1
> > >
> > > One question is if we should consider the creation of a specific
> > > draft about signaling issues.
> >
> > So, this is a 'problem statement', describing the problem we're
> > trying to
> solve
> > (e.g., the application's tolerance for TCMTF-induced jitter)?
> > Or, this is a document analyzing how we signal TCMTF capabilities to
> > the other end?
> >
> >
> > > In paragraph 5, I have written the idea, but I don't currently
> > > know if it is necessary at this stage: "a mechanism to negotiate
> > > which concrete option would they use in each layer".
> > >
> > >
> > >
> > > My opinion: We could first focus on drafts (A) and (B), and later
> > > re- charter the WG if necessary in order to consider this other
> document.
> >
> > Agreed.
> >
> > -d
> >
> >
> > >
> > >
> > >
> > > What do you think?
> > >
> > >
> > >
> > > Jose
> > >
> > >

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

________________________________

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