Re: [lisp] Bandwidth savings with LISP

["Jose Saldana" <[e-mail]>]

Hi, Anton.

Comments inline

> -----Mensaje original-----
> De: Anton Smirnov [mailto:[e-mail]]
> Enviado el: viernes, 01 de julio de 2016 14:34
> Para: Jose Saldana <[e-mail]>; [e-mail]
> CC: 'José Ruiz Mas' <[e-mail]>
> Asunto: Re: [lisp] Bandwidth savings with LISP
> 
>     Hi Jose,
>     marking packet as compressed is one thing - necessary but not sufficient.
> Backward compatibility includes considerations like how ITR would decide which
> encapsulation to use while sending out packet for a particular remote EID (i.e. that
> ETR will be able to decapsulate it).

So the question is how does a border router know if the router in the other side implements the multiplexing mechanism, right?

We talked about this in a research paper (http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc.pdf, section III). I copy a couple of paragraphs from the paper (TCMTF means Tunnelling, Compressing and Multiplexing Traffic Flows):

	"In the context of the present work it is not relevant the
	specific architecture of the mapping system, rather it is
	important to understand how the LISP signaling (i.e., mappings
	and their publication and retrieval) can be enriched to carry
	meta-information concerning whether or not to multiplex
	packets destined to a block of EIDs and whether or not and
	how to compress their headers. To this end, the LISP Canonical
	Address Format (LCAF) [15] can be used."
	(...)
	"Because of the above-mentioned flexibility, it is easy to
	understand that LCAF allows effective encoding of the
	information concerning which traffic has to be multiplexed
	over a LISP tunnel, based on several parameters (e.g., source
	and destination addresses, ToS, application, etc.). Other metainformation
	(e.g., the header compression mechanism to use)
	can also be associated. It is out of scope of the present paper to
	provide the exact encoding of the different TCMTF
	mechanisms in an LCAF Record, since it has no influence on
	the gains provided by the LISP framework and on the analysis
	provided. The key point is that such a framework does not only
	provide a standard format to express what to multiplex and
	compress, but also provides a signaling mechanism thanks to
	the already defined mapping system. This signaling mechanism
	can be applied to start or adapt the multiplexing and
	compression procedures on demand, according to traffic or
	other conditions at each endpoint, providing dynamic capacity
	sharing between the two EIDs. Actually, by leveraging on the
	LCAF standard mechanism, it is possible to use the already
	deployed LISP-DDT mapping system as signaling
	infrastructure, hence, providing ready to use signaling
	resources at no further costs (either design, deployment, or
	operational costs). The use of LISP introduces an initial query
	delay during which, when no mapping is locally available,
	TCMTF techniques cannot be applied, however, packets can be
	still be forwarded natively, hence causing no harm."

The paper was mainly about bandwidth savings, so we only said that this could be achieved. This mechanisms have not yet been implemented. Our current implementation simply assumes that both ends "talk" Simplemux. Obviously, if the group finds these savings interesting, this would have to be studied and tested.


>     Also, you should investigate and document the practical use case, i.e. what is the
> likelihood of being able to compress packets in real-world traffic patterns, what it
> means for latencies (protocols using smaller packets tend to be more sensitive to
> delay and jitter) and so on.

We have identified some use cases, and we have studied the effect of the additional latencies in different services. You can have a look to these papers:

a)
http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc.pdf, talks about VoIP, games and ACKs.

b)
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6658664 includes some other use cases (they are not LISP-related, but the effect of delays would be the same)

c)
http://diec.unizar.es/~jsaldana/personal/chicago_CIT2015_in_proc.pdf this one includes a study with a real traffic trace obtained from the CAIDA database. (The CAIDA UCSD equinix-chicago- 20150219-130000, https://data.caida.org/datasets/passive-2015/equinix-chicago/20150219-130000.UTC/equinix-chicago.dirA.20150219-125911.UTC.anon.pcap.gz)

	"An implementation is used to carry out some tests
	with real traffic, showing significant improvements: 46% of the
	bandwidth can be saved when compressing voice traffic; the
	reduction in terms of packets per second in an Internet trace can
	be up to 50%. In wireless networks, packet grouping results in a
	significantly improved use of air time."



In addition, Dino has sent an e-mail with another use case: https://www.ietf.org/mail-archive/web/lisp/current/msg06471.html. We can also think about it.


>     Without those bits the idea is a bit detached.
> 
> Anton

Thanks a lot!

Jose

> 
> 
> On 07/01/2016 01:38 PM, Jose Saldana 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
> >>>
> >