On Wed, Feb 02, 2022 at 05:58:04PM +0000, Templin (US), Fred L wrote:
> 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 you are not interested in an incremental deployment option in the way i
outline ?
(parcel capable sender plus some initial network subnets along the path) ?
>From my experience with IP multicast which we worked out to require hop-by-
hop end-to-end deployment (like of course IP itself) to work automatically,
partial deployment not/badly supported, i can say that you're in for a painfull
slow ride
if you go this route.
Hence my question trying to understand the feasibility of incremental deployment
Cheers
Toerless
> Thanks - Fred
>
> > -----Original Message-----
> > From: Toerless Eckert [mailto:[email protected]]
> > Sent: Wednesday, February 02, 2022 7:53 AM
> > To: Templin (US), Fred L <[email protected]>
> > Cc: Tom Herbert <[email protected]>; [email protected];
> > [email protected]
> > 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
>
--
---
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
