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

Dino Farinacci <farinacci@gmail.com> Fri, 08 June 2018 00:23 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C90130E00 for <5gangip@ietfa.amsl.com>; Thu, 7 Jun 2018 17:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6rwMglBeIIS for <5gangip@ietfa.amsl.com>; Thu, 7 Jun 2018 17:23:04 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4805130DFA for <5gangip@ietf.org>; Thu, 7 Jun 2018 17:23:04 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id 76-v6so288206itx.4 for <5gangip@ietf.org>; Thu, 07 Jun 2018 17:23:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It5aujl3C9HAD2Job+UX0wdhoJUzxF7bMm/+6cSCweY=; b=Gd8yLx2SlStwfzRZx0G44x6gnBDzsrpfhL0IXfAqx29orTZIG0cocKZe4jRUn9cpZP RKc+iN7PMAX03APFOB4NAfAK/isWPNcJcSssvkOz59n1N92cqAY0mXe8CcKl6nJF/ZWE 5zynW8avCmifIze1FnIFUYMRIm7hAU6fxKV1t69X0o4PgKB6k0RYXrkKsfP5nQHhfO3u mNgEOgn1HkOKaJ4xaPcE/ASpymxoC1Kb92PYmnhKGLzZYzT4UBXcE7lxzCNKYWQKjGxK 6tsL05ihG8zOHgubQ0OLls1Op0JNPoGX5FQbHhqJT13O1+HH8ucW3oc6285GiUp7+0Cy W3Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It5aujl3C9HAD2Job+UX0wdhoJUzxF7bMm/+6cSCweY=; b=QfJnaHw9m8LuQiGZ6M1vqSzPnJ7UVlGsSucIi+DkN2ocG0NM7Y5j4QzG0fQ+Iz27qZ YZmSl325k3C5I1FRP5/cttoEjLyhim8UQIy8Yx2pAjbKGWn9Fxq0aCSdrFlHJYp9M7jg 07twdoLqhbT9s1lKdgiQULv/8bQsFJr/V5t0PJmaJlbt/4P4aM6Vh1gRjKJf0zm4YpWj 74tAXl17IhHhLt1ngbhhSvIw5R72BH+53MesWw3TuwTZcaDeLHPU/14rGiJ+XD0LYG6k RJu0svxyP+spaHiVBfH1/xRQDVx2lzlgc6m2oEPiyYeXFuY+7YFpLke6nPC61KgMUhna Aw0A==
X-Gm-Message-State: APt69E1vqFIPo8o9KdADTabDNCdgaWWGZLaK0dUoeCo6mU8H4nzTEqJZ SLBLDiMonYI/LuqDkpBTa30=
X-Google-Smtp-Source: ADUXVKJe6yAPaTzJQCJTjAo6HYkC5IPtjuKU736qj7EhffrabZV4p+Lfcz7eKaKEoTuv84dPepRhqg==
X-Received: by 2002:a24:33cb:: with SMTP id k194-v6mr3842123itk.81.1528417384071; Thu, 07 Jun 2018 17:23:04 -0700 (PDT)
Received: from [172.19.131.136] ([12.130.117.33]) by smtp.gmail.com with ESMTPSA id x6-v6sm121368itb.32.2018.06.07.17.23.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 17:23:03 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <1528414247.2315.235.camel@gmail.com>
Date: Thu, 07 Jun 2018 17:22:51 -0700
Cc: "FIGURELLE, TERRY F" <tf2934@att.com>, Luigi Iannone <ggx@gigix.net>, Tom Herbert <tom@herbertland.com>, 5GANGIP <5gangip@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BB3D8DA-FEC6-4348-8876-735EBCB5E225@gmail.com>
References: <CAC8QAcfuk6e+JPuKC4sw=FPYSgO3Tkr5mjSRJeOzvjxUSc9xFw@mail.gmail.com> <B300114A-8838-4FE2-8FA9-95BA4CD07089@st-andrews.ac.uk> <C42C02FB-4452-4D4F-A826-F24D401BB76D@gigix.net> <1AFE10CF28AE8B4C9663445736B8034D3826A13C@CAFRFD1MSGUSRJI.ITServices.sbc.com> <F5E27567-7D26-4C10-9327-AF7A6FA3712B@gigix.net> <CALx6S356aAYm5Qp75t+SnB=vRKJYcZiktfZD32n92AjwoW7OWA@mail.gmail.com> <1AFE10CF28AE8B4C9663445736B8034D3826B279@CAFRFD1MSGUSRJI.ITServices.sbc.com> <523BE304-3160-4AB8-BACD-245472382320@gmail.com> <1AFE10CF28AE8B4C9663445736B8034D3826B4D5@CAFRFD1MSGUSRJI.ITServices.sbc.com> <C6C5B0AE-3498-4612-9A24-17BCCD9AC930@gmail.com> <1528414247.2315.235.camel@gmail.com>
To: Rex Buddenberg <buddenbergr@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/2ly_rvDJ2sapEugK0Gn4pMqJsaM>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 00:23:10 -0000

Personally, I want to lower them. We can’t fragment. The performance of the system will go down as you guys know. 

A 1400 MTU is a sloppy max. Leaves room for other stuff you didn’t account or know about further downstream.

Dino

> On Jun 7, 2018, at 4:30 PM, Rex Buddenberg <buddenbergr@gmail.com> wrote:
> 
> 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 <tf2934@att.com>
>> 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 <farinacci@gmail.com>
>>>> Sent: Thursday, June 07, 2018 1:34 PM
>>>> To: FIGURELLE, TERRY F <tf2934@att.com>
>>>> Cc: Tom Herbert <tom@herbertland.com>; Luigi Iannone <ggx@gigix.n
>>>> et>;
>>>> 5GANGIP <5gangip@ietf.org>
>>>> 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
>> 5gangip@ietf.org
>> https://www.ietf.org/mailman/listinfo/5gangip