Subject: [tcmtf] Some thoughts about new scenarios for tcmtf

From: <[email-masked]>
Date: Fri, 16 Nov 2012 15:31:25 +0000

Dear All,

As discussed some time ago, satellite and wireless access network can be attractive network scenarios where tcmtf principles can be exploited.
However, usual wireless and satellite encapsulation protocol (between IP and lower layers) already provide means to multiplexing and "tunneling" 
compressed flows. 
In this respect, the application of tcmtf in these scenarios is less attractive, as it would introduce additional overhead, resulting in less benefits from 
the bandwidth-saving point of view. Hence, we propose a deviation from the tcmtf concepts, so that the access network (wireless or satellite) keeps 
untouched the protocol stack allowing the compression of data flows through ROHC (for example). The access point serving as "bridge" between 
the access network and the second leg of the network (i.e. Internet) implements a dual stack, with PPPmux and IP tunneling techniques, to multiplex and tunnel 
the compressed flows coming from the access network. The final destination will obviously implement a stack including the three tcmtf ingredients (compression, 
multiplexing, tunneling).

The following diagram illustrates the idea: A wireless Node A delivers data to Node B though the wireless access networks and Internet.
As this idea substantially deviates from the concepts presented in draft-saldana-tsvwg-tcmtf-03, we propose to dedicate an additional I-D 
to this idea, where implications on mobility and security should be addressed as well.

What is your opinion?

Best Regards,

Tomaso
  
											         Node B
											        +------------+
Node A                                                                   						        | Appl.         |
+------------ +                                                            						        +------------+
| Appl.         |                                                                    						        | TCP/UDP |
+------------+                                                                    						        +------------+
| TCP/UDP |                                                         Access Point                       			        |        IP        |
+------------+                                                       +-----------------------------+                     		        +------------+
|         IP       |                                                        |       Relay                              |                   		        |   ROHC      |   
+------------+                                                        +----------------------------+                     		        +------------+
|  ROHC       |                                                       |                        |  PPPmux   |                      		        |  PPPmux |
+------------+                                                       |  Encaps         +------------+                    		        +------------+
| Encaps     |                                                        | 	           |  IPtunn.     |                                                   |  IPtunn.  |
+------------+		                                 +---------------+------------+                      		        +------------+
|  L2/L1       |		                                 |  L2/L1           |  L2/L1         |                   		        |  L2/L1       |
+------------+                                                        +---------------+------------+                      		        +------------+
|					 |                                                |			        |		
|<------Wireless Access network-------->|                                                |<------Internet----------->|
|        (WLAN, Satellite, ...)       		 |                   		    |		                        |

------------------------ 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
http://www.dlr.de/kn/institut/abteilungen/san

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 19 Nov 2012 20:49:54 +0100

Tomaso,

If I understand well, the idea is that tcmtf is not used in the satellite
link, but only  in the "Internet" part. So the "Access Point" does not need
to decompress the ROHC headers.

I think that the key question is now: can this be included in the current
draft-saldana-tsvwg-tcmtf-03 of tcmtf or would it require a specific draft?

You say that the idea is different from the concepts in
draft-saldana-tsvwg-tcmtf-03. If you could provide some reasons supporting
this, it would be fine, I think.

We also need feedback from the list in order to set this clear.

Thank you very much,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> [email-masked]
> Enviado el: viernes, 16 de noviembre de 2012 16:31
> Para: [email-masked]
> CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Asunto: [tcmtf] Some thoughts about new scenarios for tcmtf
> 
> 
> Dear All,
> 
> As discussed some time ago, satellite and wireless access network can be
> attractive network scenarios where tcmtf principles can be exploited.
> However, usual wireless and satellite encapsulation protocol (between IP
> and lower layers) already provide means to multiplexing and "tunneling"
> compressed flows.
> In this respect, the application of tcmtf in these scenarios is less
attractive,
> as it would introduce additional overhead, resulting in less benefits from
> the bandwidth-saving point of view. Hence, we propose a deviation from
> the tcmtf concepts, so that the access network (wireless or satellite)
keeps
> untouched the protocol stack allowing the compression of data flows
> through ROHC (for example). The access point serving as "bridge" between
> the access network and the second leg of the network (i.e. Internet)
> implements a dual stack, with PPPmux and IP tunneling techniques, to
> multiplex and tunnel the compressed flows coming from the access
> network. The final destination will obviously implement a stack including
> the three tcmtf ingredients (compression, multiplexing, tunneling).
> 
> The following diagram illustrates the idea: A wireless Node A delivers
data
> to Node B though the wireless access networks and Internet.
> As this idea substantially deviates from the concepts presented in draft-
> saldana-tsvwg-tcmtf-03, we propose to dedicate an additional I-D to this
> idea, where implications on mobility and security should be addressed as
> well.
> 
> What is your opinion?
> 
> Best Regards,
> 
> Tomaso
> 
> 
> 	         Node B
> 
> 	        +------------+
> Node A
> 	        | Appl.         |
> +------------ +
> 	        +------------+
> | Appl.         |
> 		        | TCP/UDP |
> +------------+
> 
> | TCP/UDP |                                                         Access
Point
> 	        |        IP        |
+-----------------------------+
> |         IP       |
|       Relay                              |
> 	        |   ROHC      |
+----------------------------+
> |  ROHC       |                                                       |
|  PPPmux   |
> 	        |  PPPmux |
> +------------+                                                       |
Encaps         +------------+
> | Encaps     |                                                        |
|  IPtunn.     |
> |  IPtunn.  |
+---------------+------------+
> |  L2/L1       |		                                 |  L2/L1
|  L2/L1         |
> 	        |  L2/L1       |
+---------------+------------+
> |					 |
|
> 	        |
> |<------Wireless Access network-------->|
|<------
> Internet----------->|
> |        (WLAN, Satellite, ...)       		 |
|
> |
> 
> 
> 
> ------------------------
> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center
> Institute of Communications and Navigation | Satellite Networks |
> Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.
> Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |
> [email-masked] http://www.dlr.de/kn/institut/abteilungen/san
> 
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 20 Nov 2012 09:29:21 +0000

Hi Tomaso, Jose,

        I´m afraid I´m not able to view properly you ASCII picture, but if I´m
not misunderstanding you, you are proposing to have a header compression
(ROHC) end to end, while having multiplexing and tunneling after the
satellite/wireless link (through the LAN with several layer 3 hops or
through the Internet). So Jose, I think Tomaso is not proposing to
decompress ROCH in the access point, but in the Node B.
        Do you think that this would be more interesting than using TCMTF e2e?,
given that the AP will have to de-encapsulate the existing
multiplexing/tunneling method in wireless/satellite links, and encapsulate
using TCMTF in the other side. In terms of bandwidth for sure, but how
much? Do it compensate in terms of processing capacity?

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

On 19/11/12 20:49, "Jose Saldana" <[email-masked]> wrote:

>>Access

________________________________

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: <[email-masked]>
Date: Tue, 20 Nov 2012 12:07:58 +0000

Hi Fernando,

Yes you are right, the basic idea it to enable RoHC end-to-end (or even in a subpart of the whole network) and using tcmtf tunneling and multiplexing features only in the last segment of the network (e.g., from the AP to the end-users).
The point is that the Access Point, which can be regarded as a gateway in satellite networks, has to de-capsulate anyway the IP datagrams incoming over the satellite link. As such, I don't see much processing complexity on this node. On the other hand, the use of tcmtf on an e2e basis in this scenario is not really efficient, because the tunneling-multiplexing functions are in fact already provided by the encapsulation protocol. Over the satellite/wireless link. 
With this I don't mean that e2e tcmtf is never profitable, but the scenarios that include satellite/wireless access network certainly require an "adaptation" of tcmtf concepts, as described in my proposal. 

Regards,

Tomaso

------------------------ 

-----Original Message-----
From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2012 10:29 AM
To: [email-masked]; Cola, Tomaso de; [email-masked]
Cc: Berioli, Matteo; Brandt, Hartmut
Subject: Re: [tcmtf] Some thoughts about new scenarios for tcmtf

Hi Tomaso, Jose,

        I´m afraid I´m not able to view properly you ASCII picture, but if I´m not misunderstanding you, you are proposing to have a header compression
(ROHC) end to end, while having multiplexing and tunneling after the satellite/wireless link (through the LAN with several layer 3 hops or through the Internet). So Jose, I think Tomaso is not proposing to decompress ROCH in the access point, but in the Node B.
        Do you think that this would be more interesting than using TCMTF e2e?, given that the AP will have to de-encapsulate the existing multiplexing/tunneling method in wireless/satellite links, and encapsulate using TCMTF in the other side. In terms of bandwidth for sure, but how much? Do it compensate in terms of processing capacity?

Regards,

Fernando Pascual Blanco

On 19/11/12 20:49, "Jose Saldana" <[email-masked]> wrote:

>Tomaso,
>
>If I understand well, the idea is that tcmtf is not used in the 
>satellite link, but only  in the "Internet" part. So the "Access Point" 
>does not need to decompress the ROHC headers.
>
>draft-saldana-tsvwg-tcmtf-03. If you could provide some reasons 
>supporting this, it would be fine, I think.
>
>> De: [email-masked] [mailto:[email-masked]] En nombre 
>> de [email-masked] Enviado el: viernes, 16 de noviembre de 2012 
>> 16:31
>> Para: [email-masked]
>> As discussed some time ago, satellite and wireless access network can 
>> be attractive network scenarios where tcmtf principles can be exploited.
>> However, usual wireless and satellite encapsulation protocol (between 
>> IP and lower layers) already provide means to multiplexing and "tunneling"
>> compressed flows.
>> as it would introduce additional overhead, resulting in less benefits 
>>from  the bandwidth-saving point of view. Hence, we propose a 
>>deviation from  the tcmtf concepts, so that the access network 
>>(wireless or satellite)
>keeps
>>through ROHC (for example). The access point serving as "bridge" 
>>between  the access network and the second leg of the network (i.e. 
>>Internet)  implements a dual stack, with PPPmux and IP tunneling 
>>techniques, to  multiplex and tunnel the compressed flows coming from 
>>the access  network. The final destination will obviously implement a 
>>stack including  the three tcmtf ingredients (compression, 
>> saldana-tsvwg-tcmtf-03, we propose to dedicate an additional I-D to 
>>this  idea, where implications on mobility and security should be 
>>addressed as  well.
>>
>> What is your opinion?
>>
>> Best Regards,
>>
>> Tomaso
>>
>>
>>               Node B
>>
>>              +------------+
>> Node A
>>              | Appl.         |
>> +------------ +
>>              +------------+
>> | Appl.         |
>>                      | TCP/UDP |
>> +------------+
>>
>> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace 
>> Center Institute of Communications and Navigation | Satellite 
>> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 20 Nov 2012 13:48:52 +0000

Hi Tomaso,

        Although ROHC is end-to-end, headers will need to be decompressed within
the AP in order to know where to send the packets (for example whether to
send the packets through one TCMTF tunnel or another). The benefit of
tunnel packets while compressing them (as TCMTF does) is not decompressing
headers in every hop. So, the adaptation you are proposing is to apply
TCMTF concepts out of the satellite/wireless links, do you?

Regards,

Fernando Pascual Blanco

On 20/11/12 13:07, "[email-masked]" <[email-masked]> wrote:

>Hi Fernando,
>
>Yes you are right, the basic idea it to enable RoHC end-to-end (or even
>in a subpart of the whole network) and using tcmtf tunneling and
>multiplexing features only in the last segment of the network (e.g., from
>the AP to the end-users).
>The point is that the Access Point, which can be regarded as a gateway in
>satellite networks, has to de-capsulate anyway the IP datagrams incoming
>over the satellite link. As such, I don't see much processing complexity
>on this node. On the other hand, the use of tcmtf on an e2e basis in this
>scenario is not really efficient, because the tunneling-multiplexing
>functions are in fact already provided by the encapsulation protocol.
>Over the satellite/wireless link.
>With this I don't mean that e2e tcmtf is never profitable, but the
>scenarios that include satellite/wireless access network certainly
>require an "adaptation" of tcmtf concepts, as described in my proposal.
>
>Regards,
>
>Tomaso
>
>
>
>
>------------------------
>[email-masked]
>        I´m afraid I´m not able to view properly you ASCII picture, but
>if I´m not misunderstanding you, you are proposing to have a header
>compression
>        Do you think that this would be more interesting than using TCMTF
>e2e?, given that the AP will have to de-encapsulate the existing
>multiplexing/tunneling method in wireless/satellite links, and
>encapsulate using TCMTF in the other side. In terms of bandwidth for
>sure, but how much? Do it compensate in terms of processing capacity?
>
>Regards,
>
>Fernando Pascual Blanco
>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: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 21 Nov 2012 15:59:02 +0000

All,

I think Tomaso's suggestion could occur as a separate section in Jose's  draft (draft-saldana-tsvwg-tcmtf-03) for the case of where the (TCMTF) tunnel endpoints use a different multiplexing layer (where Jose has "PPPMUX or other mux protocols" in the draft).

However, tunnel endpoints are hard enough to specify .. and now you would need to know if there is a relay somewhere in-between the tunnel endpoints that uses a different multiplexing technique.

In other words, you would need to know EVEN MORE about the capability of possible intermediate nodes (in this case that a relay is possible between your TCMTF tunnel endpoints) . or perhaps decide if a relay is needed if the existing TCMTF tunnel endpoints do not use the same multiplexing layer (e.g., a "lossless transcode" function).

If we decide to add a section in Jose's draft, we would need to provide guidance concerning how the endpoints are either configured or negotiated. If we want TCMTF to be "simple" and "just configured" (e.g., on WAN edges) . then negotiation and possible insertion/use of a relay is a pretty big complication to the document. However, we SHOULD address this concern (how tunnel endpoints are found, how we ensure relays remain on the end-to-end tunnel path) in the document anyway!

Jose/Tomaso: Do you have thoughts on how the TCMTF endpoints negotiate the lower layers?

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 20, 2012 7:08 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tcmtf] Some thoughts about new scenarios for tcmtf

Hi Fernando,

Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] http://www.dlr.de/kn/institut/abteilungen/san 

-----Original Message-----
From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
Sent: Tuesday, November 20, 2012 10:29 AM
To: [email-masked]; Cola, Tomaso de; [email-masked]
Cc: Berioli, Matteo; Brandt, Hartmut
Subject: Re: [tcmtf] Some thoughts about new scenarios for tcmtf

Hi Tomaso, Jose,

Regards,

Fernando Pascual Blanco

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Mon, 26 Nov 2012 13:59:44 +0000

Hi All,

        Actually Jose proposed the idea of developing two new drafts: the
b)"Recommendations draft" and the c)"Dynamic Signaling Draft". That relay
between different tunneling, multiplexing or even compression capabilities
through the optimized path could be addressed to the c) draft as TCMTF
negotiation concepts in a multi-capability path. It should also be
mentioned in the original draft and recommended in the b) draft.
        For example, for the satellite scenario, it would not be necessary to
decompress ROHC within the Access Point, since it should only take packets
multiplexed and tunneled in a way (the existing and efficient
encapsulation protocols, which could also be adopted within the original
Jose´s draft as different tunnel and multiplex options), and
multiplex-tunnel them in another way (as Michael says, acting as a tunnel
and/or multiplex relay) without see layer 3 headers.

Regards,

Fernando Pascual Blanco

On 21/11/12 16:59, "Michael Ramalho (mramalho)" <[email-masked]> wrote:

>All,
>
>I think Tomaso's suggestion could occur as a separate section in Jose's
>draft (draft-saldana-tsvwg-tcmtf-03) for the case of where the (TCMTF)
>tunnel endpoints use a different multiplexing layer (where Jose has
>"PPPMUX or other mux protocols" in the draft).
>
>However, tunnel endpoints are hard enough to specify .. and now you would
>need to know if there is a relay somewhere in-between the tunnel
>endpoints that uses a different multiplexing technique.
>
>In other words, you would need to know EVEN MORE about the capability of
>possible intermediate nodes (in this case that a relay is possible
>between your TCMTF tunnel endpoints) . or perhaps decide if a relay is
>needed if the existing TCMTF tunnel endpoints do not use the same
>multiplexing layer (e.g., a "lossless transcode" function).
>
>If we decide to add a section in Jose's draft, we would need to provide
>guidance concerning how the endpoints are either configured or
>negotiated. If we want TCMTF to be "simple" and "just configured" (e.g.,
>on WAN edges) . then negotiation and possible insertion/use of a relay is
>a pretty big complication to the document. However, we SHOULD address
>this concern (how tunnel endpoints are found, how we ensure relays remain
>on the end-to-end tunnel path) in the document anyway!
>

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 26 Nov 2012 18:08:58 +0100

Hi, 

I am trying to get some light about this. First, let us try to know if the
picture is correct. If you put this in Courier letters, I think you can see
it correctly (I attach it as an image, just in case). Tomaso, is the picture
right?

Node A
Node B
+----------+
+------------+
| Appl.    |
| Appl.      |
+----------+
+------------+
| TCP/UDP  |
| TCP/UDP    |
+----------+
+------------+
|   IP     |                                  Access Point
|   IP       |
+----------+                             +----------------------+
+------------+
|  ROHC    |                             |       Relay          |
|   ROHC     |
+----------+                             +----------------------+
+------------+
|          |                             |          | PPPmux    |
|  PPPmux    |
| Encaps   |                             |  Encaps  +-----------+
+------------+
|          |                             |          |  IPtunn.  |
|  IPtunn.   |
+----------+	                         +----------+-----------+
+------------+
|  L2/L1   |                             |  L2/L1   |  L2/L1    |
|  L2/L1     |
+----------+                             +----------+-----------+
+------------+

           |                             |                      |
|
           |<--Wireless Access network-->|
|<------Internet-------->|
           |   (WLAN, Satellite, ...)    |                      |
|

So the first question is:

Tomaso, is there a single connection from Node A to Node B, or the Access
Point has to distinguish different flows? Are all packets travelling from A
to B?

If the answer is "Yes", then, as Fernando says, the AP does not need to
decompress/compress ROHC. It only needs to get a number of packets,
decapsulate them, and put them together into a multiplexed packet with
PPPMux.

I think we should first set this clear in order to advance.

Thanks,

Jose

> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
> Enviado el: lunes, 26 de noviembre de 2012 15:00
> Para: Michael Ramalho (mramalho); [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Asunto: Re: [tcmtf] Some thoughts about new scenarios for tcmtf
> 
> Hi All,
> 
mentioned in
> the original draft and recommended in the b) draft.
encapsulation
> protocols, which could also be adopted within the original Jose´s draft as
> different tunnel and multiplex options), and multiplex-tunnel them in
> another way (as Michael says, acting as a tunnel and/or multiplex relay)
> without see layer 3 headers.
> 
> Regards,
> 
> Fernando Pascual Blanco
> >However, tunnel endpoints are hard enough to specify .. and now you
> >would need to know if there is a relay somewhere in-between the tunnel
> >In other words, you would need to know EVEN MORE about the capability
> >of possible intermediate nodes (in this case that a relay is possible
> >negotiated. If we want TCMTF to be "simple" and "just configured"
> >(e.g., on WAN edges) . then negotiation and possible insertion/use of a
> >relay is a pretty big complication to the document. However, we SHOULD
> >address this concern (how tunnel endpoints are found, how we ensure
> >relays remain on the end-to-end tunnel path) in the document anyway!
> >
> >Jose/Tomaso: Do you have thoughts on how the TCMTF endpoints
> negotiate
> >the lower layers?
> >
> >Michael Ramalho
> >
> >multiplexing features only in the last segment of the network (e.g.,
> >from the AP to the end-users).
> >The point is that the Access Point, which can be regarded as a gateway
> >in satellite networks, has to de-capsulate anyway the IP datagrams
> >incoming over the satellite link. As such, I don't see much processing
> >complexity on this node. On the other hand, the use of tcmtf on an e2e
> >basis in this scenario is not really efficient, because the
> >tunneling-multiplexing functions are in fact already provided by the
> encapsulation protocol.
> Center
> >        Do you think that this would be more interesting than using
> >TCMTF e2e?, given that the AP will have to de-encapsulate the existing
> >>> As discussed some time ago, satellite and wireless access network
> >>>can  be attractive network scenarios where tcmtf principles can be
> >>>exploited.
> >>> However, usual wireless and satellite encapsulation protocol
> >>>(between  IP and lower layers) already provide means to multiplexing
> >>>and "tunneling"
> >>> compressed flows.
> >>> as it would introduce additional overhead, resulting in less
> >>>benefits from  the bandwidth-saving point of view. Hence, we propose
> >>>a deviation from  the tcmtf concepts, so that the access network
> >>>(wireless or satellite)
> >>keeps
|
> >>> | Encaps     |
|
> >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: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 27 Nov 2012 12:40:00 +0000

Jose,

        I think that the proposition is to adopt within the original draft what
you have described as "Encaps". If so, the optimized path will be the path
between node A and node B, and you can be sure that traffic within that
"Encaps" is destined to node B. Given that, you can suppose that the TCMTF
path is the path between A and B, having different tunnel/multiplex in
every scope (wireless and Internet), but maintaining the compress layer.
With dynamic TCMTF signalling, somehow, every scope in the path will
select the most optimal tunneling/multiplex method in every hope
(supposing that the Access Point is TCMTF-aware).

Regards,

Fernando Pascual Blanco

On 26/11/12 18:08, "Jose Saldana" <[email-masked]> wrote:

>>         For example, for the satellite scenario, it would not be
>>necessary
>to
>> >>> |  L2/L1       |                                              |
>>L2/L1

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 28 Nov 2012 10:34:36 +0100

Fernando,

If I understood well, the idea of Tomaso was this:

- The "left link" (wireless) between the satellite and the AP has its own
well-defined protocols.
- That protocols include RoHC.
- So we can use tcmtf in the "right link" (Internet) between the AP and the
destination through the Internet.
- In the AP we don't need to decompress-compress RoHC.

However, I don't really know if Tomaso wanted to propose this. Let's wait
for his response.

Thanks,

Jose

> Enviado el: martes, 27 de noviembre de 2012 13:40
> Para: [email-masked]; [email-masked]
> CC: [email-masked]
>         I think that the proposition is to adopt within the original draft
what you
> have described as "Encaps". If so, the optimized path will be the path
every
> scope (wireless and Internet), but maintaining the compress layer.
select
> the most optimal tunneling/multiplex method in every hope (supposing that
> the Access Point is TCMTF-aware).
> 
> Regards,
> 
> Fernando Pascual Blanco
> >I am trying to get some light about this. First, let us try to know if
> >the picture is correct. If you put this in Courier letters, I think you
> >can see it correctly (I attach it as an image, just in case). Tomaso,
> >is the picture right?
> >
> >Node A
> >Node B
> >+----------+
> >+------------+
> >| Appl.    |
> >| Appl.      |
> >+----------+
> >+------------+
> >| TCP/UDP  |
> >| TCP/UDP    |
> >+----------+
> >+------------+
> >|   IP     |                                  Access Point
> >|   IP       |
> >Tomaso, is there a single connection from Node A to Node B, or the
> >Access Point has to distinguish different flows? Are all packets
> >travelling from A to B?
> >
> >> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] Enviado el: lunes,
> 26
> >> de noviembre de 2012 15:00
> >> b)"Recommendations draft" and the c)"Dynamic Signaling Draft". That
> >>relay  between different tunneling, multiplexing or even compression
> >>capabilities  through the optimized path could be addressed to the c)
> >>draft as TCMTF  negotiation concepts in a multi-capability path. It
> >>should also be
> >mentioned in
> >> decompress ROHC within the Access Point, since it should only take
> >>packets  multiplexed and tunneled in a way (the existing and efficient
> >encapsulation
> >> protocols, which could also be adopted within the original Jose´s
> >>draft as  different tunnel and multiplex options), and
> >>multiplex-tunnel them in  another way (as Michael says, acting as a
> >>tunnel and/or multiplex relay)  without see layer 3 headers.
> >>
> >> Regards,
> >>
> >> Fernando Pascual Blanco
> >> On 21/11/12 16:59, "Michael Ramalho (mramalho)"
> <[email-masked]>
> >> wrote:
> >>
> >> >All,
> >> >
> >> >I think Tomaso's suggestion could occur as a separate section in
> >> >Jose's draft (draft-saldana-tsvwg-tcmtf-03) for the case of where
> >> >the (TCMTF) tunnel endpoints use a different multiplexing layer
> >> >(where Jose has "PPPMUX or other mux protocols" in the draft).
> >> >
> >> >would need to know if there is a relay somewhere in-between the
> >> >tunnel endpoints that uses a different multiplexing technique.
> >> >
> >> >In other words, you would need to know EVEN MORE about the
> >> >capability of possible intermediate nodes (in this case that a relay
> >> >is possible between your TCMTF tunnel endpoints) . or perhaps decide
> >> >if a relay is needed if the existing TCMTF tunnel endpoints do not
> >> >use the same multiplexing layer (e.g., a "lossless transcode"
function).
> >> >
> >> >If we decide to add a section in Jose's draft, we would need to
> >> >provide guidance concerning how the endpoints are either configured
> >> >or negotiated. If we want TCMTF to be "simple" and "just configured"
> >> >(e.g., on WAN edges) . then negotiation and possible insertion/use
> >> >of a relay is a pretty big complication to the document. However, we
> >> >SHOULD address this concern (how tunnel endpoints are found, how we
> >> >ensure relays remain on the end-to-end tunnel path) in the document
> anyway!
> >> >
> >> >Yes you are right, the basic idea it to enable RoHC end-to-end (or
> >> >even in a subpart of the whole network) and using tcmtf tunneling
> >> >and multiplexing features only in the last segment of the network
> >> >(e.g., from the AP to the end-users).
> >> >The point is that the Access Point, which can be regarded as a
> >> >gateway in satellite networks, has to de-capsulate anyway the IP
> >> >datagrams incoming over the satellite link. As such, I don't see
> >> >much processing complexity on this node. On the other hand, the use
> >> >of tcmtf on an e2e basis in this scenario is not really efficient,
> >> >because the tunneling-multiplexing functions are in fact already
> >> >provided by the
> >> encapsulation protocol.
> >> >        I´m afraid I´m not able to view properly you ASCII picture,
> >> >but if I´m not misunderstanding you, you are proposing to have a
> >> >header compression
> >> >satellite/wireless link (through the LAN with several layer 3 hops
> >> >or through the Internet). So Jose, I think Tomaso is not proposing
> >> >to decompress ROCH in the access point, but in the Node B.
> >> >TCMTF e2e?, given that the AP will have to de-encapsulate the
> >> >existing multiplexing/tunneling method in wireless/satellite links,
> >> >and encapsulate using TCMTF in the other side. In terms of bandwidth
> >> >for sure, but how much? Do it compensate in terms of processing
> capacity?
> >> >
> >> >Regards,
> >> >
> >> >Fernando Pascual Blanco
> >> >>>(between  IP and lower layers) already provide means to
> >> >>>multiplexing and "tunneling"
> >> >>> compressed flows.
> >> >>>benefits from  the bandwidth-saving point of view. Hence, we
> >> >>>propose a deviation from  the tcmtf concepts, so that the access
> >> >>>network (wireless or satellite)
> >> >>keeps
> >> >>> untouched the protocol stack allowing the compression of data
> >> >>>flows through ROHC (for example). The access point serving as
> "bridge"
> >> >>>techniques, to  multiplex and tunnel the compressed flows coming
> >> >>>from the access  network. The final destination will obviously
> >> >>>implement a stack including  the three tcmtf ingredients
> >> >>>(compression, multiplexing, tunneling).
> >> >>>
> >> >>> As this idea substantially deviates from the concepts presented
> >> >>>in
> >> >>>draft-
> >> >>> saldana-tsvwg-tcmtf-03, we propose to dedicate an additional I-D
> >> >>>Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso
> de
> >> >>>Cola, Ph.D.
> >> >consultar nuestra política de envío y recepción de correo
> >> >electrónico en el enlace situado más abajo.

---

From: <[email-masked]>
Date: Wed, 28 Nov 2012 09:37:58 +0000

Jose,

Yes you are right, the idea is to have ROHC on the wireless segment, which already implement specific functionalities for multiplexing as part of the encapsulation protocol. The second leg of the network is instead using the tcmtf functions without ROHC, which is instead applied e2e (or at least until the end of the IP tunnel)

Regards,

Tomaso

------------------------ 

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]] 
Sent: Wednesday, November 28, 2012 10:35 AM
To: 'FERNANDO PASCUAL BLANCO'; Cola, Tomaso de
Cc: [email-masked]
Subject: RE: [tcmtf] Some thoughts about new scenarios for tcmtf

Fernando,

- The "left link" (wireless) between the satellite and the AP has its own well-defined protocols.
- That protocols include RoHC.
- So we can use tcmtf in the "right link" (Internet) between the AP and the destination through the Internet.
- In the AP we don't need to decompress-compress RoHC.

However, I don't really know if Tomaso wanted to propose this. Let's wait for his response.

Thanks,

Jose

> De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] Enviado el: martes, 27 
> de noviembre de 2012 13:40
what you
> between node A and node B, and you can be sure that traffic within 
> that "Encaps" is destined to node B. Given that, you can suppose that 
> the TCMTF path is the path between A and B, having different 
> tunnel/multiplex in
every
select
> the most optimal tunneling/multiplex method in every hope (supposing 
> that the Access Point is TCMTF-aware).
> 
> Regards,
> 
> Fernando Pascual Blanco
> >I am trying to get some light about this. First, let us try to know 
> >if the picture is correct. If you put this in Courier letters, I 
> >think you can see it correctly (I attach it as an image, just in 
> >case). Tomaso, is the picture right?
> >
> >Node A
> >Node B
> >+----------+
> >+------------+
> >| Appl.    |
> >| Appl.      |
> >+----------+
> >+------------+
> >| TCP/UDP  |
> >| TCP/UDP    |
> >+----------+
> >+------------+
> >|   IP     |                                  Access Point
> >|   IP       |
> >If the answer is "Yes", then, as Fernando says, the AP does not need 
> >to decompress/compress ROHC. It only needs to get a number of 
> >packets, decapsulate them, and put them together into a multiplexed 
> >packet with PPPMux.
> >
> >>capabilities  through the optimized path could be addressed to the 
> >>c) draft as TCMTF  negotiation concepts in a multi-capability path. 
> >>It should also be
> >mentioned in
> >> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F 
> >> +34913128779 M +34682005168 [email-masked]
> >>
> >>
> >>
> >>
> >> >However, tunnel endpoints are hard enough to specify .. and now 
> >> >you would need to know if there is a relay somewhere in-between 
> >> >the tunnel endpoints that uses a different multiplexing technique.
> >> >
> >> >capability of possible intermediate nodes (in this case that a 
> >> >relay is possible between your TCMTF tunnel endpoints) . or 
> >> >perhaps decide if a relay is needed if the existing TCMTF tunnel 
> >> >endpoints do not use the same multiplexing layer (e.g., a "lossless transcode"
function).
> >> >provide guidance concerning how the endpoints are either 
> >> >configured or negotiated. If we want TCMTF to be "simple" and "just configured"
> >> >of a relay is a pretty big complication to the document. However, 
> >> >we SHOULD address this concern (how tunnel endpoints are found, 
> >> >how we ensure relays remain on the end-to-end tunnel path) in the 
> >> >document
> anyway!
> >> >
> >> >much processing complexity on this node. On the other hand, the 
> >> >use of tcmtf on an e2e basis in this scenario is not really 
> >> >efficient, because the tunneling-multiplexing functions are in 
> >> >fact already provided by the
> >> encapsulation protocol.
> >> >        I´m afraid I´m not able to view properly you ASCII 
> >> >picture, but if I´m not misunderstanding you, you are proposing to 
> >> >have a header compression
> >> >(ROHC) end to end, while having multiplexing and tunneling after 
> >> >the satellite/wireless link (through the LAN with several layer 3 
> >> >hops or through the Internet). So Jose, I think Tomaso is not 
> >> >proposing to decompress ROCH in the access point, but in the Node B.
> >> >        Do you think that this would be more interesting than 
> >> >using TCMTF e2e?, given that the AP will have to de-encapsulate 
> >> >the existing multiplexing/tunneling method in wireless/satellite 
> >> >links, and encapsulate using TCMTF in the other side. In terms of 
> >> >bandwidth for sure, but how much? Do it compensate in terms of 
> >> >processing
> capacity?
> >> >
> >> >Regards,
> >> >
> >> >Fernando Pascual Blanco
> >> >Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F 
> >> >+34913128779 M +34682005168 [email-masked]
> >> >
> >> >
> >> >
> >> >
> >> >>> As discussed some time ago, satellite and wireless access 
> >> >>>network can  be attractive network scenarios where tcmtf 
> >> >>>principles can be exploited.
> >> >>> saldana-tsvwg-tcmtf-03, we propose to dedicate an additional 
> >> >>>I-D to this  idea, where implications on mobility and security 
> >> >>>should be addressed as  well.
> >> >>>
> >> >>> What is your opinion?
> >> >>>
> >> >>> Best Regards,
> >> >>>
> >> >>> Tomaso
> >> >>>
> >> >>>
> >> >>>               Node B
> >> >>>
> >> >>>              +------------+
> >> >>> Node A
> >> >>>              | Appl.         |
> >> >>> +------------ +
> >> >>>              +------------+
> >> >>> | Appl.         |
> >> >>>                      | TCP/UDP |
> >> >>> +------------+
> >> >>>
> >> >This message is intended exclusively for its addressee. We only 
> >> >send and receive email on the basis of the terms set out at:
> >> This message is intended exclusively for its addressee. We only 
> >> send and receive email on the basis of the terms set out at: