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

Reply via email to