Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10

[Tom Herbert <[e-mail]>]

On Mon, Aug 1, 2022 at 9:51 AM Templin (US), Fred L <
[e-mail]> wrote:

> Juan Carlos and intarea, there is actually much more to be said about this
> from a “big-picture”
>
> standpoint that has not been said yet. In particular, the AERO/OMNI and IP
> Parcels architecture
>
> uniquely enable fast and efficient large object transports in conjunction
> with small-message
>
> interactive communications requiring low latency. It does this by allowing
> large MTU links
>
> (9KB or larger) in edge network data centers while requiring small MTU
> links (9KB or smaller)
>
> in the core transit network. In that way, end systems can send large
> objects in IP Parcels that
>
> take advantage of the larger edge network link MTUs, but become fragmented
> when they
>
> reach an OMNI link ingress node. The fragmentation allows the IP parcel to
> transit the core
>
> network where there are small MTU links, but without interfering with
> interactive small message
>
> communications also transiting the core due to fragmentation interleaving.
> Then, at the far
>
> end the final destination which may also be located in an edge network
> having large MTU
>
> links can efficiently receive the larger IP Parcels.
>
>
>
> This has been known for many decades, but perhaps not widely discussed.
> Back in 1988
>
> when the DECnet architects were bringing FDDI into the architecture, then
> even had a name
>
> for it and called it the “dumbbell configuration” (FDDI in edge networks
> and Ethernet core):
>
>
>
>
>
> So, in this dumbbell model, peer end systems located in the rightmost and
> leftmost FDDI rings
>
> could send IP Parcels up to 4500 bytes and the Ethernet link ingress and
> egress nodes would
>
> fragment and reassemble. The core would therefore see only 1500 byte and
> lesser with fair
>
> sharing interleaving between both bulk transfer and interactive
> communications. Replace the
>
> Ethernet link in the above diagram with a network of networks and
> configure an OMNI
>
> interface over it, and the same effect can be had using AERO/OMNI and IP
> Parcels.
>

Hi Fred,

It's not really the same thing. Presumably, at the ingress each 4500 byte
packet would be fragmented and could be serially sent over a PTP Ethernet
link. This makes reassembly at the egress side fairly trivial since one
could assume that all the fragments are received in proper order with no
fragments for other flows mixed in. So the egress side only needs a 4500
byte reassembly buffer.

However, you replace the Ethernet in the picture with an IP network, then
these simplifying properties no longer apply. The egress side may receive
fragments out of order, and there may simultaneously may be multiple flows
in reassembly. So the required memory for reassembly is greater than 4500
bytes, possibly much greater than that. Also, since this is not a PTP link,
packets for a flow may take different paths such that reassembly never
completes and  hence timers are required to punt on reassembly.


>
> This would make for a better and more efficient internetworking service
> for all supporting
>
> a diversity of services ranging from delay-sensitive interactive
> communications to short
>
> transactions, to high data rate binary large object transfers with the
> best properties applied
>
> according to traffic type. It is good for the Internet, therefore
> AERO/OMNI and IP Parcels
>
> are good and should be adopted.
>

As I and others have pointed out, performing reassembly in the network is
costly to routers (i.e. cost in memory at least) and difficult to get right
otherwise (e.g. many edge conditions, trade offs between a non
work-conserving opportunistic optimization and tail case latency). If you
remove in-network reassembly from the proposal, there is still potential
for "intelligent" fragmentation in the network where losing a fragment
doesn't mean losing the whole packet, but it's not clear to me that the
benefits for that outweigh the costs.

Tom


>
>
> Fred
>
>
>
> *From:* Int-area [mailto:[e-mail]] *On Behalf Of *Templin
> (US), Fred L
> *Sent:* Friday, July 29, 2022 6:44 AM
> *To:* Juan Carlos Zuniga (juzuniga) <juzuniga=[e-mail]>;
> [e-mail]
> *Subject:* Re: [Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
>
>
> FYI, a new draft version is posted with the following updates:
>
>
>
> 1) Senders encodes the number of segments included in the Jumbo Payload
> header so receivers
>
>     can accurately determine packaging sizes.
>
>
>
> 2) Excuses OAL intermediate nodes from having to perform parcel
> sub-dividing or re-combining.
>
>
>
> Fred
>
>
>
> *From:* Int-area [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Juan Carlos Zuniga (juzuniga)
> *Sent:* Thursday, July 28, 2022 11:00 AM
> *To:* [e-mail]
> *Subject:* [EXTERNAL] Re: [Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
>
>
> EXT email: be mindful of links/attachments.
>
>
>
>
> Hi all,
>
>
>
> As mentioned during the meeting, we will close the call at the end of the
> IETF 114 week.
>
>
>
> If you have any last comments, please speak up.
>
>
>
> Best,
>
>
>
> Juan Carlos & Wassim
>
>
>
> *From: *Int-area <[e-mail]> on behalf of Juan Carlos
> Zuniga (juzuniga) <juzuniga=[e-mail]>
> *Date: *Wednesday, June 22, 2022 at 2:26 PM
> *To: *[e-mail] <[e-mail]>
> *Subject: *[Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
> Dear IntArea WG,
>
>
>
> We are starting a 2-week call for adoption of the IP-Parcels draft:
>
> https://www.ietf.org/archive/id/draft-templin-intarea-parcels-10.html
>
>
>
> The document has been discussed for some time and it has received multiple
> comments.
>
>
>
> If you have an opinion on whether this document should be adopted by the
> IntArea WG please indicate it on the list by the end of Wednesday July 6th
> .
>
>
>
> Thanks,
>
>
>
> Juan-Carlos & Wassim
>
> (IntArea WG chairs)
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>