Re: [Int-area] [EXTERNAL] Re: IP parcels
Toerless Eckert <tte@cs.fau.de> Wed, 02 February 2022 15:53 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 E5AE93A13A4 for <int-area@ietfa.amsl.com>; Wed, 2 Feb 2022 07:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.65
X-Spam-Level:
X-Spam-Status: No, score=-6.65 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_PASS=-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 39UE8sqiyu3o for <int-area@ietfa.amsl.com>; Wed, 2 Feb 2022 07:53:05 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 B2A113A13BA for <int-area@ietf.org>; Wed, 2 Feb 2022 07:53:03 -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 25D5358C4B4; Wed, 2 Feb 2022 16:52:58 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 12E7F4EA533; Wed, 2 Feb 2022 16:52:58 +0100 (CET)
Date: Wed, 02 Feb 2022 16:52:58 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Tom Herbert <tom@herbertland.com>, "touch@strayalpha.com" <touch@strayalpha.com>, "int-area@ietf.org" <int-area@ietf.org>
Message-ID: <Yfqo2sReFNi4R5lI@faui48e.informatik.uni-erlangen.de>
References: <d6c6fec034a74e319cc9840ecb0f5603@boeing.com> <Yfl79dv6WxMuN0Ty@faui48e.informatik.uni-erlangen.de> <4542b9d32f2b4a578cd79875a9fdadc5@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4542b9d32f2b4a578cd79875a9fdadc5@boeing.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/iYphg5ioicB_Sj_XEIwFhJ8l4cU>
Subject: Re: [Int-area] [EXTERNAL] Re: 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 15:53:18 -0000
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] 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