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

Dino Farinacci <farinacci@gmail.com> Tue, 05 July 2016 17:59 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB9012B060; Tue, 5 Jul 2016 10:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTAyqK4-KJCd; Tue, 5 Jul 2016 10:59:02 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F48512D68A; Tue, 5 Jul 2016 10:58:56 -0700 (PDT)
Received: by mail-pa0-x22f.google.com with SMTP id uj8so9514179pab.3; Tue, 05 Jul 2016 10:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mn7l4a/j9Ovridlxg/jIPWL46ry2f47xIM2tR/t62Pw=; b=vZe/6jWtjb9qMGPa92PIQ7KWb4LZhevlJ1anxzNDsKU6yTLEOfaWFVfMhesqyMgqMe kOz92c21whepqbE1YoDCDlJRBwXfs0nvJcFSBM1cZHEI076MDZOg9Zi1FewH0aocwmlc WW2M8RxI0RiaUJrukrye7jpovpltgMUShfDs8KLSzRiUWnQXIGbGCY8WzUXFLs8SMYea WtVVZsVBMtriUufIBVfUK4DGm1Bvm5yB7IUZb4JT4P5EXPGThnQMBeXkG78ifEhf8nmr bRHDNZwJh7wraC8H2nsqgI1gg238X/V64BJlh9Kyv3MldZupJqkIhI0gfsVKHNg6B38A gKRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mn7l4a/j9Ovridlxg/jIPWL46ry2f47xIM2tR/t62Pw=; b=XO5BKuwwt/OV84Hp4WnUCzcKz2z8xYZ2NfFMqSyvp/xaad+lx1S4nBRdf32L16AmDX YUs2KLdJwYgCCzaL97bQz2jc0xNyX0YXCywVk0ZnJ/dAK9EuzPg0K1oocgDl+9Z+UlU8 pRym4JcCtua4NJKEAzhGr4/PhgCNx5z3DaxRJFq1iYzMXiW/jSAmV/JGnkZrbNsXnGSS XDRjJSdVQIu0GyRMbuVP7pGX8/bFsiRxMc16ulO9g+d6Z0ireInlwipm1l8vQ0k1OF++ RRbApmP41xXVnfv55itZPGyvjOVDORUJaLKsVzNFRpbZnegquEGsaf60oVR2rTVmTefb 8gbA==
X-Gm-Message-State: ALyK8tLJ0rdEE5Ai59c+5SHI+8pZmAhEXbe2Yy86CoNPquSf8x8OruKLpOvGdyARhrfjNg==
X-Received: by 10.66.42.102 with SMTP id n6mr34096545pal.60.1467741535814; Tue, 05 Jul 2016 10:58:55 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id o6sm6778443pax.9.2016.07.05.10.58.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jul 2016 10:58:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAD6AjGRokOVdB7Z4TpxmCqi_9nOajT0e7b=y3VcsQrqVy1KJTg@mail.gmail.com>
Date: Tue, 05 Jul 2016 11:00:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D68AD20F-B5E4-4B06-9A8D-C480DB4761C1@gmail.com>
References: <007601d1cd2f$3a8cad70$afa60850$@unizar.es> <576C060C.2070907@cisco.com> <00ab01d1d38d$17365060$45a2f120$@unizar.es> <6C1441C1-90C3-457B-8146-4869C9FE5929@gmail.com> <CAD6AjGRokOVdB7Z4TpxmCqi_9nOajT0e7b=y3VcsQrqVy1KJTg@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/iW7aaJxT52sLHA3GeFWFRVtfpTM>
Cc: "5gangip@ietf.org" <5gangip@ietf.org>, José Ruiz Mas <jruiz@unizar.es>, Anton Smirnov <asmirnov@cisco.com>, LISP mailing list list <lisp@ietf.org>, Jose Saldana <jsaldana@unizar.es>
Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2016 17:59:04 -0000

> On Friday, July 1, 2016, Dino Farinacci <farinacci@gmail.com> wrote:
> 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).
> 
> 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.
> 
> 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
> 
> 
> I dont think this will fly. 

I tend to agree.

> LISP is a lot of work and Super Framing / packing is a edge case benefit, especially when layering on top of all the other muck 

Let’s not conflate running LISP and super-framing. I think running LISP (but not on the UE) is really an easy deployable solution. That is a separate topic for discussion. This thread was focusing on super-framing.

> A real benefit that would justify heavy lifting  is replacing the 5G core with an alternative mobility system such as LISP or ILNP. 

Right, we will have several presentations at the 5gangip BOF discussing this.

> http://telecoms.com/wp-content/blogs.dir/1/files/2016/06/5G-architecture-options.pdf
> 
> You can see that new core is a green field opportunity to replace the mobility system, which is very high value area. 

Yes, I and many are aware of the opportunity.

Thanks,
Dino

> 
> CB
>  
> > On Jul 1, 2016, at 4:38 AM, Jose Saldana <jsaldana@unizar.es> 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:asmirnov@cisco.com]
> >> Enviado el: jueves, 23 de junio de 2016 17:54
> >> Para: Jose Saldana <jsaldana@unizar.es>; lisp@ietf.org
> >> CC: 'José Ruiz Mas' <jruiz@unizar.es>
> >> 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:lisp-bounces@ietf.org] En nombre de Jose Saldana
> >>>> Enviado el: miércoles, 04 de mayo de 2016 18:41
> >>>> Para: lisp@ietf.org
> >>>> CC: 'Jose Ruiz Mas' <jruiz@unizar.es>
> >>>> 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >>>>> Enviado
> >>>>> el: miércoles, 04 de mayo de 2016 18:20
> >>>>> Para: Jose Ruiz Mas <jruiz@unizar.es>; Jose Saldana
> >>>>> <jsaldana@unizar.es>; Julian Fernandez Navajas <navajas@unizar.es>
> >>>>> 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
> >>>> lisp@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >>>
> >>> _______________________________________________
> >>> lisp mailing list
> >>> lisp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/lisp
> >>>
> >
> > _______________________________________________
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip