> My point, which appears not to be tracking, is I *wish* protocol layers
> didn’t have such strict MTUs, but rather expanded as headers were added *at
> all layers*, in the same *spirit* as Ethernet does.
The Internet can do this. Just make the MTU 1400. Then you can add up to 100
bytes of he
I know that Ethernet gets to do the redefinition.
My point, which appears not to be tracking, is I *wish* protocol layers didn’t
have such strict MTUs, but rather expanded as headers were added *at all
layers*, in the same *spirit* as Ethernet does.
The question was “what features do we want”,
Joe, I am missing something in your wish.
Ethernet, when it defines new heders, also revises the definition of the
actual frame format on the wire. The IETF does not own the frame format
on the wire. We do not own the link MTU.
Unless we want to reinvent X.25 with linkwise fragmentation and
Hi, Fred,
These both address a way to support *fragmentation*. I clearly said what we
need is a way to stop fragmenting (it was a wish list after all).
Ethernet never fragments because it just keeps adding headers. Nothing in the
docs below does that.
THAT, in a nutshell, is what’s missing, as
Abe mentions "more efficient and productive use of our resources" and I think
we all wish for that.
I think this WG should discuss the general question whether the minor wastage
of IPv4 address space that this set of drafts addresses is an efficient and
productive use of our resources. In othe
Joe, go read these and tell me what you think is missing because I assure you
that
nothing is missing:
https://datatracker.ietf.org/doc/draft-templin-6man-omni/
https://datatracker.ietf.org/doc/draft-templin-dtn-ltpfrag/
And please quit sending the funky html emails - they are corrupting the lis
Dear Colleagues:
0) I was just made aware of a current IETF Draft discussion on
reducing the 127/8 netblock allocated for Local Loopback to 127/16 in
order to free up mostly unused resources in that portion of the IPv4
address pool. In studying this lead, I discovered that there are at
lea
Hi Fred,
It’s not possible to claim any one layer solves this. MTU is inherently a
multilayer issue, and that’s perspective that’s missing, IMO.
Note that I don’t think this can be solved the way I’m asking in the current
layering, even with shim layers.
But that was the question asked.
Jo
Joe, AAL5 adapted to heterogeneous Internetworks does the job properly as
part of a multi-layered segmentation and reassembly solution. See also:
https://datatracker.ietf.org/doc/draft-templin-dtn-ltpfrag/
From: to...@strayalpha.com [mailto:to...@strayalpha.com]
Sent: Friday, December 03, 2021 11
—
Joe Touch, temporal epistemologist
www.strayalpha.com
> On Dec 3, 2021, at 10:06 AM, Templin (US), Fred L
> wrote:
>
> Joe, I was going to let this slide but this is the most words you have spoken
> to
> me in a single message in many years.
Sorry - my day job keeps me quite busy….
> What
> I think the discussion is about to talk which layer should the features be
> added to. (network? Host? Or the abstracted waist?)
>
> It is true that users expect more features from the NETWORK as a lot of you
> proposed, but users are definitely know nothing about TCP/IP or OSI or ATM
> arch
Joe, I was going to let this slide but this is the most words you have spoken to
me in a single message in many years. What AERO/OMNI enable is lossless and
adaptive packet sizing to determine the best-performing size for a given flow
*even if that size exceeds the path MTU*. I think this honors th
On Fri, Dec 3, 2021 at 3:19 AM Alexandre Petrescu
wrote:
>
> - make sure the Internet does no harm.
>
> - use shorter paths and not artificially-long paths like with VPN
>gateways, video session rdv points. Use more direct communications
>
> - accommodate more bandwidth: 10petabit/s for a lin
Fred,
Having a mechanism that *can* be used at any layer to address fragmentation
isn’t the same as solving the MTU issue.
Issues that complicate this are:
- not all layers employ that mechanism or any other
- too many ‘layers’ peek into payload contents for message dispatch (of one
sort or ano
Joe, yes MTU was hard – very hard – but it is now solved.
From: to...@strayalpha.com [mailto:to...@strayalpha.com]
Sent: Thursday, December 02, 2021 5:21 PM
To: Templin (US), Fred L
Cc: Dino Farinacci ; int-area@ietf.org; Dirk Trossen
Subject: Re: Side meeting follow-up: What exact features do
Hi Fred,
I see AERO and OMNI as examples of technologies trying to fill a gap (or a few
gaps), falling exactly in what has been done in the Gap Analysis draft:
surveying technologies that are filling gap in the addressing model.
Ìt would be wonderful if you could formulate the gap(s) that AERO
- make sure the Internet does no harm.
- use shorter paths and not artificially-long paths like with VPN
gateways, video session rdv points. Use more direct communications
- accommodate more bandwidth: 10petabit/s for a link.
- reduce the number of overlays. Reduce the encapsulations, like
Hi Dino,
The extensions are those identified in Section 3 of the gap analysis draft (at
https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/).
There are 21 extension listed so far (saee Secti9on 4 on Page 21 for an
overview).
Best,
Dirk
-Original Message-
18 matches
Mail list logo
