Brian, RFC2675 standard jumbograms cannot support the transmission of these multi-segment buffers (i.e., parcels) between peer end systems across an arbitrary Internetwork. The source end system needs to insert sufficient ancillary information so that the destination end system can determine the length of each non-final segment and the number of segments included. This is not possible with RFC2675 because the Jumbo Payload HBH option does not include sufficient space for ancillary information and the multitude of MUST/SHOULD/MAY directives in the spec make refactoring of processing rules untenable. IP Parcels and Advanced Jumbos (AJs) provide a new specification and a new construct that is not even based on the Jumbo Payload HBH option to the point that IP parcels can travel over arbitrary Internetworks and AJs are in all ways superior to standard jumbograms.
About integrity, the current Internet link model has the link at each hop perform a link-layer integrity check (usually CRC32) but the effectiveness of those checks begins to diminish for sizes much larger than ~9KB. IP parcels and AJs continue to use these link-layer checks to ensure the integrity of only a leading portion of each parcel/AJ, but leave bulk integrity checking as an end-to-end function. So, the source inserts integrity checks at the IP layer on transmission and the destination verifies the integrity on reception. And, when Forward Error Correction is included, the destination can often correct errors instead of request retransmissions. The rest is all in the drafts, but the above is a pretty good summary. Thank you - Fred > -----Original Message----- > From: Brian E Carpenter <brian.e.carpen...@gmail.com> > Sent: Friday, September 27, 2024 4:58 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com>; Tom Herbert > <t...@herbertland.com>; Tim Chown <tim.ch...@jisc.ac.uk> > Cc: Internet Area <Int-area@ietf.org>; IPv6 List <i...@ietf.org> > Subject: [EXTERNAL] Re: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs) > > EXT email: be mindful of links/attachments. > > > > Another clarification point: > On 28-Sep-24 02:58, Templin (US), Fred L wrote: > > ... > > Plus, packaging as an RFC2675 does not make the parcel eligible for > > transport over an actual > > network Interface because there are insufficient integrity checks. > > RFC2675 notes this and kicks the problem upwards: > > " Note: The 16 bit checksum used by UDP and TCP becomes less accurate > as the length of the data being checksummed is increased. > Application designers may want to take this into consideration." > > It could also have been kicked down to layer 2, of course. HIPPI, for > example, had adequate checksums and parity bits. > > Brian _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
