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

["Templin (US), Fred L" <[e-mail]>]

Tom, your message seems to be repeating past myths that led to fearmongering works like
“Fragmentation Considered Harmful”. It is just not true that there is any problem with reassembly
in the Internet today, and performance tests with tools such as iperf3 readily show that a significant
performance gain is possible using larger packets that incur fragmentation and reassembly than
with smaller packets that require no fragmentation.

You also seem to be assuming the worst about where the reassembler will be located. This proposal
is not asking to put a reassembly engine on the line card of a high speed core router then asking it to
reassemble at line rates in hardware. Instead, the reassembly engine in this proposal will be located
at a Proxy several layers up in the architecture which may need to reassemble before forwarding
further toward downstream-dependent nodes.

AERO and OMNI are good works and very likeable. Conversely, I am not liking seeing these
fearmongering myths propagated by you and others as though they were truths.

Fred

From: Tom Herbert [mailto:[e-mail]]
Sent: Monday, August 01, 2022 10:56 AM
To: Templin (US), Fred L <[e-mail]>
Cc: Juan Carlos Zuniga (juzuniga) <juzuniga=[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10


EXT email: be mindful of links/attachments.






On Mon, Aug 1, 2022 at 9:51 AM Templin (US), Fred L <[e-mail]<mailto:[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):

[cid:image001.png@01D8A702.8A68B240]

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]<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]<mailto:[e-mail]>>; [e-mail]<mailto:[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]] On Behalf Of Juan Carlos Zuniga (juzuniga)
Sent: Thursday, July 28, 2022 11:00 AM
To: [e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of Juan Carlos Zuniga (juzuniga) <juzuniga=[e-mail]<mailto:juzuniga=[e-mail]>>
Date: Wednesday, June 22, 2022 at 2:26 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/int-area