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

[PEDRO ANDRES ARANDA GUTIERREZ <[e-mail]>]

This is why I’m proposing to move the processing as close as possible to the RAN using SFC… Well, or at least that’s another ingredient in the cake …

---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ Zurbarán,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler



-----Mensaje original-----
De: 5gangip <[e-mail]> en nombre de Jose Saldana <[e-mail]>
Fecha: lunes, 4 de julio de 2016, 13:50
Para: 'Dino Farinacci' <[e-mail]>
CC: "[e-mail]" <[e-mail]>, 'José Ruiz Mas' <[e-mail]>, 'LISP mailing list list' <[e-mail]>, 'Anton Smirnov' <[e-mail]>
Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP

Hi, Dino.

> -----Mensaje original-----
> De: Dino Farinacci [mailto:[e-mail]]
> Enviado el: viernes, 01 de julio de 2016 19:06
> Para: Jose Saldana <[e-mail]>
> CC: Anton Smirnov <[e-mail]>; LISP mailing list list <[e-mail]>;
> José Ruiz Mas <[e-mail]>; [e-mail]
> Asunto: Re: [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).

We have also previously thought on the potential utility of multiplexing in mobility scenarios.

For example, in PMIPv6 (standardized by the concluded IETF NETLMM Working Group), some tunnels are created between the Local Mobility Anchor (LMA, running in the P-GW) and the Mobile Access Gateway (MAG, running in the Serving Gateway). See the scheme in
http://openairinterface.eurecom.fr/openairfiles/DOCS.pmipv6/html/html/main.html. Perhaps multiplexing in those tunnels could make sense, as they include the traffic of many mobile nodes. The same tunnel is used for m mobiles (a 1:m relation, see http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4492976&tag=1).

>
> 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.

So what you propose is to take the packets waiting in the queue, and to aggregate them into bigger ones, before sending them to the mobile node right?

Could this fit with other use case? In http://research.cisco.com/pdfs/LISP-MN%20mobile%20networking%20through%20LISP.pdf
(page 9), a LISP-based mobility scheme is explained in detail:

        In this section we describe the handover process in LISP-MN. When a MN
        changes its attachment it regains connectivity in a new subnetwork. It first
        obtains a new RLOC and, as described in section 2.3.1, it notifies the new
        EID-to-RLOC binding to its Map-Server. The MN has to update also all the
        bindings stored in the Map-Cache of the peers, either routers or nodes, with
        which it is communicating. In order to do it uses the special signalling message
        called Solicit-Map-Request (SMR). The reception of such message triggers a
        Map-Request to refresh the binding (...).

Would it make sense to also multiplex packets waiting before the EID-to-RLOC binding is updated?

>
> 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
>

Thanks!

Jose
PS: If you could detail a bit more the use case you are talking about, it would be fine.


> > On Jul 1, 2016, at 4:38 AM, Jose Saldana <[e-mail]> 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:[e-mail]] Enviado el: jueves, 23
> >> de junio de 2016 17:54
> >> Para: Jose Saldana <[e-mail]>; [e-mail]
> >> CC: 'José Ruiz Mas' <[e-mail]>
> >> 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:[e-mail]] En nombre de Jose Saldana
> >>>> Enviado el: miércoles, 04 de mayo de 2016 18:41
> >>>> Para: [e-mail]
> >>>> CC: 'Jose Ruiz Mas' <[e-mail]>
> >>>> 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: [e-mail] [mailto:[e-mail]]
> >>>>> Enviado
> >>>>> el: miércoles, 04 de mayo de 2016 18:20
> >>>>> Para: Jose Ruiz Mas <[e-mail]>; Jose Saldana
> >>>>> <[e-mail]>; Julian Fernandez Navajas <[e-mail]>
> >>>>> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >>>
> >>> _______________________________________________
> >>> lisp mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >
> > _______________________________________________
> > lisp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lisp
>


_______________________________________________
5gangip mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/5gangip



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição