Re: [lisp] [5gangip] Bandwidth savings with LISP

Hey Dino,

Queuing also happens when a UE is has been idle for a while and is being paged. 

On the header size issue, one of the complaints I've made about ICN/CCN etc. and 5G is the increased header sizes and the impact that this has on the most expensive resource (by a wide margin), the RF spectrum. 

Not much point optimizing all the relatively cheap wired links if the tax then goes up on the incredibly expensive wireless links.

Finding a way to properly map multicast/broadcast to the natural RF multicast would seem like a smart thing to do to extend some of the bandwidth savings protocols like ICN/CCN give but there are challenges with this as each UE may have a different RF encoding (due to different channel conditions) and therefore require separate copies anyway.

Cheers

Peter

-----Original Message-----
From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Dino Farinacci
Sent: Friday, July 01, 2016 1:06 PM
To: Jose Saldana
Cc: 5gangip@ietf.org; José Ruiz Mas; LISP mailing list list; Anton Smirnov
Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP

So I have been thinking about a compelling use-case for LISP header-compression and the super-framing feature (sorry for using my own term).

I have been told that the Radio Access Network (RAN) tends to be sensitive to overlay solutions due to large headers. I have also heard that there seems to be queuing behavior for the base-stations that send to UEs (i.e. phones). The fact that queuing is happening while waiting for a handoffs to occur can be a good opportunity to pack IP packets into super-frames to send over the RAN.

Using this solution means the eNodeB (base-station) and the UE (phone) would have to run LISP. I would like to hear comments from the WG. I have copied 5gangip to see if they have opinions.

Dino

> On Jul 1, 2016, at 4:38 AM, Jose Saldana <jsaldana@unizar.es> wrote:
> 
> Hi again, Anton.
> 
> I have just uploaded a new presentation including more ideas and also a section about backward compatibility:
> 
> http://es.slideshare.net/josemariasaldana/header-compression-and-multi
> plexing-in-lisp
> 
> BR and thanks,
> 
> Jose
> 
>> -----Mensaje original-----
>> De: Anton Smirnov [mailto:asmirnov@cisco.com] Enviado el: jueves, 23 
>> de junio de 2016 17:54
>> Para: Jose Saldana <jsaldana@unizar.es>; lisp@ietf.org
>> CC: 'José Ruiz Mas' <jruiz@unizar.es>
>> Asunto: Re: [lisp] Bandwidth savings with LISP
>> 
>>    Hi Jose,
>>    there is a theoretical aspect of the work (it's curious) and then 
>> there is a practical one. For the latter one - section "Backward 
>> compatibility" is conspicuously missing from the document. On the 
>> first glance, it looks like backward compatibility of the solution was not investigated. Is this correct?
>> 
>> Anton
>> 
>> 
>> On 06/23/2016 11:11 AM, Jose Saldana wrote:
>>> Hi all,
>>> 
>>> As you may know, we recently submitted a draft
>> (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/) 
>> with a proposal allowing bandwidth and pps reductions.
>>> 
>>> The idea is to send together a number of small packets, which are in 
>>> the buffer of
>> an ITR and have the same ETR as destination, into a single packet. 
>> Therefore, they will share a single LISP header. And this can be 
>> combined with ROHC (header compression).
>>> 
>>> We have a running implementation, based on LISPMob 
>>> (https://github.com/Simplemux/lispmob-with-simplemux), which we have 
>>> used to run some tests
>>> 
>>> This is a summary of the results.
>>> 
>>> - When small packets (100 bytes) are sent, up to 63% of throughput 
>>> increase can
>> be observed (in our example, we pass from 550kbps to 910kbps).
>>> 
>>> - In the case of securing the LISP tunnel with IPSec, the increase 
>>> can be 935
>> (from 470kbps to 870kbps).
>>> 
>>> You can find more detailed information in this presentation:
>>> http://es.slideshare.net/josemariasaldana/header-compression-and-mul
>>> ti
>>> plexing-in-lisp
>>> 
>>> Your feedback will be highly appreciated.
>>> 
>>> Best regards,
>>> 
>>> The authors
>>> 
>>>> -----Mensaje original-----
>>>> De: lisp [mailto:lisp-bounces@ietf.org] En nombre de Jose Saldana 
>>>> Enviado el: miércoles, 04 de mayo de 2016 18:41
>>>> Para: lisp@ietf.org
>>>> CC: 'Jose Ruiz Mas' <jruiz@unizar.es>
>>>> Asunto: [lisp] New draft posted:
>>>> draft-saldana-lisp-compress-mux-00.txt
>>>> 
>>>> Hi all,
>>>> 
>>>> We have just posted this draft
>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp-
>>>> compress-mux/.
>>>> 
>>>>               Header compression and multiplexing in LISP
>>>>                    draft-saldana-lisp-compress-mux-00
>>>> 
>>>> Abstract
>>>> 
>>>>    When small payloads are transmitted through a packet-switched
>>>>    network, the resulting overhead may result significant.  This is
>>>>    stressed in the case of LISP, where a number of headers are prepended
>>>>    to a packet, as new headers have to be added to each packet.
>>>> 
>>>>    This document proposes to send together a number of small packets,
>>>>    which are in the buffer of a ITR, having the same ETR as destination,
>>>>    into a single packet.  Therefore, they will share a single LISP
>>>>    header, and therefore bandwidth savings can be obtained, and a
>>>>    reduction in the overall number of packets sent to the network can be
>>>>    achieved.
>>>> 
>>>> A running implementation can be found here:
>>>> https://github.com/Simplemux/lispmob-with-simplemux. I has been 
>>>> built as a fork of lispmob.
>>>> 
>>>> The idea is very similar to what was published in this paper:
>>>> http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc.
>>>> pd
>>>> f
>>>> 
>>>> Your feedback about the draft will be appreciated.
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> Jose Saldana
>>>> Julián Fernández Navajas
>>>> José Ruiz Mas
>>>> 
>>>>> -----Mensaje original-----
>>>>> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
>>>>> Enviado
>>>>> el: miércoles, 04 de mayo de 2016 18:20
>>>>> Para: Jose Ruiz Mas <jruiz@unizar.es>; Jose Saldana 
>>>>> <jsaldana@unizar.es>; Julian Fernandez Navajas <navajas@unizar.es>
>>>>> Asunto: New Version Notification for 
>>>>> draft-saldana-lisp-compress-mux-00.txt
>>>>> 
>>>>> 
>>>>> A new version of I-D, draft-saldana-lisp-compress-mux-00.txt
>>>>> has been successfully submitted by Jose Saldana and posted to the 
>>>>> IETF repository.
>>>>> 
>>>>> Name:		draft-saldana-lisp-compress-mux
>>>>> Revision:	00
>>>>> Title:		Header compression and multiplexing in LISP
>>>>> Document date:	2016-05-04
>>>>> Group:		Individual Submission
>>>>> Pages:		8
>>>>> URL:
>>>>> https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress-m
>>>>> ux
>>>>> -
>>>>> 00.txt
>>>>> Status:
>>>>> https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/
>>>>> Htmlized:
>>>>> https://tools.ietf.org/html/draft-saldana-lisp-compress-mux-00
>>>>> 
>>>>> 
>>>>> Abstract:
>>>>>    When small payloads are transmitted through a packet-switched
>>>>>    network, the resulting overhead may result significant.  This is
>>>>>    stressed in the case of LISP, where a number of headers are prepended
>>>>>    to a packet, as new headers have to be added to each packet.
>>>>> 
>>>>>    This document proposes to send together a number of small packets,
>>>>>    which are in the buffer of a ITR, having the same ETR as destination,
>>>>>    into a single packet.  Therefore, they will share a single LISP
>>>>>    header, and therefore bandwidth savings can be obtained, and a
>>>>>    reduction in the overall number of packets sent to the network can be
>>>>>    achieved.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Please note that it may take a couple of minutes from the time of 
>>>>> submission until the htmlized version and diff are available at 
>>>>> tools.ietf.org.
>>>>> 
>>>>> The IETF Secretariat
>>>> 
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
5gangip mailing list
5gangip@ietf.org
https://www.ietf.org/mailman/listinfo/5gangip