Subject: [lisp] Bandwidth savings with LISP

From: "Jose Saldana" <[email-masked]>
Date: Thu, 23 Jun 2016 11:11:29 +0200

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-multiplexing-in-lisp

Your feedback will be highly appreciated.

Best regards,

The authors

> -----Mensaje original-----
> De: lisp [mailto:[email-masked]] En nombre de Jose Saldana
> Enviado el: miércoles, 04 de mayo de 2016 18:41
> Para: [email-masked]
> CC: 'Jose Ruiz Mas' <[email-masked]>
> 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.pdf
>
> Your feedback about the draft will be appreciated.
>
> Thanks in advance,
>
> Jose Saldana
> Julián Fernández Navajas
> José Ruiz Mas
>
> > -----Mensaje original-----
> > De: [email-masked] [mailto:[email-masked]] Enviado
> > el: miércoles, 04 de mayo de 2016 18:20
> > Para: Jose Ruiz Mas <[email-masked]>; Jose Saldana
> > <[email-masked]>; Julian Fernandez Navajas <[email-masked]>
> > 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-mux-
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 23 Jun 2016 17:53:48 +0200

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

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 24 Jun 2016 09:49:10 +0200

Hi Anton,

This is currently an idea to be explored. We have been able to run it, including some tweaks in the LISPMob implementation.

It includes three different options:

     2.1.  Basic multiplexing method 
     2.2.  Multiplexing method based on Simplemux  
     2.3.  Header compression and multiplexing method  

2.1. The "Basic multiplexing method" may probably have some backward compatibility issues. The draft says this (although this is a preliminary idea):

   One of the free bits in the LISP header should be used to flag the
   fact that more than a single packet is included in the encapsulated
   one. 

In fact, when we tested this (i.e. putting two packets instead of one after the LISP header) in LISPMob, it worked, but it was just because the implementation checked if there were more packets.

2.2 and 2.3 would also need some tweaks:

   In this case, a port number different from 4341 should be used in the
   UDP header preceding the LISP header, in order to indicate that the
   protocol inside the LISP header is not IP but Simplemux.

One thing we would want to discuss in the list is if these tweaks are easy to deploy, and/or if they are the most convenient ones.

Thanks a lot for your comments,

Jose 

> De: Anton Smirnov [mailto:[email-masked]]
> Enviado el: jueves, 23 de junio de 2016 17:54
> Para: Jose Saldana <[email-masked]>; [email-masked]
> CC: 'José Ruiz Mas' <[email-masked]>
> 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
> 
> 
> > 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
> >
> > - 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).
> >
> > You can find more detailed information in this presentation:
> > http://es.slideshare.net/josemariasaldana/header-compression-and-multi
> > plexing-in-lisp
> >
> >> https://github.com/Simplemux/lispmob-with-simplemux. I has been built
> >> as a fork of lispmob.
> >>
> >>> has been successfully submitted by Jose Saldana and posted to the
> >>> IETF repository.
> >>>