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:t...@cs.fau.de] > Sent: Wednesday, February 02, 2022 7:53 AM > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: Tom Herbert <t...@herbertland.com>; to...@strayalpha.com; > int-area@ietf.org > 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
