I am not at the stage of trying to work out the details of such discovery of capabilities. I am sure it can be done. I am still stuck at understanding what you consider to be the most easily explained benefit for the network devices ...
Cheers Toerless On Wed, Feb 02, 2022 at 06:58:27PM +0000, Templin (US), Fred L wrote: > Toerless, I have another thought to consider. In addition to an initial > end-to-end > connection handshake (e.g., a TCP option), the source host can send a "ping" > IP parcel that consists of only an IP header with a non-zero IP {Total, > Payload} > Length field, a Jumbo Payload option and a single ICMP Echo Request message > body as the parcel contents. If the destination host gets the parcel, it can > send > back an ICMP Echo Reply in a non-parcel IP packet. That would support a uni- > directional parcel test for the forward path only, and an analogous test would > be needed for the reverse path if IP parcels are desired in the reverse > direction. > > A lot can be told if the ping parcel reaches all the way to the destination. > First, > it tells that the source is willing to send parcels. Second, it tells that > all links on > the path are parcel-capable. And finally, if we allow the ping to carry one > of Bob > and Gorry's MTU options it can also give an indication of the maximum parcel > size that can be accepted along the path. > > What do you think? > > Fred > > > -----Original Message----- > > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin > > (US), Fred L > > Sent: Wednesday, February 02, 2022 9:58 AM > > To: Toerless Eckert <t...@cs.fau.de> > > Cc: int-area@ietf.org > > Subject: Re: [Int-area] IP parcels > > > > 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 > -- --- t...@cs.fau.de _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area