[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

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 <[email protected]>
> Sent: Friday, September 27, 2024 4:58 PM
> To: Templin (US), Fred L <[email protected]>; Tom Herbert <[email protected]>; Tim Chown <[email protected]>
> Cc: Internet Area <[email protected]>; IPv6 List <[email protected]>
> 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 -- [email protected]
To unsubscribe send an email to [email protected]