Subject: [tsvwg] New Version Notification for draft-saldana-tsvwg-simplemux-04.txt

From: "Jose Saldana" <[email-masked]>
Date: Wed, 27 Jan 2016 18:04:22 +0100

Hi all,

A new version of the Simplemux draft has been uploaded.
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/

In addition, you can find a research paper explaining it here: 
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7363105

An implementation (https://github.com/TCM-TF/simplemux) has been used to carry out some tests with real traffic, showing significant improvements: 46% of the bandwidth can be saved when compressing voice traffic. And 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.

Best regards,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]
> Enviado el: miércoles, 27 de enero de 2016 17:59
> Para: Jose Saldana <[email-masked]>
> Asunto: New Version Notification for draft-saldana-tsvwg-simplemux-04.txt
> 
> 
> A new version of I-D, draft-saldana-tsvwg-simplemux-04.txt
> has been successfully submitted by Jose Saldana and posted to the IETF
> repository.
> 
> Name:		draft-saldana-tsvwg-simplemux
> Revision:	04
> Title:		Simplemux. A generic multiplexing protocol
> Document date:	2016-01-27
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-simplemux-
> 04.txt
> Status:         https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/
> Htmlized:       https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-simplemux-04
> 
> Abstract:
>    The low efficiency caused by the high amount of small packets present
>    in the network can be alleviated by means of packet aggregation.
>    There are some situations in which multiplexing a number of small
>    packets into a bigger one is desirable.  For example, a number of
>    small packets can be sent together between a pair of machines if they
>    share a common network path.  Thus, the traffic profile can be
>    shifted from small to larger packets, reducing the network overhead
>    and the number of packets per second to be managed by intermediate
>    routers.
> 
>    This document describes Simplemux, a protocol able to encapsulate a
>    number of packets belonging to different protocols into a single
>    packet.  It includes the "Protocol" field on each multiplexing
>    header, thus allowing the inclusion of a number of packets belonging
>    to different protocols (multiplexed packets) on a packet of another
>    protocol (tunneling protocol).
> 
>    In order to reduce the overhead, the size of the multiplexing headers
>    is kept very low (it may be a single byte when multiplexing small
>    packets).
> 
> 
> 
> 
> 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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Jan 2016 10:48:06 -0800

> An implementation (https://github.com/TCM-TF/simplemux) has been used to carry out some tests with real traffic, showing significant improvements: 46% of the bandwidth can be saved when compressing…
Hi Jose,

Have considered the effect this will have on packet ordering (i.e.
will this create rampant OOO packets at a receiver)? You also might
want to look at implementing this within an existing encapsulation,
such as GUE, which already provides basic encapsulation features like
checksum, flow entropy, and compatibility with network HW since it is
UDP. Although, if this does become an IP protocol it would already be
compatible with GUE since protocol field takes an IP protocol number.

Thanks,
Tom

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 28 Jan 2016 11:50:42 +0100

Hi Tom,

Thanks a lot for your comments.

Regarding packet ordering, this would introduce a certain jitter in the network (some packets will experience more delay than others). However, the idea is that you should not multiplex packets from a single user, but from a number of them, so you will be able to send e.g. 30 packets from different users adding a small delay. We have explored this in some research papers. See e.g. this one of IEEE Communications Magazine: http://diec.unizar.es/~jsaldana/personal/yoda_commag_2013.pdf

Regarding integration with GUE (https://tools.ietf.org/html/draft-ietf-nvo3-gue-02), I agree with you: the idea of Simplemux is that it can be integrated with many encapsulation methods. In fact, we are currently about to start building an experimental implementation of LISP+Simplemux. Perhaps integrating with GUE could also be interesting.

BR,

Jose

> De: Tom Herbert [mailto:[email-masked]]
> Enviado el: miércoles, 27 de enero de 2016 19:48
> CC: tsvwg <[email-masked]>
> Asunto: Re: [tsvwg] New Version Notification for draft-saldana-tsvwg-simplemux-
> 04.txt
> 
> > An implementation (https://github.com/TCM-TF/simplemux) has been used to
> carry out some tests with real traffic, showing significant improvements: 46% of the
> bandwidth can be saved when compressing voice traffic. And 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.
> >
> Hi Jose,
> 
> will this create rampant OOO packets at a receiver)? You also might want to look at
> implementing this within an existing encapsulation, such as GUE, which already
> provides basic encapsulation features like checksum, flow entropy, and
> compatibility with network HW since it is UDP. Although, if this does become an IP
> protocol it would already be compatible with GUE since protocol field takes an IP
> protocol number.
> 
> Thanks,
> Tom
> 
> > Best regards,
> >
> > Jose
> >
> >> has been successfully submitted by Jose Saldana and posted to the
> >> IETF repository.
> >>
> >> 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
> >
> >