Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

["FIGURELLE, TERRY F" <[e-mail]>]

Sent from my iPhone

On Jun 7, 2018, at 7:57 PM, Dino Farinacci <[e-mail]<mailto:[e-mail]>> wrote:

Also note the problems of tunneling like encapsulation overhead,
diff-serv, hashing for ECMP, UDP checksum, fragmentation go away if
tunneling is not being done. This is

You heard what was said, GTP is not going away anytime soon.

There is no diff-serv problem, hashing can always be improved, as was just said in this thread, no UDP checksum problem,  and fragmentation can be avoided.

We’ve seen all of this with LISP deployment. These are not real problems. Just ones that are fabricated.

That’s a bit harsh.

GTP encapsulation can increase fragmentation and fragmentation does cause problems.

It increases latency because layer4 (e.g. PCEF) has to buffer until it has full packet. Retransmits at RAN layer2 can cause out of order packets. That is really bad when one of the fragments is out of order and the number of packets between the fragments is larger than a layer4+ element is configured to handle or supports.

While AT&T has taken great efforts to address all of these issues, often blazing the trail, not all mobile operators have the knowledge and resources to do so.

However, there is plenty of info on the topic and vendors should do the right things for their mobile network operator customers.

Typically the easiest things to do is reduce MSS for TCP traffic and attempt to reduce device MTU. TCP can be the majority of traffic on mobile networks (Google YouTube can flip that due to QUIC).

An addressable or transparent proxy that can be a TCP proxy should be set not only for MSS that prevents fragmentation but you want SACK too. Since TCP latency can play a huge role in throughout (see Massey in wiki TCP) due to bit error rates causing retransmits. The split TCP sessions (inside and outside of proxy) reduces the apparent latency over the RAN for the inside TCP session.

While mobiles have gotten a bit creative with their TCP stacks, the user still feels the impact of stalls. It’s a very common complaint even when a MNO/ISP does everything right.

It can also help to reduce MTU in PCO but not all mobiles honor that 3GPP feature. That also didn’t help mobile WiFi hotspots or tethering.

Yes, larger transport MTU is probably worth pursing at least for RAN and backhaul for GTP-U. I would start with backhaul transport contracts by adding at least IP MTU 2000 or appropriate layer2 value. Then as contracts expire the new ones should support what you need. Make sure as any upgrades are done on network, EPC or RAN that it can support larger transport MTU and if possible set MRU>MTU. This takes planning and time to fix.

I do think we should focus more on the benefits mapping can have towards services. Particularly when those services are in more than one location and for devices that typically are moving or nomadic enough to cross wireless (tracking area changes that cause path changes) or service locations changes.

Apps are all over the place when it comes to how they deal with or tolerate lost sessions, lost transactions, periods of unavailability, location changes and other factors due to an access that is less reliable and more variable when compare to current fixed location ISP access.

How does mapping help for these types of problems?

It could support a better path to a service which could include migration to a new service location. It could obscure that from the service or it could enable the service to move to the new location.

Just my thoughts.

Dino
_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=o9ik5qSzFvRAmMSixdE24AXFFKxQ9Yy6D3o5JYG4MbE&s=iin_2H25Swh9BuuHKWfDWpES5-WhM3osr0TWrIg7HnA&e=