Re: [Int-area] IP parcels

Dino Farinacci <farinacci@gmail.com> Tue, 21 December 2021 15:55 UTC

Return-Path: <farinacci@gmail.com>
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 184243A10DB for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 07:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tRvf3Oj4LgU8 for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 07:55:28 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58993A10E0 for <int-area@ietf.org>; Tue, 21 Dec 2021 07:55:28 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id g28so12927982qkk.9 for <int-area@ietf.org>; Tue, 21 Dec 2021 07:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZCNecbs60O33OBXzoNLGk8xDch/SiYECuJNytwRVa44=; b=FpInwIMtmHrIj4gGiry8Ko7a6b+PTit/CcvMKIhNd9Pa8NkQhDwCvunSEbNoMvB/ZI IaPjmdsDq5BepsJIjPZ6vvzSvhmG9CqonoFEXFOhZwFFogV33/87DQdS26gExSnLMUV7 uNNWSU+Tq8bo1H5FWXCG72KO83QPliHvgk+8C8zIiqCENEmGtVZ6OoM7mofkfKAGhAzL OELKeuzgISEXakWT6mHo4hmwsuyWhHYJP7A0gL7VmFZYnsfCSoikBHIjBXkQaqDQ9bH3 qHeLJTR9w4PYEXepZrEIeCMQuKPlpAou8jOCSXYoARPfqs6N34L6bAUZ+S/KaZjtpzzv uAyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZCNecbs60O33OBXzoNLGk8xDch/SiYECuJNytwRVa44=; b=f2GVEbNK87K7ojtjZS5KpICNvgFgv/Rh5u01mVX9/O2mFO+ATdJOU1PmdCbfPNzKcY kQnMxL+wUpwgryPG/GJae64vxvImrKra83JGHfsox8L1pMITjkq8Ob2WAX9j1NmXDSpi bxrZ1fAfSADkMQehs9hedwmbWpIQCdPAcSjQq43FqK65szuC0VeVq42wXCF9nPmAu8JO LqQvS81awQiMHopS0R9WRInilrZU8Jzo3WE261baICaGp6ujI/kIVSSCwHj17utJCkcz ODxI/jFxH43BnatLsVGvSoKpSqTjotvk7ljYCihlwvKIt82BmHakahZkEhrC3hoJ2+sz EDZA==
X-Gm-Message-State: AOAM533qC54/S5i2Y5J9253jdeRSxaNhEbfDW5Dof+7qdCTAgbD00GPo wWUV0t9NzgyMN+fZf4K9I4bT4ryVuKQ=
X-Google-Smtp-Source: ABdhPJxTzS3rIxXdFqlGs7F07qMtSp/tm4hZrG8+M4fqKwNBsFyjp0N8ujy0L7qK4Ubn5NEZIIDh5g==
X-Received: by 2002:a05:620a:4441:: with SMTP id w1mr2469241qkp.619.1640102126838; Tue, 21 Dec 2021 07:55:26 -0800 (PST)
Received: from smtpclient.apple (174-081-118-031.res.spectrum.com. [174.81.118.31]) by smtp.gmail.com with ESMTPSA id w10sm14887859qkp.121.2021.12.21.07.55.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Dec 2021 07:55:26 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <885e4e47-7298-a748-5e40-cd83544c232f@gmail.com>
Date: Tue, 21 Dec 2021 10:55:23 -0500
Cc: int-area@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <55B8D5CD-3D4D-4410-A278-8724B32C3C8B@gmail.com>
References: <e382aa5dc9f94a2490db3cd03140f39d@boeing.com> <885e4e47-7298-a748-5e40-cd83544c232f@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/KdzPvQjdn4ZbCCBb1ZBAzvPg0A0>
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: Tue, 21 Dec 2021 15:55:33 -0000

This idea has been used in ethernet backplanes (as well as cell based) in switches/routers. The term is frequenty referred to as "super framing" and has been for at least 20 years.

Maybe a suggestion of "super-packet" would be more appropriate. 

The idea works well in short/higher-reliability paths (between cards inside a switch backplane/internal-switch-fabric) but not sure it can be scaled up to a packet network. Note making packets gratiusioly large creates more elephant flows and head-of-line-blocking considerations.

Dino

> On Dec 21, 2021, at 10:02 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> The title and abstract are great.
> 
> About the title, just one little note.  This word 'parcel' is very well
> adapted and suggestive for an English speaker.  I think I heard it very
> well in US English, even though not sure about UK English - to they also
> use 'parcel' to mean a package sent in mail?  Probably yes.
> 
> An 'IP Parcel' is a new concept, akin to an IP packet, IP datagram, or
> to a TCP segment: it is also a delimited 'chunk' of data sent in the
> network.  It is different than an IP packet in that it is made to be
> able to carry more IP packets inside.  An IP tunnel also is known to
> carry another IP packet which itself could carry another packet
> (encapsulated tunnels); however an IP parcel would be different than an
> IP tunnel in that there are less IP headers, presumably, and no trailers
> at all (IP tunnel encapsulation involves trailers, IIRC).  Maybe I could
> understand that if I read the draft.
> 
> The name 'parcel', to a French speaker, makes think it might be a
> 'parcelle'.  That 'parcelle' is a limited domain, like a part of land.
> In our current discussions of 'limited domains' in the Internet, that
> 'parcelle' confuses me.  It is not an 'IP parcelle' limited domain, but
> an 'IP parcel' packet, even though it is pronounced the same.
> 
> Le 18/12/2021 à 02:06, Templin (US), Fred L a écrit :
>> Here's one that should help with shipping, just in time for Christmas. Thanks to everyone for the past and future list exchanges.
>> Fred
>> -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, December 17, 2021 5:00 PM To:
>> i-d-announce@ietf.org Subject: I-D Action: draft-templin-intarea-parcels-00.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> Title           : IP Parcels Author          : Fred L. Templin Filename        : draft-templin-intarea-parcels-00.txt Pages : 8
>> Date : 2021-12-17
>> Abstract: IP packets (both IPv4 and IPv6) are understood to contain a
>> unit of data which becomes the retransmission unit in case of loss.
>> Upper layer protocols such as the Transmission Control Protocol (TCP)
>> prepare data units known as "segments", with traditional arrangements
>> including a single segment per packet.  This document presents a new
>> construct known as the "IP Parcel" which permits a single packet to
>> carry multiple segments.
> 
> It sounds interesting.
> 
> But I wonder whether the IP parcel carries multiple TCP segments (TCP
> payloads that dont have IP headers) or rather multiple IP packets (an IP
> packet might carry a TCP payload)?
> 
> Maybe it's written in the draft, I will have to look.
> 
>> The parcel can be opened at middleboxes on the path with the included
>> segments broken out into individual packets, then rejoined into one
>> or more repackaged parcels to be forwarded further toward the final
>> destination.  Reordering of segments within parcels is unimportant;
>> what matters is that the number of parcels delivered to the final
>> destination should be kept to a minimum, and that loss or receipt of
>> individual segments (and not parcel size) determines the retransmission unit.
> 
> The _segment_ is retransmitted upon segment loss or the entire parcel is?
> 
> Alex
> 
>> The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
>> There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00
>> 
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> _______________________________________________ I-D-Announce mailing
>> list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________ Int-area mailing
>> list Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area