Re: [Int-area] IP parcels

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

Toerless, if we want the IP parcel concept to apply only for OMNI links then I
agree that we should take it up only in that document. But, if we want it to apply
for all links then we also need a standalone document that updates RFC2675
since we are changing some rules associated with the Jumbo Payload option.
I think we will want it to apply for all links.

There are benefits for all three of the source host, network path and destination
host if a parcel can be sent - even if the network path includes other links besides
just an OMNI link. But, I don't think the source host should try to send IP parcels
unless it has assurance that the destination host is prepared to accept them. So,
there are both hop-by-hop and end-to-end considerations to factor into the
equation. What do you think?

Thanks - Fred

> -----Original Message-----
> From: Toerless Eckert [mailto:[e-mail]]
> Sent: Wednesday, February 02, 2022 7:53 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: Tom Herbert <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Int-area] [EXTERNAL] Re: IP parcels
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> On Tue, Feb 01, 2022 at 08:14:08PM +0000, Templin (US), Fred L wrote:
> > > Section 5 of draft-templin-intarea-parcels-06 reads as if there is a mandatory
> > > dependency against draft-templin-6man-omni.
> > > Q1: Is that true ? If not, then i must be overlooking a description how parcels would work
> > >     in the absence of OMNI.
> >
> > IP parcels are packets that both set a non-zero IP {Total, Payload} Length value and
> > also include a Jumbo Payload option. By RFC2675, this constitutes an illegal jumbo
> > and so it is highly unlikely that any native links (let alone native paths) would pass
> > the Parcel unless it was first encapsulated. So, encapsulation is required in any case,
> > and OMNI encapsulation is the prime example given. But, it is possible that some
> > other form of encapsulation besides OMNI might pick up on the concept.
> 
> Thanks. I would strongly suggest to improve the text so that it does not look as
> if parcels depend solely on an individual submission draft - but instead describe
> the dependencies against the underlying layer.
> 
> For once, its not clear to me if/why those parcles could not simply be passed over any
> link-layer that can support frames large enough for a parcel. Likewise, if the parcel
> needs to be hop-by-hop segmented to fit smaller link layer size, a discussion about
> the benefits and downsides of that adaption would certainly be useful for the document.
> 
> > > Q2: If there is this dependency, how do you think the parcel draft could go to
> > >     standard given how OMNI is individual submission.
> >
> > I haven't really thought about that much yet but I don't think OMNI needs to be
> > a normative dependency; some other form of encapsulation might decide to
> > pick up on the parcel concept in the future.
> 
> See above.
> 
> > > Q3: Is it possible for parcel support to only exist on an initial sequence of
> > >     subnets, and as soon as a parcel packet has to be sent out to an interface
> > >     that does not support parcels, the parcel is fragmented into normal/non-parcel
> > >     IP packets ?
> >
> > The parcel can only travel as far as the extent of the encapsulation, and once the
> > encapsulation header is removed the only choices are: 1) deliver the parcel to
> > upper layers in the case of local delivery, 2) insert a new encapsulation header
> > (i.e., re-encapsulate) and forward the parcel further, or 3) unpack the parcel and
> > forward each segment separately as an independent IP packet toward the final
> > destination.
> 
> I think your 3) is what i was asking, and i don't see this explicitly written up
> in the document.
> 
> > I had not really thought about case 3), and I will have to drop back and consider
> > whether that is something we would want to support. And, I think this only applies
> > for the final leg of the path from the decapsulator to the final destination and the
> > same logic cannot be applied for the initial leg of the path from an original source
> > to a first encapsulating node.
> >
> > What do you think?
> 
> If a path from a parcel capable source to a non-parcel capable destination could
> consist of a sequence of one or more subnets thart can carry parcels, ending in a
> router that performs 3), aka: extracting the segments and passing them on as normal
> IP packets over one or more subnets up to the final destination.
> 
> That sounds like the most obvious incremental deployment option.
> 
> 
> Btw: this where just questions i stumbled across. I still haven't gotten to the point
> of understanding what would be the benefit of parcels to existing network hops
> except if there was a clear understanding that packets >> 64kb would create some
> form of benefit for routers/network paths. But as far as i understood the document and
> discussion on the mailing list, you where primarily looking for performance benefits
> on the sending host though, not the network path.
> 
> Cheers
>     Toerless