Subject: Re: OMNI Adaptation Layer (OAL) - Lossless Path MTU Adaptation for the Mobile Internet

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 6 Oct 2020 16:44:00 +0000

Thank you, Michael - see below:

> -----Original Message-----
> From: Michael Richardson [mailto:[email-masked]]
> Sent: Tuesday, October 06, 2020 9:00 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]
> Subject: Re: OMNI Adaptation Layer (OAL) - Lossless Path MTU Adaptation for the Mobile Internet
> 
> 
> Templin (US), Fred L <[email-masked]> wrote:
>     > Folks, I have been waiting a long time for someone in the IETF to tell
>     > me it is OK to re-purpose the IPv6 Site-Local Addressing (SLA) range
>     > for use with my documents but have heard only silence.
> 
> I was among those who convinced Fred that this was a useful repurposing of
> the site-local range.

Yes, this is why you were added to the acknowledgements section. I do also
remember the "deprecation event" from 16 years ago, when it was impressed
on me by some individuals who will remain nameless that it was something I
should take note of. But, I had honestly put that out of my mind under the
wrong impression that "deprecates means deprecates for all time".

With clearer hindsight vision thanks to your input, however, it just would not
make sense to throw away a significant and useful portion of the IPv6 address
space forever when it could instead contribute in a big way to the future of
mobile Internetworking. So, thanks for the useful perspective!

> Not to resurrect SLA itself, but as a useful place for the things that AERO/OMNI need.
> Fred has gone in https://datatracker.ietf.org/doc/html/draft-templin-6man-omni-interface-45#section-8
> and used the SLA term, which isn't what I would say.
> It's just the 10 bits that he wants, not the term and semantics.

I have to say that I like the terminology "xLA", which could be any one of
LLA, SLA or ULA. So, I think the acronym SLA fits well but maybe we could
rename it slightly as "Segment Local Address" - which would fit well with
the AERO/OMNI bridged topology which joins link segments the same as
for L2 bridging.

> SLA was unworkable as originally defined because the boundary was unclear.
> They were also hard to use for applications, and ambiguous is passed around
> inside applications.
> 
> RFC3879 says:
>    The
>    special behavior of this prefix MUST no longer be supported in new
>    implementations.  The prefix MUST NOT be reassigned for other use
>    except by a future IETF standards action.  Future versions of the
>    addressing architecture [RFC3513] will include this information.
> 
> 1) AERO/OMNI's definition of them makes the boundary clear.
> 2) The addresses are never seen by applications, but are used for
>    automatic tunnelling, so there is never an application involved.
> 3) There is no special %1 mechanism needed.

Correct.
 
>     > So, I have taken
>     > the step of writing SLAs into the AERO and OMNI specs in place of the
>     > ULA text that was there previously. The intention is that AERO/OMNI
>     > will set aside the RFC3879 deprecation and bring SLAs back into active
>     > use for a good purpose. If anyone has any thoughts on this, please
>     > review the latest AERO/OMNI specs and post comments.
> 
> I wouldn't think of this as "setting aside RFC3879",
> rather as updating RFC3513 to provide a new use for this space.

We have moved on to RFC4291 - do we say that we update RFC4291 then?

Thanks - Fred

>     >> Hi, an adoption call is in progress for the OMNI spec:
>     >>
>     >> https://mailarchive.ietf.org/arch/msg/ipv6/v5wQHVoX_Ad3OF0oGP7CBXwyTSs/
>     >> https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
>     >>
>     >> Section 5 of the document now includes an "OMNI Adaptation Layer
>     >> (OAL)" specification. The OAL allows the OMNI interface to span
>     >> multiple available underlying interfaces (and/or networked paths) with
>     >> diverse MTUs while providing real-time adaptive packet size
>     >> adjustments without loss. It operates at a layer below IP but above
>     >> the data link layer, and its hallmark architectural features include:
>     >>
>     >> 1) IPv6 ND per RFC4861 but with new OMNI option 2) RFC2473
>     >> Encapsulation 3) IPv6 Fragmentation and Reassembly 4) Packet-Too-Big
>     >> (PTB) "soft errors" 5) Support for either IP protocol version
>     >>
>     >> Items 2 through 4 in particular contribute to what amounts to
>     >> "Lossless Path MTU Adaptation" - a holy grail objective. The OAL works
>     >> by accepting packets of various sizes from the network layer and
>     >> performing RFC2473 encapsulation and IPv6 fragmentation to ensure that
>     >> the packets will fit over the selected underlying data link
>     >> interface. At the same time, the OAL can send PTB "soft errors" back
>     >> to the original source. These soft errors indicate that the network is
>     >> experiencing some level of discomfort with the current packet size, so
>     >> the original source should reduce the size of the packets it
>     >> sends. But, no packets are lost thanks to OAL IPv6 fragmentation and
>     >> reassembly, and therefore no retransmissions are necessary.
>     >>
>     >> Some might look at this design and ask: "well, isn't this really just
>     >> AAL5"?  Yes and no; AAL5 assumes a specific maximum cell size
>     >> (ATM). Conversely, OAL operates over any underlying data link MTU size
>     >> and so MTU diversity is naturally accommodated. When presented with an
>     >> unprobed network path, however, OAL does fall back on the certainties
>     >> of the minimum path MTUs for IPv4 (576) and IPv6 (1280) networked
>     >> paths.
>     >>
>     >> A key aspect of OAL is real-time adaptation to changing path MTU
>     >> dynamics.  RFC1191 and RFC8201 call for a delay of at least 10mins for
>     >> the source to begin sending larger packets after having received a PTB
>     >> hard error in order to avoid (further) loss. With the OAL, however,
>     >> when a source receives a PTB soft error it can adaptively test for
>     >> larger packet sizes at any time (at the expense of possibly receiving
>     >> additional soft errors) without fear of costly data loss and
>     >> retransmissions. This results in a real-time adaptation service that
>     >> seeks and utilizes an optimum packet size, which may change
>     >> dynamically over time due to path changes related to mobility, link
>     >> quality, etc. This makes the OAL especially well-suited to wireless
>     >> environments.
>     >>
>     >> Wrapping up, the OAL is now documented in the OMNI spec which I invite
>     >> everyone to read. Please respond to this thread with any questions or
>     >> comments for what I have outlined above. Please respond to the
>     >> adoption call thread to voice support for the adoption call.
>     >>
>     >> Thank you,
>     >>
>     >> Fred Templin [email-masked]
>     >>
>     >> --------------------------------------------------------------------
>     >> IETF IPv6 working group mailing list [email-masked] Administrative
>     >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     >> --------------------------------------------------------------------
> 
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list [email-masked] Administrative
>     > Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
> 
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 13:51:24 -0400

Templin (US), Fred L <[email-masked]> wrote:
    >> Not to resurrect SLA itself, but as a useful place for the things that
    >> AERO/OMNI need.  Fred has gone in
    >> https://datatracker.ietf.org/doc/html/draft-templin-6man-omni-interface-45#section-8
    >> and used the SLA term, which isn't what I would say.  It's just the 10
    >> bits that he wants, not the term and semantics.

    > I have to say that I like the terminology "xLA", which could be any one
    > of LLA, SLA or ULA. So, I think the acronym SLA fits well but maybe we
    > could rename it slightly as "Segment Local Address" - which would fit
    > well with the AERO/OMNI bridged topology which joins link segments the
    > same as for L2 bridging.

To me, it causes (human) search engine overload to reuse the term.

If 6man thinks you should be allocated a different /10, then we can at least
discuss it better if we have a new term.
(And the way that OMNI embeds the addresses make them distinct among all
users, to the extent that the original addresses were distinct)

    >> > So, I have taken > the step of writing SLAs into the AERO and OMNI
    >> specs in place of the > ULA text that was there previously. The
    >> intention is that AERO/OMNI > will set aside the RFC3879 deprecation
    >> and bring SLAs back into active > use for a good purpose. If anyone
    >> has any thoughts on this, please > review the latest AERO/OMNI specs
    >> and post comments.
    >>
    >> I wouldn't think of this as "setting aside RFC3879", rather as
    >> updating RFC3513 to provide a new use for this space.

    > We have moved on to RFC4291 - do we say that we update RFC4291 then?

Uhm, yes, of course. (Duh on me)
I was really just echoing the 3879 pointer/advice.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 6 Oct 2020 17:54:36 +0000

BTW, I am quite sure that there are a significant number of long-time readers of this
list who know very well what AERO and OMNI are about, and know that the concepts
have been under development for more than two decades and finally coming together
in one place. It is time for them to come out of hiding now and start talking about this
openly so we can move on to the next-generation IPv6-based Mobile Internet.

Thanks - Fred 

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Tuesday, October 06, 2020 9:44 AM
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6