Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

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

Hi Fernando,

| I´m sure we will find a consensus about that :).

Sure..

|What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF
|establishing should be quite similar to the establishing procedures of tunnels
|defined in draft A (L2TP, GRE...),

I agree the procedures for establishing the association b/w the muxer and the de-muxer could be similar to those of establishing a tunnel. However, I would like us to avoid two assumptions:
1. The other end of a tunnel is always TCMTF capable. I think this is more important when you already have a tunnel (say, IPSec tunnel) and would like to perform TCMTF on the fly.
2. A tunnel is always needed for performing TCMTF. If we aren't doing any compression, but only multiplexing, the outermost IP header would be intact and should suffice for routing the packets. There are satellite networks where reducing the packets per second (pps) for VoIP calls is more important -- they don't do any compression, but only multiplexing, and don't setup a tunnel as well. For e.g:
http://www.cisco.com/web/strategy/docs/gov/aag_c45-697642_v2.pdf
http://www.cisco.com/web/strategy/docs/gov/ip_multiplexing_agensler.pptx

Nevertheless, I think all this go into the signaling doc. If we require capability negotiation, I think we can combine it with the procedure for establishing the association b/w the muxer and the de-muxer. If we make capability negotiation as optional, we might want to keep those as separate procedures.

Muthu

From: [e-mail] [mailto:[e-mail]] On Behalf Of FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [e-mail]; Muthu Arul Mozhi Perumal (mperumal)
Cc: [e-mail]
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Jose, Muthu,

I´m sure we will find a consensus about that :). What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF establishing should be quite similar to the establishing procedures of tunnels defined in draft A (L2TP, GRE...), actually at network level TCMTF is a tunnel. Once established signaling will negotiate upper levels (multiplexing and HC) to perform TCMTF (draft A).

What do you think?

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]<mailto:[e-mail]>

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Organization: Universidad de Zaragoza
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: miércoles, 16 de enero de 2013 11:18
To: "'Muthu Arul Mozhi Perumal (mperumal) '" <[e-mail]<mailto:[e-mail]>>, Fernando Pascual Blanco <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RV: [tcmtf] TCMTF: Document A: mechanism for a muxer to discover a de-muxer


Fernando, Muthu, everyone,



Since there is no consensus about this, I think we should carry on with the debate. Do you think the mechanism would be very complicated? Any new ideas?:



- *dynamically establishing, modifying and releasing tunnels*



#1. A *mechanism for a muxer to discover a de-muxer (and vice versa)*.



There is still no consensus here:



Fernando: "Regarding #1, to be honest, I am not completely sure of the need to specify a mechanism to discover muxes and demuxes between them. I think those kind of mechanisms have more sense in local environments but I´m not sure if it applies here. At least at the beginning this associations can be done manually."



Muthu: "I think it is the opposite -- in local environments you can provision/associate them manually. However, in a multi-vendor environment over the Internet this should happen automatically."

"#1 needs to be specified."


Best regards,

Jose

De: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [e-mail]<mailto:[e-mail]>
Asunto: [tcmtf] TCMTF: Document A discussion: content and charter

Document (A) refers to the main TCMTF draft, currently in http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

1.- Content of the Document

Currently it contains the description of the question and the protocols which could be used on each layer (tunneling, compressing, multiplexing). It says that the signaling issues would be that of each protocol.

There is consensus (I think) about this: we should include some signaling issues. The question is: What should we include in Draft A and what in Draft C?

- *Auto-negotiation* 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.

This should be included in (A). I think there is consensus about this:
Juan Antonio: "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."



Dan: "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."



Fernando: "I also agree with the idea of including the mux-demux signaling within the draft A (as Dan said, they are capabilities negotiation). This draft should be able to get two boxes with TCMTF fully working between them. Under my point of view this includes the definition of the capabilities in each node and the negotiation of that capabilities."



Does this mean that Document (A) will no longer be a Best Current Practice? I think so.





- *dynamically establishing, modifying and releasing tunnels*



#1. A *mechanism for a muxer to discover a de-muxer (and vice versa)*.



There is still no consensus here:



Fernando: "Regarding #1, to be honest, I am not completely sure of the need to specify a mechanism to discover muxes and demuxes between them. I think those kind of mechanisms have more sense in local environments but I´m not sure if it applies here. At least at the beginning this associations can be done manually."



Muthu: "I think it is the opposite -- in local environments you can provision/associate them manually. However, in a multi-vendor environment over the Internet this should happen automatically."

"#1 needs to be specified."







#2. A mechanism to *elect an optimal muxer and a de-muxer when there are more than one muxer/de-muxer for a flow*.



We agree: This can wait for Document (C).



                Fernando: "#2 is more related to the higher entity that has to decide whether a flow should be TCMTFed or not, and under my point of view it can be addressed in a different draft."

                Muthu: "#2 can be added later."





3. A mechanism to *setup/release a tunnel b/w a muxer and a de-muxer*.



We agree: This has to be included in (A).



                Fernando "#3 I think should be included in the draft A, since it is a mechanism within the TFMTF protocol itself."

                Muthu: "#3 many not require much specification."





2.- Should we include it in the Charter now?

Of course, Document (A) should be in the charter.


Best regards,

Jose


________________________________

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