Re: [tcmtf] Answers to possible questions in the BOF

On Jul 3, 2013, at 11:51 AM, Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> wrote:

> |However, if there are a bunch of IPsec packets sharing a common path, 
> |I could see them being successfully multiplexed into one larger packet 
> |at one tunnel endpoint and then de-multiplexed at the other tunnel endpoint.  
> |This can provide a packet per second reduction.  I don't think there are
> |enough bytes in an IPsec header to bother trying to do IPsec header 
> |compression (SPI and sequence number are only 64 bits).
> 
> Actually, RFC5856 describes how ROHC can be used over IPSec (ROHCoIPsec).

My read of it was:  apply ROHC at the endpoint ("inner headers") and then do IPsec.  That is, compress and then encrypt.

-d

> Combining it with multiplexing the entire packets could provide significant reduction in the header overhead, especially for IPv6, I think.
> 
> Muthu
> 
> |-----Original Message-----
> |From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of Dan Wing (dwing)
> |Sent: Monday, July 01, 2013 10:25 PM
> |To: jltornos@unizar.es
> |Cc: tcmtf@ietf.org; jsaldana@unizar.es
> |Subject: Re: [tcmtf] Answers to possible questions in the BOF
> |
> |
> |On Jun 28, 2013, at 1:57 AM, jltornos@unizar.es wrote:
> |
> |> Hi all,
> |>
> |> Few days ago Julian talked about TCM-TF's security and now I've read in the link included by Dan,
> |saying that the gain obtained when multiplexing Ipsec-encrypted packets is 20-to-1. We have been
> |looking for more information about this issue and thinking about a way to reduce the needed  bandwidth
> |in IPsec flows.
> |>
> |> The main idea is to find a way to change the authentication of the individual packets and merge all
> |of them in a unique authentication. Thus, instead of using 20 IPsec tunnels, we would have a single
> |tunnel including 20 flows. Is this something similar than how Cisco gets the improvement?
> |
> |We would not be able to change IPsec any more than we could change TCP, so I would not look at how to
> |change IPsec authentication.
> |
> |However, if there are a bunch of IPsec packets sharing a common path, I could see them being
> |successfully multiplexed into one larger packet at one tunnel endpoint and then de-multiplexed at the
> |other tunnel endpoint.  This can provide a packet per second reduction.  I don't think there are
> |enough bytes in an IPsec header to bother trying to do IPsec header compression (SPI and sequence
> |number are only 64 bits).
> |
> |-d
> |
> |
> |>
> |> José Luis
> |>
> |>
> |>
> |> Dan Wing <dwing@cisco.com> ha escrito:
> |>
> |>>
> |>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <jsaldana@unizar.es> wrote:
> |>>
> |>>> Question 4: Is TCM-TF interesting for the Industry? Should the IETF  standardize this?
> |>>>
> |>>> Answer:
> |>>>
> |>>> 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP  traffic. So if RFC4170 was
> |interesting, why not updating it?
> |>>>
> |>>> 2) TCM-TF can be useful in order to save bandwidth in many cases:
> |>>>
> |>>> - Aggregation network of *network operators*: We are saving  bandwidth by optimizing and putting
> |together traffic flows. Is this  interesting for a network operator? What about overprovisioning?  The
> |idea is that there are places and moments in which a number of  flows based on small packets are in
> |the same place and at the same  moment. Then, TCM-TF can be applied in order to provide  flexibility.
> |We are not optimizing the overall Internet traffic, we  are optimizing specific flows with very tight
> |delay requirements,  which network operators have to take care of in a special way.
> |>>> www.huawei.com/ilink/en/download/HW_193034
> |>>>
> |>>> - *End to end* optimization: Nowadays, many appliances are used to  connect remote offices of the
> |same company (creating a VPN). So if  a tunnel exists, why not optimizing this traffic when possible?
> |We  would save bandwidth in the access network, where it can be scarce.
> |>>>
> |>>> - Wireless and satellite scenarios.
> |>>
> |>> "Cisco adds IP multiplexing to mobile satellite package", April  2012,
> |http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.html
> |>>
> |>>
> |>>
> |>>>
> |>>>
> |>>> Any other thoughts? Any other scenarios in mind? Potential beneficiaries?
> |>>
> |>> Some networks, today, use cRTP (RFC2508) on their access links.   This gives bandwidth savings on
> |the access link, but consumes  considerable CPU horsepower on the aggregation router (to perform
> |cRTP), but provides no bandwidth savings across the network core.   If, instead, the bandwidth could
> |be saved on the access link, across  the core, and on the far-end access link -- all without the CPU
> |impact on the aggregation router -- it is a considerable win.
> |>>
> |>> -d
> |>>
> |>>
> |>>
> |>>>
> |>>>
> |>>> Jose
> |>>>
> |>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En  nombre de Jose Saldana
> |>>> Enviado el: lunes, 24 de junio de 2013 13:00
> |>>> Para: tcmtf@ietf.org
> |>>> Asunto: [tcmtf] Answers to possible questions in the BOF
> |>>>
> |>>> I would like to start a thread about possible questions people may  ask in the BOF. Obviously, we
> |also need answers, so we should  cooperate.
> |>>>
> |>>> This is different from the "questions to ask in the BOF". This will  be discussed separately.
> |>>>
> |>>> Thanks!
> |>>>
> |>>> Jose
> |>>>
> |>>> _______________________________________________
> |>>> 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