Re: [Int-area] IP parcels

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 21 December 2021 15:03 UTC

Return-Path: <alexandre.petrescu@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 525183A0E13 for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 07:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.181
X-Spam-Level:
X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 j9kRYS09iR_G for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 07:03:01 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A183A0DCD for <int-area@ietf.org>; Tue, 21 Dec 2021 07:03:00 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 1BLF2w75017877 for <int-area@ietf.org>; Tue, 21 Dec 2021 16:02:58 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EDB3A20A575 for <int-area@ietf.org>; Tue, 21 Dec 2021 16:02:57 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E47FF206D78 for <int-area@ietf.org>; Tue, 21 Dec 2021 16:02:57 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 1BLF2v4U010633 for <int-area@ietf.org>; Tue, 21 Dec 2021 16:02:57 +0100
Message-ID: <885e4e47-7298-a748-5e40-cd83544c232f@gmail.com>
Date: Tue, 21 Dec 2021 16:02:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: fr
To: int-area@ietf.org
References: <e382aa5dc9f94a2490db3cd03140f39d@boeing.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <e382aa5dc9f94a2490db3cd03140f39d@boeing.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/qsRO8iVL-Yo5mDlefw2aP1ioJpc>
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:03:05 -0000

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