Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows

Hi all,

        I also think that the flows (TCP in that case) will have their own e2e
congestion control, and TCMTF will be something in the middle not aware
about that methods. In case of congestion (too much traffic at the mux),
by performing the TCMTF the situation could be solved, if not, packet
delay will be higher and the flow transmitter will generate packets slower.
        The problem is that the delay introduced by the TCMTF function could
trick the origin of the flow, thinking that the flow path is congested and
reducing the transmission rate. This is something that will have to be
addressed.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
fpb@tid.es

On 21/01/13 14:33, "Jose Saldana" <jsaldana@unizar.es> wrote:

>Gorry,
>
>Regarding your question:
>> RTT and/or control feedback would be really helpful in establishing a
>> congestion control or circuit-breaker function to ensure the traffic
>>does not
>> cause congestion collapse. Have you thought about this?
>
>If I understand well, you are talking about using RTT or feedback not
>only for selecting an adequate multiplexing period, but also for
>congestion control. Is this true?
>
>The question is that TCMTF is designed for traffic saving, so I think the
>cause of the congestion would not be TCMTF itself, but a high amount of
>flows, or a high bandwidth to aggregate. So perhaps in that case the
>flows which are being multiplexed will have their own end-to-end
>congestion control mechanisms.
>
>An example: you are grouping a lot of TCP flows of an MMORPG game. If a
>bottleneck appears and delays rise, TCP mechanisms will act and reduce
>the rate.
>
>Can we find an example in which interrupting the use of TCMTF and sending
>native packets instead will be necessary? Perhaps this one: if you are
>using TCMTF for reducing pps and not bandwidth. This can happen with VoIP
>in a satellite network: you group packets without header compression. You
>reduce pps and you increase bandwidth. However, I think bandwidth
>increase is really small: 25 bytes for the tunnel header and two more
>bytes for separating each multiplexed packet. If you are grouping 10 VoIP
>packets (20 IP/8 UDP/12 RTP/20 payload), the tunnel needs 25 +
>10x(2+60)=645bytes. Native traffic would need 10x60=600 bytes. So
>bandwidth increase is 7.5%. If you group 20 packets, bandwidth increase
>is 1265/1200= 5%
>
>Gorry, was this your idea? Are you thinking about other scenarios in
>which interrupting TCMTF can be interesting?
>
>Thanks a lot,
>
>Jose
>
>> -----Mensaje original-----
>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de
>> Gorry Fairhurst
>> Enviado el: viernes, 18 de enero de 2013 11:25
>> Para: tcmtf@ietf.org
>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using Tunneling
>> Compressed Multiplexed Traffic Flows
>>
>> If this is going to be used in the general Internet, then we need to
>>decide
>> whether there is one-way or two-way control connectivity. This will
>> determine the constraints from a congestion control perspective.
>> RTT and/or control feedback would be really helpful in establishing a
>> congestion control or circuit-breaker function to ensure the traffic
>>does not
>> cause congestion collapse. Have you thought about this?
>>
>> Gorry
>>
>>
>>
>> On 17/01/2013 13:50, Jose Saldana wrote:
>> > In addition, perhaps we are too focused on online games and VoIP
>> services. There are other services which are one-way: perhaps M2M
>> communications do not require a two way communication. We can think
>> about a number of sensors sending their measurements to a central
>>server.
>> So perhaps RTT will not even exist in this case.
>> >
>> > Jose
>> >
>> >> -----Mensaje original-----
>> >> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es] Enviado el: jueves,
>> >> 17 de enero de 2013 14:39
>> >> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián
>> >> Fernández Navajas'
>> >> CC: tcmtf@ietf.org
>> >> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >> Tunneling Compressed Multiplexed Traffic Flows
>> >>
>> >> Jose,
>> >>
>> >>          Let´s say that playing with the OWD you have more
>> >> granularity in order to know in which direction you need to reduce
>> >> the delay by reducing the multiplexing delay. But people with more
>> >> knowledge about online games will provide us more information for
>>sure.
>> >>
>> >> Regards,
>> >>
>> >> Fernando Pascual Blanco
>> >> Telefónica Global Resources
>> >> Network Automation and Dynamization
>> >> TECHNOLOGY PEOPLE GROUP
>> >> F +34913128779
>> >> M +34682005168
>> >> fpb@tid.es
>> >>
>> >>
>> >>
>> >>
>> >> On 17/01/13 13:16, "Jose Saldana" <jsaldana@unizar.es> wrote:
>> >>
>> >>> Fernando,
>> >>>
>> >>> So you may have this case:
>> >>> - your multiplexing delay limit is 50 ms
>> >>> - you have a lot of flows to multiplex, so perhaps the time between
>> >>> multiplexed packets will be 5 ms
>> >>> - you detect an increase in RTT
>> >>> - the system reacts and reduces multiplexing period
>> >>> - in fact, the reduction doesn't matter until the period is reduced
>> >>> to less than 5 ms
>> >>>
>> >>> So you only have to make this decision: using tcmtf with 5 ms period
>> >>> or not. If RTT is critical you may not be interested on saving
>> >>> bandwidth, but on reducing a bit the RTT.
>> >>>
>> >>> So I think your question is: what happens if the RTT is very big
>> >>> (out of
>> >>> limits) and you can save bandwidth using a 5ms multiplexing period?
>> >>>
>> >>> For example, the maximum RTT for a good quality is 80 ms and your
>> >>> network has 120 just now. In this case, perhaps having 125 doesn't
>> >>> matter, if you can save bandwidth.
>> >>>
>> >>> This makes sense, but it is a "extreme" case. However, would it be
>> >>> any advantage if OWD is used instead of RTT?
>> >>>
>> >>> Best regards,
>> >>>
>> >>> Jose
>> >>>
>> >>>> -----Mensaje original-----
>> >>>> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]  Enviado el:
>> >>>> miércoles, 16 de enero de 2013 12:52
>> >>>> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; 'Julián
>> >>>> Fernández  Navajas'
>> >>>> CC: tcmtf@ietf.org
>> >>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >>>> Tunneling  Compressed Multiplexed Traffic Flows
>> >>>>
>> >>>> Hi Jose,
>> >>>>
>> >>>>          You are right, but my point here is:
>> >>>>
>> >>>>                  Client - Mux - Demux - Server
>> >>>>
>> >>>>          Imagine that there is enough packets between mux and demux
>> >>>> to make  the added delay very small (TCMTF is working very well and
>> >>>> the mux has not  to wait the multiplexing period to fulfill a big
>> >>>> packet and send it, so imagine a  multiplexing period of 50 ms and
>> >>>> a big packet is fulfilled in 5 ms). If the RTT  get increased
>> >>>> because a congestion in the way back to the client (there is no
>> >>>> TCMTF
>> >>>> optimization) and we decrease the multiplexing period (even in the
>> >>>> extreme we can disable the TCMTF optimization) the high RTT will
>> remain.
>> >>>> Even if the TCMTF optimization was helping in the client to server
>> >>>> path,  disabling it may harm. Do you think that scenario would be
>> possible?
>> >>>>
>> >>>>          So I´m not sure about that, I think we need more opinions
>>here.
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Fernando Pascual Blanco
>> >>>> Telefónica Global Resources
>> >>>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP
>> F
>> >>>> +34913128779 M +34682005168 fpb@tid.es
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 16/01/13 11:57, "Jose Saldana" <jsaldana@unizar.es> wrote:
>> >>>>
>> >>>>> My two cents:
>> >>>>>
>> >>>>> In games and in VoIP the really important thing is RTT:
>> >>>>>
>> >>>>> - Games always measure the RTT (gamers talk about the "ping"): the
>> >>>>> important thing is the delay from a player action to the server
>> >>>>> reaction arriving to the player's machine.
>> >>>>> - In VoIP I think it is the same: what matters is the RTT, in
>> >>>>> order to grant interactivity and avoiding cross-talk.
>> >>>>>
>> >>>>> In addition, RTT is easier to measure than OWD, since you don't
>> >>>>> need synchronization.
>> >>>>>
>> >>>>> And regarding Two-way TCMTF, I think we have to think about TCMTF
>> >>>>> as one-way. Otherwise, things would become very complicated.
>> Some
>> >>>> services
>> >>>>> have very different client-server and server-client traffic
>> >>>>> patterns (e.g. games). In addition, sometimes the two flows can
>> >>>>> follow different network paths. I think once we talked about a
>> >>>>> network provider using a number of ISPs.
>> >>>>>
>> >>>>> However, using RTT for tuning a one-way TCMTF may not be bad... or
>> >>>>> is it bad? Any other thoughts?
>> >>>>>
>> >>>>> BR,
>> >>>>>
>> >>>>> Jose
>> >>>>>
>> >>>>>> -----Mensaje original-----
>> >>>>>> De: FERNANDO PASCUAL BLANCO [mailto:fpb@tid.es]  Enviado el:
>> >>>> martes,
>> >>>>>> 15 de enero de 2013 18:04
>> >>>>>> Para: jsaldana@unizar.es; 'Dan Wing'; 'Mirko Sužnjević'; Julián
>> >>>>>> Fernández  Navajas
>> >>>>>> CC: tcmtf@ietf.org
>> >>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >>>>>> Tunneling  Compressed Multiplexed Traffic Flows
>> >>>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>>          To re-open that issue, I would suggest that given that
>> >>>>>> the delay is so  sensitive in real time services, we need to find
>> >>>>>> a consensus here.
>> >>>>>>
>> >>>>>>          My opinion is that to apply the first possibility (the
>> >>>>>> static multiplexing
>> >>>>>> period) we need to suppose that the network conditions are really
>> >>>>>> bad, to be  protected when the network congestion arises. In that
>> >>>>>> case, the application  of the TCMTF optimization will not be
>> >>>>>> optimal, so that would be the less  preferred option, but easier
>> >>>>>> to implement and maintain over the time.
>> >>>>>>
>> >>>>>>          On the other hand, the second possibility would be the
>> >>>>>> preferred. It is  easy to know the delay between the mux and the
>> >>>>>> demux but most of the  times will not be enough unless mux and
>> >>>>>> demux were really near from the  client and the server
>> >>>>>> respectively. I agree with Jose in the possibility of snoop  RTCP
>> >>>>>> packets in order to adapt the multiplexing period when
>> >>>>>> multiplexing RTP packets (and RTCP is available). Talking about
>> >>>>>> RTT, I´m not sure if RTT  would be useful given that the
>> >>>>>> multiplexing period only affect the one way  delay (OWD). Imagine
>> the following scenario:
>> >>>>>>          - Client - Mux/Demux - Demux/Mux - Server (two ways
>> >>>>>> TCMTF, TWTCMTF :P)
>> >>>>>>          - The OWD from server to client get increased
>> >>>>>>          - The OWD from client to server remains equal
>> >>>>>>          - Should we use a lower multiplexing period in the
>> >>>>>> client to server  direction? I don´t think so… because we should
>> >>>>>> use a lower multiplexing  period in the other direction.
>> >>>>>>
>> >>>>>>          My point is that the multiplexing period should only be
>> >>>>>> affected by the  OWD and not by the RTT (or it may be application
>> >>>>>> dependent). How to  calculate the OWD? I´ve been reading
>> >>>>>> something about OWAMP and it  seems that an specific software has
>> >>>>>> to be implemented in the client/server  side.
>> >>>>>> Can we assume that? Unfortunately I cannot contribute so much
>> >> here…
>> >>>>>>          It is possible that for certain services the static (and
>> >>>>>> worst
>> >>>>>> case)
>> >>>>>> multiplexing period would be the better solution.
>> >>>>>>
>> >>>>>>          What do you think?
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>>
>> >>>>>> Fernando Pascual Blanco
>> >>>>>> Telefónica Global Resources
>> >>>>>> Network Automation and Dynamization TECHNOLOGY PEOPLE
>> GROUP
>> >> F
>> >>>>>> +34913128779 M +34682005168 fpb@tid.es
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 17/12/12 12:25, "Jose Saldana" <jsaldana@unizar.es> wrote:
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> Julian and I have been discussing about this. Some ideas have
>> >>>> arisen.
>> >>>>>>> This is the summary.
>> >>>>>>>
>> >>>>>>> This would be the scheme of the system, including mux and
>> demux:
>> >>>>>>>
>> >>>>>>> Real-time application ------- mux -------- internet ---------
>> >>>>>>> demux
>> >>>>>>> -------
>> >>>>>>> server
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I think perhaps the draft could say something like:
>> >>>>>>>
>> >>>>>>> When setting the multiplexing period, there are two
>>possibilities:
>> >>>>>>>
>> >>>>>>> 1.- Static / permanent: At system setup time, network delays are
>> >>>>>>> measured, and a multiplexing period is selected and set in the
>> >>>>>> multiplexer.
>> >>>>>>>
>> >>>>>>> 2.- Dynamic: A mechanism is used so as to adapt to the evolution
>> >>>>>>> of network delays. In this case, different mechanisms can be
>> >>>>>>> used in order to obtain periodical end-to-end network delay
>> >>>>>>> estimations, which would be useful in order to set the
>> >>>>>>> multiplexing
>> >> period:
>> >>>>>>>
>> >>>>>>> - If the traffic is RTP, then RTCP packets containing the
>> >>>>>>> estimation could be analyzed in order to extract these values,
>> >>>>>>> as Dan
>> >> suggests.
>> >>>>>>> The question
>> >>>>>>> is: would that packets travel through the multiplexer?
>> >>>>>>> - If the traffic is TCP, perhaps something similar to the RTT
>> >>>>>>> estimation of TCP could be useful.
>> >>>>>>> - If the traffic is UDP, should the mux use something like OWAMP
>> >>>>>>> (http://tools.ietf.org/html/rfc4656) in order to calculate two
>> >>>>>>> delays (application to mux, and mux to server) and calculate the
>> >>>> sum?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I think the draft is only supposed to report the maximum delays
>> >>>>>>> normally considered acceptable. Perhaps the additional
>> >>>>>>> mechanisms for calculating the RTT could just be suggested.
>> >>>>>>>
>> >>>>>>> What do you think?
>> >>>>>>>
>> >>>>>>> Jose
>> >>>>>>>
>> >>>>>>>> -----Mensaje original-----
>> >>>>>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En
>> >>>>>>>> nombre de Dan Wing Enviado el: viernes, 14 de diciembre de 2012
>> >>>>>>>> 18:33
>> >>>>>>>> Para: jsaldana@unizar.es; 'Mirko Sužnjević'
>> >>>>>>>> CC: tcmtf@ietf.org
>> >>>>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >>>>>>>> Tunneling Compressed Multiplexed Traffic Flows
>> >>>>>>>>
>> >>>>>>>>> -----Original Message-----
>> >>>>>>>>> From: Jose Saldana [mailto:jsaldana@unizar.es]
>> >>>>>>>>> Sent: Friday, December 14, 2012 2:58 AM
>> >>>>>>>>> To: 'Dan Wing'; 'Mirko Sužnjević'
>> >>>>>>>>> Cc: tcmtf@ietf.org
>> >>>>>>>>> Subject: RE: [tcmtf] Draft: Maximum Tolerable Delays when
>> >>>>>>>>> using Tunneling Compressed Multiplexed Traffic Flows
>> >>>>>>>>>
>> >>>>>>>>> Dan,
>> >>>>>>>>>
>> >>>>>>>>> Regarding the use of the maximum delay, some days ago we
>> >>>>>>>>> discussed about
>> >>>>>>>>> it:
>> >>>>>>>>> the actual OWD of the network should be measured (or
>> >>>>>>>>> estimated) in order to know the maximum multiplexing period
>> we
>> >> can set.
>> >>>>>>>>>
>> >>>>>>>>> We may have this formula, if thinking one-way:
>> >>>>>>>>>
>> >>>>>>>>> OWD  + Mux period/2  < tolerable_OWD
>> >>>>>>>>>
>> >>>>>>>>> If we think RTT:
>> >>>>>>>>>
>> >>>>>>>>> OWD + Mux period/2 + OWD back < 2*tolerable_OWD
>> >>>>>>>>>
>> >>>>>>>>> I don't know if we should include a mechanism for estimating
>> >>>>>>>>> OWD in tcmtf. I think this is more an implementation problem,
>> >>>>>>>>> which may be already solved.
>> >>>>>>>>
>> >>>>>>>> Yes, it's already solved end-to-end:  RTP with RTCP feedback
>> >>>>>>>> allows determining one way delay.
>> >>>>>>>>
>> >>>>>>>> But if something in the middle is multiplexing several packets
>> >>>>>>>> together,
>> >>>>>>> we
>> >>>>>>>> don't want it to add too much delay.  That thing in the middle
>> >>>>>>>> won't necessarily know the one way delay seen by the endpoints,
>> >>>>>>>> unless it analyzes the RTP and RTCP.  There are devices that do
>> >>>>>>>> that on the market,  mostly to diagnose where networks are
>> >>>>>>>> causing loss/delay with RTP flows.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> Another option is using some typical values, e.g. from
>> >>>>>>>>>
>> >> http://ipnetwork.bgtmo.ip.att.net/pws/global_network_avgs.htm
>> >>>>>>>>> l
>> >>>>>>>>>
>> >>>>>>>>> The draft includes some preliminary/recommended values for
>> the
>> >>>>>>>>> Multiplexing Period. Is this interesting? Should we put the
>> >>>>>>>>> formula instead?
>> >>>>>>>>
>> >>>>>>>> It's probably sufficient as-is.
>> >>>>>>>>
>> >>>>>>>> -d
>> >>>>>>>>
>> >>>>>>>>> Mirko, another question: in online games, players usually talk
>> >>>>>>>>> about the "ping", and I think it means RTT. Don't you think it
>> >>>>>>>>> would be better to define a RTT limit instead of a OWD one in
>> >>>>>>>>> that
>> >>>>>> case?
>> >>>>>>>>>
>> >>>>>>>>> What do you think?
>> >>>>>>>>>
>> >>>>>>>>> Jose
>> >>>>>>>>>
>> >>>>>>>>>> -----Mensaje original-----
>> >>>>>>>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org]
>> En
>> >>>>>>>>>> nombre de Dan Wing Enviado el: jueves, 13 de diciembre de
>> >>>>>>>>>> 2012
>> >>>>>>>>>> 17:07
>> >>>>>>>>>> Para: 'Mirko Sužnjević'; tcmtf@ietf.org
>> >>>>>>>>>> Asunto: Re: [tcmtf] Draft: Maximum Tolerable Delays when
>> >>>>>>>>>> using Tunneling Compressed Multiplexed Traffic Flows
>> >>>>>>>>>>
>> >>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>> From: tcmtf-bounces@ietf.org [mailto:tcmtf-
>> bounces@ietf.org]
>> >>>>>>>>>>> On Behalf Of Mirko Sužnjevic
>> >>>>>>>>>>> Sent: Thursday, December 13, 2012 1:07 AM
>> >>>>>>>>>>> To: tcmtf@ietf.org; tsvwg@ietf.org
>> >>>>>>>>>>> Subject: [tcmtf] Draft: Maximum Tolerable Delays when using
>> >>>>>>>>>>> Tunneling Compressed Multiplexed Traffic Flows
>> >>>>>>>>>>>
>> >>>>>>>>>>> Hello,
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> We have just submitted the draft named Maximum Tolerable
>> >>>>>>>>>>> Delays when using Tunneling Compressed Multiplexed Traffic
>> >>>> Flows:
>> >>>>>>>>>>> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd
>> >>>>>>>>>>> -tc
>> >>>>>>>>>>> mtf
>> >>>>>>>>>>> /
>> >>>>>>>>>>
>> >>>>>>>>>> The suggested 400ms for interactive voice is at least 2x too
>> >>>>>> high.
>> >>>>>>>>>> I
>> >>>>>>>>> expect
>> >>>>>>>>>> that number does not include the playout jitter buffer (which
>> >>>>>>>>>> is variable,
>> >>>>>>>>> but
>> >>>>>>>>>> usually a few samples, so 40-80ms).  200ms end-to-end is the
>> >>>>>>>>>> higher end,
>> >>>>>>>>> and
>> >>>>>>>>>> that includes jitter buffer, codec processing, and so on.
>> >>>>>>>>>>
>> >>>>>>>>>> But, more importantly:  it seems valuable for endpoints to
>> >>>>>>>>>> signal their maximum delay somehow.  Or would the TCMTF
>> >>>>>>>>>> function
>> >>>>>>>> determine
>> >>>>>>>>>> the maximum delay, using some heuristic?
>> >>>>>>>>>>
>> >>>>>>>>>> How does the TCMTF function determine how much of that
>> >>>>>>>>>> 'tolerable latency' budget it can consume?
>> >>>>>>>>>>
>> >>>>>>>>>> -d
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>> It is an extension of tcmtf
>> >>>>>>>>>>> http://datatracker.ietf.org/doc/draft-
>> >>>>>>>>>>> saldana-tsvwg-tcmtf/. Since a specific list for tcmtf exists
>> >>>>>>>>>>> (tcmtf@ietf.org), the idea is to discuss it there.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> The draft contains recommendations for TCMTF multiplexing
>> >>>>>>>>>>> period for different real-time services. In order to prevent
>> >>>>>>>>>>> QoE degradation of real-time services using TCMTF, a policy
>> >>>>>>>>>>> defining a multiplexing period can be employed. Values of
>> >>>>>>>>>>> maximum tolerable delays presented in
>> >>>>>>>>>> the
>> >>>>>>>>>>> draft form the base of such policy.    The recommendations
>> >>>> are
>> >>>>>>>>> presented
>> >>>>>>>>>>> for real-time network services in which TCTMF bandwidth
>> >>>>>>>>>>> optimization is applicable (i.e., services  which have low
>> >>>>>>>>>>> payload to header size ratio which results in high protocol
>> >>>>>> overhead).
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Your feedback will be welcome. Thank you.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Sincerely,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Mirko Suznjevic
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> tcmtf mailing list
>> >>>>>>>>>> tcmtf@ietf.org
>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> tcmtf mailing list
>> >>>>>>>> tcmtf@ietf.org
>> >>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> 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
>> > tcmtf@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcmtf
>> >
>>
>> _______________________________________________
>> tcmtf mailing list
>> tcmtf@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcmtf
>
>_______________________________________________
>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