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

[Tom Herbert <[e-mail]>]

On Thu, Jun 7, 2018 at 5:21 PM, Dino Farinacci <[e-mail]> wrote:
> So to account for GTP headers, do you have the UEs send like 1400 byte max sized packets?
>
That would only account for UEs that are sending to other hosts, not
all the hosts on the Internet that are sending to UEs. Looks like
Terry is suggesting to use jumbo frames with 2000 MTU. That will work
in a closed network where everything is tightly managed, but isn't a
general solution (by IETF standards). See draft-ietf-intarea-tunnels.

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 mentioned in the draft. Sure, it
may be the case that over the years operators and vendors have
provided solutions to these problems, but if that entails a whole
bunch of complexity in both implementation (like protocol specific
logic) and deployment then that itself becomes the problem. In the
face of such complexity, that creates a high barrier of entry for
alternative solutions and innovation.

Tom


> Dino
>
>
>> On Jun 7, 2018, at 4:57 PM, FIGURELLE, TERRY F <[e-mail]> wrote:
>>
>> I only want to be able to pass a UE 1500 IP packet thru the network without fragmentation even for small cell where you have GTP and IPsec headers. Using a transport MTU2000 on eNB and EPC data plane elements is more than enough to allow those encapsulations without needing fragmentation.
>>
>> I also know way to much about bit error rates and feed forward error correction. When they started talking about feed forward error correction being sent from neighboring sectors that got my attention.
>>
>> I once challenged somebody to do the math for beam forming. I think they gave up after a couple of weeks. He was complaining why we paid some people so much. I never got a chance to say because it doesn't take them a couple of weeks!
>>
>>> -----Original Message-----
>>> From: Rex Buddenberg <[e-mail]>
>>> Sent: Thursday, June 07, 2018 4:31 PM
>>> To: Dino Farinacci <[e-mail]>; FIGURELLE, TERRY F
>>> <[e-mail]>
>>> Cc: Luigi Iannone <[e-mail]>; Tom Herbert <[e-mail]>;
>>> 5GANGIP <[e-mail]>
>>> Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt
>>>
>>> Dino,
>>>
>>> Back in Ye Olde Days, MTU in radio nets was drastically smaller than in wireline
>>> due to RF noise.  Bit error rate for radio is orders of magnitude greater than, say,
>>> fiber.  Further, in lower-capacity links, the number of bits in flight is a lot greater
>>> and too-large MTUs left wannabes unable to wedge into the link, perhaps with
>>> high precedence traffic.  There's a multi-variable optimization problem between
>>> bit error rate, forward error correction and interruptability that is complex
>>> enough that when WiFi appeared, it simply reused the MTU=1500 that ethernet
>>> had used.
>>>      And ethernet used 1500 because it was a round number and was big enough
>>> to get at least one datagram in (datagram sizes were never standardized but a
>>> convention number in the 700 byte territory was used in early days because
>>> that was the max size of RAM available in an early packet switch after the router
>>> programming was put in and
>>> started.)
>>>      In radio, errors in frequencies below about 8MHZ are dominated by
>>> lightning.  Refracted by ionosphere.  There's always a thunderstorm going on
>>> somewhere in the world...  Above that frequency, you get less lightning racket --
>>> lightning  noise becomes a local phenomenon because the higher freqs don't
>>> refract through ionosphere.  Rather, bit error rate is more dominated by galactic
>>> noise.  And increasingly, man-made racket.
>>>
>>> So before you and Terry go jacking up the MTUs, there are a couple 'yes buts'.
>>>
>>> b
>>>
>>>
>>> On Thu, 2018-06-07 at 15:17 -0700, Dino Farinacci wrote:
>>>> On Jun 7, 2018, at 2:12 PM, FIGURELLE, TERRY F <[e-mail]>
>>>> wrote:
>>>>>
>>>>>
>>>>> The MTU mismatch?
>>>> Yes, thanks for the explaination. But what are the other two issues:
>>>> “between vendors” and “between address families”.
>>>>
>>>> Dino
>>>>
>>>>>
>>>>>
>>>>> We already have vendors working on auto-MTU adjust and working on
>>>>> device requirements so whenever it gets an updated MTU in PCO the
>>>>> device will honor it. We were told that this is something 3GPP would
>>>>> not be interested in since it is a temp deployment challenge not a
>>>>> long term challenge. Plus we require MRU>MTU so most elements can
>>>>> get a larger packet then they can send. We can set MTU per APN so
>>>>> the 5G APN is set to use full 1500 byte "Internet" MTU.
>>>>>
>>>>> Thus you can have a network where legacy APN's stull do their thing
>>>>> then decide when/where to use larger MTU. IMS looks ripe for a
>>>>> larger than 1500 byte MTU. Those SIP messages can be huge. But we
>>>>> need to validate all the vendors can support this and work the
>>>>> details to get there.
>>>>>
>>>>> Now if you can get the entire Internet to support more that 1500
>>>>> byte MTU, you are better than me.
>>>>>
>>>>> We worked a lot on MTU discovery but even for IPv6 this just doesn't
>>>>> pan out. I wish it did but realities sometimes suck and its taking
>>>>> way too long to get to all IPv6 ☹
>>>>>
>>>>> Now if you meant something else please rephrase it concisely.
>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dino Farinacci <[e-mail]>
>>>>>> Sent: Thursday, June 07, 2018 1:34 PM
>>>>>> To: FIGURELLE, TERRY F <[e-mail]>
>>>>>> Cc: Tom Herbert <[e-mail]>; Luigi Iannone <ggx@gigix.n
>>>>>> et>;
>>>>>> 5GANGIP <[e-mail]>
>>>>>> Subject: Re: [5gangip] New Version Notification for draft-xyzy-
>>>>>> atick-gaps-
>>>>>> 00.txt
>>>>>>
>>>>>>>
>>>>>>> Apparently X2 handoffs not only can’t go between vendor and IP
>>>>>>> address
>>>>>> families they can’t go between MTU sizes. So we need to do all the
>>>>>> tracking areas in a market to avoid S1 handovers.
>>>>>>
>>>>>> Do you think this is a problem worth solving?
>>>>>>
>>>>>> Dino
>>>> _______________________________________________
>>>> 5gangip mailing list
>>>> [e-mail]
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>>>> man_listinfo_5gangip&d=DwIDaQ&c=LFYZ-
>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl
>>>>
>>> 2paJIf4zw&m=kEgRvI2s9tO3cGtRNOgWGjsXlDy18UBXS4gkFz9cMWY&s=JYVGc
>>> _lQt_62
>>>> X66D-1KYrqbqjOMSwSIytZMPe94JAms&e=
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip