Alex, I do not think there is any problem for QUIC. IPv6 Next Header field only
takes
a value for UDP; it does not take a value for QUIC. It is QUIC's job to make
sure that
everything beyond the UDP header is aligned properly for its own purposes.
Fred
> -Original Message-
> From: Alexa
Alex, it is true that we are stuck with "minimum/maximum" double-speak. So,
since
the beginning of time we have had:
minMTU (minimum maximum transmission unit)
minMRU (minimum maximum reassembly unit)
and now:
minMPS (minimum maximum payload size)
But, the latter is really not a new IP t
Dino, the term "Bridge" used here refers to bridging at the adaptation layer;
not at
the link layer. What is being bridged is the overlay; not the underlays. And,
again this
is at the adaptation layer - the layer below IP but above the link layer.
I am sorry if that comes across as confusing, bu
Joe, I am having a hard time seeing your response as anything other than a
non-answer to my question.
Fred
> -Original Message-
> From: to...@strayalpha.com [mailto:to...@strayalpha.com]
> Sent: Wednesday, December 08, 2021 12:11 PM
> To: Templin (US), Fred L
> Cc: Dino Farinacci ; int-a
> On Dec 8, 2021, at 8:30 AM, Templin (US), Fred L
> wrote:
>
> Absolutely not talking about translation - talking about concatenation and
> adaptation.
Those terms are too general. Please be more specific.
Dino
___
Int-area mailing list
Int-are
Dino,
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: Wednesday, December 08, 2021 5:18 AM
> To: Templin (US), Fred L
> Cc: to...@strayalpha.com; int-area@ietf.org
> Subject: Re: [Int-area] Side meeting follow-up: What exact features do we
> want from the
—
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
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
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
All waists, like all layers except those that touch the physical (e.g., MAC
protocols) are relative.
It’s a lot like the ‘end’ in E2E. It was thought to imply “that which can be
kicked”, but it’s really “that which *I* can kick”.
Once you accept this relativity, everything else just works - inc
> Yes, I agree but I am not convinced we need to solve this by adding the
> complexity in L3 and hence through out the whole of the Internet
> rather than further up the protocol stack.
AERO and OMNI do not solve this at L3; they solve it in the adaptation layer
(i.e.,
lower down the protocol st
13 matches
Mail list logo
