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

[Rex Buddenberg <[e-mail]>]

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://www.ietf.org/mailman/listinfo/5gangip