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

[Tom Herbert <[e-mail]>]

On Fri, Jun 8, 2018 at 3:18 PM, FIGURELLE, TERRY F <[e-mail]> wrote:

>
>
> Sent from my iPhone
>
> On Jun 7, 2018, at 7:57 PM, Dino Farinacci <[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.
>
> Hi Terry,

That's interesting. I would assume that the typical fragmentation pattern
in the tunneling MTU scenario is precisely two fragments. I believe this is
usually one big fragment followed by one small one. I would expect fragment
loss to be a problem, but without loss it's a bit surprising that OOO would
be a major issue, maybe this is going through some middlebox that expects
fragments in order?. The general OOO problem between fragments and not
fragments is being solve in other IETF protocols either by fragmenting
within the encapsulation (like in GUE) or the basing ECMP in flow label and
not transport ports (i.e. transport ports only are in first fragment).

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?
>
> ILA eschews encapsulation, so that avoids the tunneling issues like this.


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