Subject: Re: [Int-area] IP parcels

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Feb 2022 19:29:09 +0100

Fred,

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.
Q2: If there is this dependency, how do you think the parcel draft could go to
    standard given how OMNI is individual submission.

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 ?

Thanks
    Toerless

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 1 Feb 2022 20:14:08 +0000

Hi Toerless, thanks for these questions and see below for responses:

> -----Original Message-----
> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2022 10:29 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Tom Herbert <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Int-area] IP parcels
> 
> Fred,
> 

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.

>     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.

>     that does not support parcels, the parcel is fragmented into normal/non-parcel

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 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?

Fred

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Feb 2022 16:52:58 +0100

> 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.

> pick up on the parcel concept in the future.

See above.

> forward each segment separately as an independent IP packet toward the final

I think your 3) is what i was asking, and i don't see this explicitly written up
in the document.

> to a first encapsulating node.

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