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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

Along with it I think we also need a way for the muxer and de-muxer to discover each other. In a way it is a generalization of:
> dynamically establishing, modifying and releasing tunnels

Once we have that the muxer and de-muxer can setup a tunnel on-demand and don't have to assume that there is always a muxer/de-muxer at the other end of an existing tunnel.

When a muxer/de-muxer discovers more than one de-muxer/muxer, we may also need a mechanism to elect a muxer and a de-muxer for a flow -- but, I think it can be added later.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of JUAN ANTONIO CASTELL LUCIA
|Sent: Thursday, January 10, 2013 2:46 AM
|To: Dan Wing (dwing); [e-mail]; [e-mail]
|Subject: 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: [e-mail] [mailto:[e-mail]] En nombre de Dan Wing
|Enviado el: miércoles, 09 de enero de 2013 17:24
|Para: [e-mail]; [e-mail]
|Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
|
|> -----Original Message-----
|> From: Jose Saldana [mailto:[e-mail]]
|> Sent: Wednesday, January 09, 2013 8:08 AM
|> To: 'Dan Wing'; [e-mail]
|> 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:[e-mail]] Enviado el: miércoles, 09 de
|> > enero de 2013 16:38
|> > Para: [e-mail]; [e-mail]
|> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
|> > 1
|> >
|> > > -----Original Message-----
|> > > From: [e-mail] [mailto:[e-mail]] On
|> > > Behalf Of Jose Saldana
|> > > Sent: Wednesday, January 09, 2013 1:48 AM
|> > > To: [e-mail]
|> > > 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
|[e-mail]
|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
|_______________________________________________
|tcmtf mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/tcmtf