Hi Anton and José,
Regarding how the ITR and ETR will be able to encapsulate and to
decapsulate the packets, one option is that this information could be at
the level of application of the packets. Therefore, it would be
transparent to LISP.
A solution to avoid using marked packets is to use a different port to
4341, i.e. 4343. All the data in this port will be muliplexed.
By last, the latency would be bounded at the mux configuration, in order
to maintain quality of service without requiring aditional research.
Julián
El 01/07/2016 a las 14:34, Anton Smirnov escribió:
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).
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.
Without those bits the idea is a bit detached.
Anton
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-multiplexing-in-lisp
BR and thanks,
Jose
-----Mensaje original-----
De: Anton Smirnov [mailto:[email protected]]
Enviado el: jueves, 23 de junio de 2016 17:54
Para: Jose Saldana <[email protected]>; [email protected]
CC: 'José Ruiz Mas' <[email protected]>
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-multi
plexing-in-lisp
Your feedback will be highly appreciated.
Best regards,
The authors
-----Mensaje original-----
De: lisp [mailto:[email protected]] En nombre de Jose Saldana
Enviado el: miércoles, 04 de mayo de 2016 18:41
Para: [email protected]
CC: 'Jose Ruiz Mas' <[email protected]>
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: [email protected] [mailto:[email protected]]
Enviado
el: miércoles, 04 de mayo de 2016 18:20
Para: Jose Ruiz Mas <[email protected]>; Jose Saldana
<[email protected]>; Julian Fernandez Navajas <[email protected]>
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 protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
