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

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

|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). Combining it with multiplexing the entire packets could provide significant reduction in the header overhead, especially for IPv6, I think.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of Dan Wing (dwing)
|Sent: Monday, July 01, 2013 10:25 PM
|To: [e-mail]
|Cc: [e-mail]; [e-mail]
|Subject: Re: [tcmtf] Answers to possible questions in the BOF
|
|
|On Jun 28, 2013, at 1:57 AM, [e-mail] 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 <[e-mail]> ha escrito:
|>
|>>
|>> On Jun 26, 2013, at 3:49 AM, Jose Saldana <[e-mail]> 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: [e-mail] [mailto:[e-mail]] En  nombre de Jose Saldana
|>>> Enviado el: lunes, 24 de junio de 2013 13:00
|>>> Para: [e-mail]
|>>> 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
|>>> [e-mail]
|>>> https://www.ietf.org/mailman/listinfo/tcmtf
|>>
|>>
|>
|>
|>
|
|_______________________________________________
|tcmtf mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/tcmtf