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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 2 Oct 2020 16:09:10 +0000

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]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 5 Oct 2020 20:41:40 +0000

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. 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.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Friday, October 02, 2020 9:09 AM
> To: [email-masked]
> Subject: OMNI Adaptation Layer (OAL) - Lossless Path MTU Adaptation for the Mobile Internet
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 11:59:31 -0400

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.

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.

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.

    > 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.

    >> 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.
    >>
    >> 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: Mark Smith <[email-masked]>
Date: Wed, 7 Oct 2020 03:39:28 +1100

Hi,

> I was among those who convinced Fred that this was a useful repurposing of

I haven't read to the draft, so this is more general observations.

Unless it is going to have properties and uses that are exactly the same as
site-locals (with all of the issues that caused them to be deprecated),
then I think it is better to allocate new address space for this and a new
name. We have the space, if we didn't we'd have reclaimed the 6bone address
space by now I'd think.

Giving something that has been deprecated a new purpose, while "rebirthing"
the old name with its old and still fairly commonly known and published
semantics (e.g. IPv6 books and training courses), will be very confusing.

I am also generally sceptical of new "site-locals", unless they've been
made to resemble ULAs by having a globally unique ID embedded. Lack of
global uniqueness can create situations where uniqueness is created when it
is needed via NAT. Many of the issues with old site-locals were caused by
them not being globally unique, and complexity and operational issues with
the mechanisms to try to overcome that lack of uniqueness.

Regards,
Mark.

> Fred has gone in
> https://datatracker.ietf.org/doc/html/draft-templin-6man-omni-interface-45#section-8