Re: [Int-area] IP parcels
Toerless Eckert <tte@cs.fau.de> Wed, 02 February 2022 19:08 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155793A1C2F for <int-area@ietfa.amsl.com>; Wed, 2 Feb 2022 11:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.869
X-Spam-Level:
X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UdDoMfgiwYH for <int-area@ietfa.amsl.com>; Wed, 2 Feb 2022 11:08:34 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509273A1C3A for <int-area@ietf.org>; Wed, 2 Feb 2022 11:08:33 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 9FB7F58C4B4; Wed, 2 Feb 2022 20:08:26 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8D9524EA537; Wed, 2 Feb 2022 20:08:26 +0100 (CET)
Date: Wed, 02 Feb 2022 20:08:26 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Message-ID: <YfrWqls+uOr6XofA@faui48e.informatik.uni-erlangen.de>
References: <30fcb1daa52b45719b0a83c37e29a24d@boeing.com> <a4410f45a40a4dce951feda603e70406@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <a4410f45a40a4dce951feda603e70406@boeing.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ldX_9ZwgSn6Ts9to3SOfbTuMcpY>
Subject: Re: [Int-area] IP parcels
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2022 19:08:39 -0000
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-bounces@ietf.org] On Behalf Of Templin (US), Fred L > > Sent: Wednesday, February 02, 2022 9:58 AM > > To: Toerless Eckert <tte@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:tte@cs.fau.de] > > > Sent: Wednesday, February 02, 2022 7:53 AM > > > To: Templin (US), Fred L <Fred.L.Templin@boeing.com> > > > Cc: Tom Herbert <tom@herbertland.com>; touch@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 > -- --- tte@cs.fau.de
- [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] IP parcels Eric Vyncke (evyncke)
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] [EXTERNAL] Re: IP parcels Templin (US), Fred L
- Re: [Int-area] [EXTERNAL] IP parcels touch@strayalpha.com
- Re: [Int-area] [EXTERNAL] Re: IP parcels Tom Herbert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Alexandre Petrescu
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Dino Farinacci
- Re: [Int-area] [EXTERNAL] Re: IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Alexandre Petrescu
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Dino Farinacci
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Christian Huitema
- Re: [Int-area] IP parcels Behcet Sarikaya
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels touch@strayalpha.com
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Tom Herbert
- Re: [Int-area] IP parcels Toerless Eckert
- Re: [Int-area] [EXTERNAL] Re: IP parcels Templin (US), Fred L
- Re: [Int-area] [EXTERNAL] Re: IP parcels Toerless Eckert
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Toerless Eckert
- Re: [Int-area] IP parcels Toerless Eckert
- Re: [Int-area] [EXTERNAL] Re: IP parcels Templin (US), Fred L
- Re: [Int-area] IP parcels Templin (US), Fred L