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

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Jul 2016 10:05:57 -0700

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

> On Jul 1, 2016, at 4:38 AM, Jose Saldana <[email-masked]> 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-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
>> 
>> 
>> 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-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.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-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
>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 4 Jul 2016 13:50:46 +0200

Hi, Dino.

> De: Dino Farinacci [mailto:[email-masked]]
> Enviado el: viernes, 01 de julio de 2016 19:06
> Para: Jose Saldana <[email-masked]>
> CC: Anton Smirnov <[email-masked]>; LISP mailing list list <[email-masked]>;
> José Ruiz Mas <[email-masked]>; [email-masked]
> 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).

We have also previously thought on the potential utility of multiplexing in mobility scenarios.

For example, in PMIPv6 (standardized by the concluded IETF NETLMM Working Group), some tunnels are created between the Local Mobility Anchor (LMA, running in the P-GW) and the Mobile Access Gateway (MAG, running in the Serving Gateway). See the scheme in 
http://openairinterface.eurecom.fr/openairfiles/DOCS.pmipv6/html/html/main.html. Perhaps multiplexing in those tunnels could make sense, as they include the traffic of many mobile nodes. The same tunnel is used for m mobiles (a 1:m relation, see http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4492976&tag=1). 

>
> 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.

So what you propose is to take the packets waiting in the queue, and to aggregate them into bigger ones, before sending them to the mobile node right?

Could this fit with other use case? In http://research.cisco.com/pdfs/LISP-MN%20mobile%20networking%20through%20LISP.pdf 
(page 9), a LISP-based mobility scheme is explained in detail:

	In this section we describe the handover process in LISP-MN. When a MN
	changes its attachment it regains connectivity in a new subnetwork. It first
	obtains a new RLOC and, as described in section 2.3.1, it notifies the new
	EID-to-RLOC binding to its Map-Server. The MN has to update also all the
	bindings stored in the Map-Cache of the peers, either routers or nodes, with
	which it is communicating. In order to do it uses the special signalling message
	called Solicit-Map-Request (SMR). The reception of such message triggers a
	Map-Request to refresh the binding (...).

Would it make sense to also multiplex packets waiting before the EID-to-RLOC binding is updated?

>
> 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
>

Thanks!

Jose
PS: If you could detail a bit more the use case you are talking about, it would be fine.

> > I have just uploaded a new presentation including more ideas and also a 
> > section
> about backward compatibility:
> >
> >> De: Anton Smirnov [mailto:[email-masked]] Enviado el: jueves, 23
> >> de junio de 2016 17:54
> >>    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
> >>
> >>
> >> (https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/)
> >> with a proposal allowing bandwidth and pps reductions.
> >>>
> >> 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).
> >>>
> >>>> https://github.com/Simplemux/lispmob-with-simplemux. I has been
> >>>> built as a fork of lispmob.
> >>>>

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Mon, 4 Jul 2016 12:11:59 +0000

This is why I’m proposing to move the processing as close as possible to the RAN using SFC… Well, or at least that’s another ingredient in the cake …

---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ Zurbarán,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

-----Mensaje original-----
De: 5gangip <[email-masked]> en nombre de Jose Saldana <[email-masked]>
Fecha: lunes, 4 de julio de 2016, 13:50
Para: 'Dino Farinacci' <[email-masked]>
CC: "[email-masked]" <[email-masked]>, 'José Ruiz Mas' <[email-masked]>, 'LISP mailing list list' <[email-masked]>, 'Anton Smirnov' <[email-masked]>
Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP

Hi, Dino.

Thanks!

Jose

_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 4 Jul 2016 13:43:50 +0000

Hey Dino,

Queuing also happens when a UE is has been idle for a while and is being paged. 

On the header size issue, one of the complaints I've made about ICN/CCN etc. and 5G is the increased header sizes and the impact that this has on the most expensive resource (by a wide margin), the RF spectrum. 

Not much point optimizing all the relatively cheap wired links if the tax then goes up on the incredibly expensive wireless links.

Finding a way to properly map multicast/broadcast to the natural RF multicast would seem like a smart thing to do to extend some of the bandwidth savings protocols like ICN/CCN give but there are challenges with this as each UE may have a different RF encoding (due to different channel conditions) and therefore require separate copies anyway.

Cheers

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Friday, July 01, 2016 1:06 PM
To: Jose Saldana
Cc: [email-masked]; José Ruiz Mas; LISP mailing list list; Anton Smirnov
Subject: Re: [5gangip] [lisp] Bandwidth savings with LISP

Dino

>> first glance, it looks like backward compatibility of the solution was not investigated. Is this correct?
>> 
>> Anton
>> 
>>

---

From: Ca By <[email-masked]>
Date: Mon, 4 Jul 2016 07:14:45 -0700

On Friday, July 1, 2016, Dino Farinacci <[email-masked]> wrote:

> header-compression and the super-framing feature (sorry for using my own
> term).
>
> 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.

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

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

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.

CB

> > On Jul 1, 2016, at 4:38 AM, Jose Saldana <[email-masked]
> <javascript:;>> wrote:
> >
> > Hi again, Anton.
> >
> section about backward compatibility:
> >
> >
> >> De: Anton Smirnov [mailto:[email-masked] <javascript:;>]
> >> Para: Jose Saldana <[email-masked] <javascript:;>>; [email-masked]
> <javascript:;>
> >> CC: 'José Ruiz Mas' <[email-masked] <javascript:;>>
> there is a practical
> Therefore, they
> >>>> De: lisp [mailto:[email-masked] <javascript:;>] En nombre de
> Jose Saldana
> >>>> Para: [email-masked] <javascript:;>
> >>>> CC: 'Jose Ruiz Mas' <[email-masked] <javascript:;>>
> >>>>> De: [email-masked] <javascript:;> [mailto:
> [email-masked] <javascript:;>]
> >>>>> Enviado
> >>>>> Para: Jose Ruiz Mas <[email-masked] <javascript:;>>; Jose Saldana
> >>>>> <[email-masked] <javascript:;>>; Julian Fernandez Navajas <
> [email-masked] <javascript:;>>
> >>>> [email-masked] <javascript:;>
> >>> [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Jul 2016 10:54:38 -0700

> So what you propose is to take the packets waiting in the queue, and to aggregate them into bigger ones, before sending them to the mobile node right?

To do any type of packet aggregation, you need a queue of packets. I don’t want to explicit create a queue just to get super-framing/packet-aggregation. But if it is happening for other reasons, the opportunity does present itself. But I’m not sure yet if there is huge benefits. Because large packets have their own set of problems.

> Would it make sense to also multiplex packets waiting before the EID-to-RLOC binding is updated?

Today, it is hard for hardware to queue packets on the input side. And on the output side, most hardware that performs lookups then packet rewrites, queues packets and forgets them. They typically don’t pull them out to do processing later.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Jul 2016 10:57:23 -0700

> On the header size issue, one of the complaints I've made about ICN/CCN etc. and 5G is the increased header sizes and the impact that this has on the most expensive resource (by a wide margin), the…

So you are saying large packets would have the same disadvanage. Therefore, small headers on small payloads is the most optimal design space?

> Not much point optimizing all the relatively cheap wired links if the tax then goes up on the incredibly expensive wireless links.

Right.

> Finding a way to properly map multicast/broadcast to the natural RF multicast would seem like a smart thing to do to extend some of the bandwidth savings protocols like ICN/CCN give but there are c…

Right, another topic. But thanks for raising it.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Jul 2016 11:00:03 -0700

> 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.

> 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

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 6 Jul 2016 06:06:19 +0000

Answers inline, marked with [PA]

It’s my (-) .02 cents
Best,
---

Technology Exploration -

C/ Zurbarán,12
28010 Madrid, Spain

Georg Kreisler

-----Mensaje original-----
De: 5gangip <[email-masked]> en nombre de Dino Farinacci <[email-masked]>
Fecha: martes, 5 de julio de 2016, 20:00
Para: Ca By <[email-masked]>
CC: "[email-masked]" <[email-masked]>, José Ruiz Mas <[email-masked]>, Anton Smirnov <[email-masked]>, LISP mailing list list <[email-masked]>, Jose Saldana <[email-masked]>
Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP

I tend to agree.

[PA] Hey folks, 5G is going for slices for many good reasons. One of these is to avoid stacking headers… especially in the RAN.

[PA] No objection to use all these wonderful things you propose in the CORE, but there is a lot of processing before that and there’s where my part kicks in, right? ;-)

[PA] Hey folks, what does 5G core actually mean? For me it will be the core of the 5G network, which is currently TBD. So instead of thinking about replacing something that does not exist, why don’t we argue that this core part of the future 5G network would benefit for supporting LISP? ;-)

[PA] Me too, just trying to put things into (yet another) perspective (with no claim to absolute truth or completeness). ;-)

Thanks,
Dino

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 6 Jul 2016 11:37:33 +0200

Hi, 

Just a minor comment inline...

> Enviado el: martes, 05 de julio de 2016 19:57
> Para: AshwoodsmithPeter <[email-masked]>
> CC: Jose Saldana <[email-masked]>; [email-masked]; José Ruiz Mas
> <[email-masked]>; LISP mailing list list <[email-masked]>; Anton Smirnov
> <[email-masked]>
> > On the header size issue, one of the complaints I've made about ICN/CCN etc.
> and 5G is the increased header sizes and the impact that this has on the most
> expensive resource (by a wide margin), the RF spectrum.
> 
> So you are saying large packets would have the same disadvanage. Therefore,
> small headers on small payloads is the most optimal design space?
> 
> > Not much point optimizing all the relatively cheap wired links if the tax then goes
> up on the incredibly expensive wireless links.
> 
> Right.

Well, optimization can also benefit the spectrum usage. We have run some tests sending small packets in a Wi-Fi link:

https://www.ietf.org/proceedings/93/slides/slides-93-gaia-2.pdf, slide 11.

If you first aggregate and then send them, you save bandwidth, but also air time, as you reduce the number of channel contention periods. In fact, 802.11 also has two different aggregation mechanisms working at layer 2. The advantage of aggregating at layer 3 is that you can send packets together during more than a single hop (see some scenarios in slide 12).

Best regards,

Jose

> 
> > Finding a way to properly map multicast/broadcast to the natural RF multicast
> would seem like a smart thing to do to extend some of the bandwidth savings
> protocols like ICN/CCN give but there are challenges with this as each UE may
> have a different RF encoding (due to different channel conditions) and therefore
> require separate copies anyway.
> 
> > 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
> >>>> (https://github.com/Simplemux/lispmob-with-simplemux), which we
> >>>> have used to run some tests
> >>>>
> >>>> http://es.slideshare.net/josemariasaldana/header-compression-and-mu
> >>>> l
> >>>> ti
> >>>> plexing-in-lisp
> >>>>
> >>>>>> https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress-
> >>>>>> m
> >>>>>> ux
> >>>>>> -
> >>>>>> 00.txt
> >>>>>> Status:

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jul 2016 10:43:39 -0500

On Wed, Jul 6, 2016 at 1:06 AM, PEDRO ANDRES ARANDA GUTIERREZ
<[email-masked]> wrote:
> Let’s not conflate running LISP and super-framing. I think running LISP (but not on the UE) is really an easy deployable solution.

I think we should discuss this further. Why can't we run LISP on UE?
Does it have to run on the host for proper LISP operation?

> That is a separate topic for discussion. This thread was focusing on super-framing.
>

Core network is 3GPP terminology, it comes after RAN and it is the
part that connects to the Internet. So the term core network could be
confusing to IETF folks.

Yes, I think that we should discuss the prospects of future 5G core
network would benefit from supporting LISP, but why and how?

Regards,

Behcet

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Jul 2016 10:11:38 -0700

> I think we should discuss this further. Why can't we run LISP on UE?

We can. I will present draft-meyer-lisp-mn at 5gangip. We have many options WHERE to deploy LISP. And we don’t have to stack headers.

> Does it have to run on the host for proper LISP operation?

No, not at all.

Dino

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 6 Jul 2016 17:41:54 +0000

Hey Dino,

>So you are saying large packets would have the same disadvanage. Therefore, small headers on small payloads is the most optimal design space?

Not sure how that follows ;) I'm saying either compress or provide an advantage to the RF link too, or both, but doing neither would be a hard sell. Larger packet sizes of course reduce the relative header tax so bigger is actually better I suppose.

Cheers,

Peter

Right.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Jul 2016 15:20:40 -0700

> Not sure how that follows ;) I'm saying either compress or provide an advantage to the RF link too, or both, but doing neither would be a hard sell. Larger packet sizes of course reduce the relativ…

More headers mean larger packets. Less headers with multiple packets in a super-packet means larger packets. So the negative effect is the same.

Dino

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 06 Jul 2016 17:20:07 -0700

There's another variable.  Noise, manifested in bit errors, is about
three orders of magnitude greater in RF than in wireline.  The larger
the packet, the larger the retransmission when it fails the CRC check.
If you must, there are yet more variables such as the amount of FEC.
The more FEC, the fewer bit errors, but the FEC comes at a cost in
capacity.  

Multivariable optimization problem.  And some of the variables change
from moment to moment.

On Wed, 2016-07-06 at 15:20 -0700, Dino Farinacci wrote:
> > 
> > Hey Dino,
> > 
> > > 
> > > > 
> > > > On the header size issue, one of the complaints I've made about
> > > > ICN/CCN etc. and 5G is the increased header sizes and the
> > > > impact that this has on the most expensive resource (by a wide
> > > > margin), the RF spectrum. 
> > > 
> > > So you are saying large packets would have the same disadvanage.
> > > Therefore, small headers on small payloads is the most optimal
> > > design space?
> > Not sure how that follows ;) I'm saying either compress or provide
> > an advantage to the RF link too, or both, but doing neither would
> > be a hard sell. Larger packet sizes of course reduce the relative
> > header tax so bigger is actually better I suppose.
> More headers mean larger packets. Less headers with multiple packets
> in a super-packet means larger packets. So the negative effect is the
> same.
> 
> Dino
>

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Thu, 7 Jul 2016 07:12:43 +0000

Hi Behcet,

In the northwestern tip of the Iberian peninsula, people answer questions with more questions ;-) So let me answer your question:

Why should we be running LISP on the UE?

Best, /PA

---

Technology Exploration
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo – GCTO Unit
C/ Zurbarán,12

28010 Madrid, Spain

Georg Kreisler

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Thu, 7 Jul 2016 07:17:05 +0000

OK, we may need to start by agreeing on what ‘core network’ means.

In a more canonical approach, we have the access network providing capillarity (and the RAN is just a part of this) and the core providing all the common network functions and the interconnection between access networks and between providers… Which is +/- what we are speaking about in most contexts including 3GPP…

Best, /PA
---

Technology Exploration

28010 Madrid, Spain

Georg Kreisler

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 7 Jul 2016 10:22:20 +0200

My two cents:

We should share an idea of what "big" or "small" means when talking about packets.

In Ethernet the MTU is 1500 bytes, so packets circulating by the wired Internet are between 40 and 1500 bytes. See the histogram of a real trace here: http://es.slideshare.net/josemariasaldana/simplemux-traffic-optimization/2

So when I talk about a "small packet", I am thinking about 40-100 bytes. When I talk about "big packet" I am thinking about 1500 bytes.

I assume that sending a 1500-byte packet is reasonably efficient in a network, be it wired or wireless.

- But sending thousands of 40-byte packets is not efficient in a wired network. This is why in wired networks, Jumbo frames, up to 9198 bytes, can be used.

- And sending 40-byte packets is not efficient at all in a wireless network, due to the overhead, and also to the contention mechanisms required before the actual sending of the data. This is why 802.11 includes aggregation mechanisms capable of sending a number of subframes into a single one. A-MPDU is able to send a number of subframes, each one with its own FEC, so they can be retransmitted individually (in order to avoid the trade-off highlighted by Rex: "The larger the packet, the larger the retransmission when it fails the CRC check.")

So in my case, multiplexing small packets would mean to aggregate 15 or 20 small packets into a 1500-byte one. Of course, you can also aggregate in order to build bigger frames.

So we can use:

- small: 40-100 bytes
- big: 1500 bytes
- super-frame: about 9000 or more

BR,

Jose

> De: Rex Buddenberg [mailto:[email-masked]]
> Enviado el: jueves, 07 de julio de 2016 2:20
> Para: Dino Farinacci <[email-masked]>; AshwoodsmithPeter
> <[email-masked]>
> CC: [email-masked]; José Ruiz Mas <[email-masked]>; Anton Smirnov
> <[email-masked]>; LISP mailing list list <[email-masked]>; Jose Saldana
> <[email-masked]>
> There's another variable.  Noise, manifested in bit errors, is about three orders of
> magnitude greater in RF than in wireline.  The larger the packet, the larger the
> retransmission when it fails the CRC check.
> The more FEC, the fewer bit errors, but the FEC comes at a cost in capacity.
> 
> Multivariable optimization problem.  And some of the variables change from
> moment to moment.
> 
> > > > > ICN/CCN etc. and 5G is the increased header sizes and the impact
> > > > > that this has on the most expensive resource (by a wide margin),
> > > > > the RF spectrum.
> > > >
> > > an advantage to the RF link too, or both, but doing neither would be
> > > a hard sell. Larger packet sizes of course reduce the relative

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 07 Jul 2016 09:12:44 -0700

Jose,

There's some 'but this is the way we've always done it' here that needs
to be cleaned up.

The 1500 byte MTU in ethernet was arrived at when buffer space was an
issue.  It's rather arbitrary.  10M clock rate rather than 1 or 10G
like we have today.  And the physical carrier of the day was RG5
coaxial cable (aka 10Base5).  

Packets shorter than 1500 are attributable to three things:
  - end-of-file packets where the content byte-count is less than 1500
  - one-datagram messages of less than 1500 bytes
  - overhead messages such as Syns and Fins and their Acks.  

The character of the data probably changes as you get to mobile
platforms -- expect an increase in short packets (a typical track
report contains identity, timestamp and position -- things you can say
in far less than 1500 bytes).  

Secondly, you got the notion right vis ethernet.  Layer 2 frames tend
to equal layer 3 datagrams.  Which means that you need to fight every
frame onto the air.  The impact of congestion is significant.
     But a better perspective to start your thinking from is IEEE
802.16, (industry label WiMax) rather than 802.3 (or .11).  In .16 the
standard carefully is agnostic about what the content frames are (in
reality they're ethernet, nobody is using ATM cells which was the issue
at time of writing).  And these subframes are aggregated into frames
where several (all that a station is allowed to transmit in that time
window) are shoved out the port head-to-tail.  The jitter associated
with the MAC (and contention access) is removed.  To my knowledge
802.16 has no arbitrary max frame size -- dependent on number of
stations and amount of traffic they have.  
     In such a case, header compressions that save bytes will have a
clear win (although I think we need a few other things higher on the
priority list).

On Thu, 2016-07-07 at 10:22 +0200, Jose Saldana wrote:
> In Ethernet the MTU is 1500 bytes, so packets circulating by the
> wired Internet are between 40 and 1500 bytes. See the histogram of a
> real trace here: http://es.slideshare.net/josemariasaldana/simplemux-
> traffic-optimization/2
> 
> So when I talk about a "small packet", I am thinking about 40-100
> bytes. When I talk about "big packet" I am thinking about 1500 bytes.
> 
> 
> - But sending thousands of 40-byte packets is not efficient in a
> wired network. This is why in wired networks, Jumbo frames, up to
> 9198 bytes, can be used.
> 
> - And sending 40-byte packets is not efficient at all in a wireless
> network, due to the overhead, and also to the contention mechanisms
> required before the actual sending of the data. This is why 802.11
> includes aggregation mechanisms capable of sending a number of
> subframes into a single one. A-MPDU is able to send a number of
> subframes, each one with its own FEC, so they can be retransmitted
> individually (in order to avoid the trade-off highlighted by Rex:
> "The larger the packet, the larger the retransmission when it fails
> the CRC check.")
> 
> So in my case, multiplexing small packets would mean to aggregate 15
> or 20 small packets into a 1500-byte one. Of course, you can also
> aggregate in order to build bigger frames.
> 
> So we can use:
> 
> - small: 40-100 bytes
> - big: 1500 bytes
> > > > > > impact