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:t...@herbertland.com] Sent: Monday, August 01, 2022 10:56 AM To: Templin (US), Fred L <fred.l.temp...@boeing.com> Cc: Juan Carlos Zuniga (juzuniga) <juzuniga=40cisco....@dmarc.ietf.org>; int-area@ietf.org 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 <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> 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:int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>] On Behalf Of Templin (US), Fred L Sent: Friday, July 29, 2022 6:44 AM To: Juan Carlos Zuniga (juzuniga) <juzuniga=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; int-area@ietf.org<mailto:int-area@ietf.org> 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:int-area-boun...@ietf.org] On Behalf Of Juan Carlos Zuniga (juzuniga) Sent: Thursday, July 28, 2022 11:00 AM To: int-area@ietf.org<mailto:int-area@ietf.org> 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 <int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>> on behalf of Juan Carlos Zuniga (juzuniga) <juzuniga=40cisco....@dmarc.ietf.org<mailto:juzuniga=40cisco....@dmarc.ietf.org>> Date: Wednesday, June 22, 2022 at 2:26 PM To: int-area@ietf.org<mailto:int-area@ietf.org> <int-area@ietf.org<mailto:int-area@ietf.org>> 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 Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
