Subject: Re: [Int-area] IP parcels

From: "Templin (US), Fred L" <[email-masked]>
Date: Sun, 19 Dec 2021 18:21:39 +0000

Joe, your insistence on using html makes it impossible to respond to all of your points inline
which is the reason for my top-posts. And by top-posting, I am unable to respond to each of
your points individually – so if it seems I am ignoring some points I am not; some simply get
lost as a result of the top-posting. So, here is my attempt at addressing this message:

Parcels that contain a single segment whether 64K or considerably less are still sent as
(singleton) parcels and not ordinary packets. That way, nodes in the network can know
that it is OK to encapsulate and fragment since by asserting its interest in receiving parcels
the destination has also subscribed to being able to reassemble up to a full 64K.

Parcels do not set (Payload Length / Total Length) to 0; they set it to the length of the
first element of the parcel (which is also the same length of each non-final element of
the parcel). What happens then is that network equipment will see a unit with an L3
length that may be considerably shorter than the L2 length. You are right that legacy
routers might not like this (or, they might truncate the packet according to L3 length),
and so for paths that might traverse legacy routers the first-hop node that recognizes
parcels instead encapsulates the parcel in an IPv4 or IPv6 header then performs (source)
fragmentation if necessary. These IP fragments will then travel through legacy routers
just fine.

About RFC793bis, you and Wes Eddy know far more about its status than I do; I only
noted that this is something with TCP implications and so made mention of it in case
there is still room for a few more engine tweaks while the hood is still open.

About IPv4, I am currently running IPv4 edge networks with IPv4-in-IPv6 tunnel endpoints
connected to an IPv6 transit network and it works really good. End systems get to use
smaller addresses and smaller headers, and they can talk to remote correspondents using
IPv4 as if they were all on the same IPv4 network. So yes, I think we might still want to
consider IPv4 for edge networks like that.

About getting 64K packets across, only the edge networks or end systems see them as
large packets; in the core thy are typically broken up into something much smaller by
ingress nodes that apply segmentation/fragmentation. We don’t need the core to move
to jumbo links; we only need that at the edges. ATM taught us that.

About our “nail”, end systems get to see larger packets/parcels and get to take advantage
of the reduced interrupts and system call overhead they provide. That is what makes it
worthwhile.

Fred

From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, December 18, 2021 8:13 PM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]; Wes Eddy <[email-masked]>
Subject: Re: [Int-area] IP parcels

HI, Fred,

If you have one segment that’s less than 64K, you don’t need the parcel option at all.

If you have something longer than 64K, either as a single segment or multiple smaller segments, by setting total length to 0, you end up being dropped by legacy routers, which either ignore options they don’t understand or drop packets with options they don’t support.

RFC793bis does talk about IPv6 jumbos, but this new work is out of scope for RFC793bis - furthermore, it’s too late. It has passed WGLC, IETF LC, and is currently in IESG review for publication.

You also haven’t addressed why the IETF should be taking up this *new* work for IPv4, which I thought also had been considered ineligible.

But overall, again, what’s the point? We can’t even get 64K IP packets through the Internet; making them larger doesn’t make that easier or more likely. Such large sizes are of diminishing benefit; routers already forward at 40Gbps per link for minimal packets and end systems have other problems that this exacerbates.

This seems a lot like a huge hammer in search of a nail. Where’s the nail?

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Dec 18, 2021, at 7:18 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Joe, I never said that I wanted to restrict this to small transport segments; in fact, I want
just the opposite – I want large segments. A perfectly legal parcel is one which includes 1
~64KB segment - another legal parcel is one which includes 64 of them! If you want bigger
segments than that, then true jumbos are necessary and this spec does not preclude that.

About RFC793(bis), I see there is a section on Jumbos and IP parcels is (sort of) an application
of Jumbos.

Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Saturday, December 18, 2021 4:57 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Wes Eddy <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Int-area] IP parcels

EXT email: be mindful of links/attachments.

Hi, Fred,

Regarding 793bis, new ideas are out of scope. It’s supposed to be a roll-in of existing items only.

Nevermind the problems below, which “TCP will find a way” doesn’t magically fix.

The problem is this:
- end systems need to send larger transport segments (not just IP segments)
- if they can do that, they should, filling up to the largest IP payload

Having an IP packet have the opportunity to include lots of small transport packets assumes transport packets either work better or faster when they’re small. It’s the opposite.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>

On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Joe, TCP will find a way to adapt – it always has. I also see that TCP is currently undergoing
a second edition revision so the timing seems right to consider IP parcels in the analysis.
I am Cc’ing the second edition editor for his information – Wesley, please consider this
new concept called “IP Parcels” as it relates to your document.

Here is the latest draft version – it expands on the “Motivation” section and adds a number
of important feature such as a new “Parcels Permitted” TCP option:

https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/

Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, December 17, 2021 6:01 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] IP parcels

Hi, Fred,

I’m first concerned at the use of an IP option at all, due to the problems with *any* options forcing processing to slow-path.

From TCP’s viewpoint, it seems like you’ve just created a nightmare for SACK and ECN, basically because you will encourage drops of large bursts of packets.

This will also increase the bustiness of TCP, i.e., rather than letting the ACKs support pacing.

Any part of the system that currently coalesces TCP packets is likely to generate errors here, because they might see only the first TCP segment.

However, AFAICT the most significant consideration is that  the issue with per-packet performance is at the TCP and UDP layers, not as much at the IP layer.

So what problem is this trying to solve?

Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>

On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

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:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, December 17, 2021 5:00 PM
To: [email-masked]<mailto:[email-masked]>
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.  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 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<http://rsync.ietf.org/>::internet-drafts

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 19 Dec 2021 11:53:12 -0800

Hi, Fred (et al.),

> On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> which is the reason for my top-posts.

I use MacOS mail, IOS mail, and Thunderbird on Windows, all using default configurations, FWIW. I appear to be able to post inside everyone else’s responses. I don’t know if the IETF’s mailers are munging formats, though.

I’ve made my position clear. However:

- You still haven’t shown any evidence that end systems need to do all this extra work so they can somehow run faster, nor that this will be noticeably faster than large (i.e., 20-60KB) IPv4 packets.

- You still haven’t shown any reason why this is feasible; in fact, below you add the idea of on-path fragmentation, which is largely deprecated because fragments won’t traverse tunnels (in your case, notably for single chunks larger than 64KB). Nevermind that the fragmentation is both expensive and slow-path at routers.

- You have claimed that both routers and transports will somehow adopt this when we can’t even get reasonably large MTUs that already fit within IPv4 across heterogeneous enterprises.

IPv4 is over; even if you don’t think so, any way forward with larger packets starts with:
	a) getting ~64KB IP packets across the net
	b) after (a), prove that >64KB are needed based on the IPv6 jumbo approach

Any way forward with a lot of small packets inside one large one (where both chunks and total length are less than 64K) starts by proving there’s a need and it fixing how TCP interacts with its inherent burstiness and loss correlation.

Only THEN will this issue be worth more discussion.

Joe

> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Wes Eddy <[email-masked] <mailto:[email-masked]>>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Dec 18, 2021, at 7:18 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Wes Eddy <[email-masked] <mailto:[email-masked]>>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> 
> On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ <https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/>
>  
> Fred
>  
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> 
> 
> On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: I-D-Announce [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ <https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/>
> 
> https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00 <https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00>
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 20 Dec 2021 15:00:19 +0000

Joe, I will do my best to respond to your points in the following top posts; you may not
like it but it is the best I can do:

There is evidence supplied in the latest parcel draft versions, beginning with the -02.

This will involve unpacking of the parcel and placing the unpacked sub-parcels
into a tunnel as the (unfragmented) transit packet. Then, if any fragmentation
is necessary, the OMNI link ingress fragments the *tunnel* packet; not the
*transit* packet. And, this work will occur only at OMNI ingress and egress
nodes and not at any high-speed routers on the path. Those routers will see
only MTU-sized and smaller IP packets whizzing past at line rate.

No, not routers. Routers will continue to see only line-rate and MTU or smaller
sized IP packets. Only the end systems and the OMNI ingress/egress nodes need
to do any extra work.

I still have IPv4 working really good in environments where the longer IPv6 addresses
are not necessary, and the network layer headers are only half the size. Why would I
throw that away? About getting ~64KB across the net, parcels have that covered with
IP fragmentation/reassembly used if necessary. And end systems only receive parcels
if they ask for them, which means that they assert they can reassemble all the way up
to 64KB as opposed to restricting to something smaller like the 576/1500 minimum.
About exceeding 64KB, we will want to start out doing that with parcels that contain
multiple smaller segments instead of sending just a single large segment for peers that
are located in different edge networks joined by an OMNI link. You may be right that
peers in the same edge network with huge link MTUs may eventually want to use true
jumbos (i.e., that carry large segments) but for going over the core parcels are a better.

The world is not just TCP anymore. QUIC and other UDP-based transports have already
shown performance increases using facilities like GSO/GRO which are essentially a short
term and non-standard implementation of what parcels promise to do in the long term.

Thanks - Fred

Sent: Sunday, December 19, 2021 11:53 AM

Hi, Fred (et al.),

On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Joe

Fred

HI, Fred,

Joe

—

Fred

Hi, Fred,

The problem is this:

Joe

—

Fred

Hi, Fred,

Joe
—

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, December 17, 2021 5:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-templin-intarea-parcels-00.txt

       Title           : IP Parcels
       Author          : Fred L. Templin

Abstract:

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 20 Dec 2021 07:50:31 -0800

Hi, Fred,

You haven’t addressed my concerns.

Comparing this to GRO/GSO (which are not mentioned in RFC9000) only highlights its challenges; GRO/GSO packs up to the existing path MTU, i.e., it’s for packets smaller than the path MTU; it never comes into play for protocols that send packets already at the size of the path MTU. Its packets also traverse NATs. 

Note also that RFC8200 doesn’t mention the IPv6 jumbo option, which notably excludes concurred use of the fragment option. You might check why both authors made those choices.

Until path MTUs noticeably increase, approach serves only to increase the use of IP source fragmentation where it could otherwise be avoided, IMO, it’s DOA.

Joe

—
www.strayalpha.com

> On Dec 20, 2021, at 7:00 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 20 Dec 2021 09:20:10 -0800

> term and non-standard implementation of what parcels promise to do in the

Fred,

Can you explain why GSO/GRO aren't sufficient and are only short term
solutions? We've been using these for almost twenty years now with good
effect. These are widely deployed with TCP, TSO works well to offload
transmit, LRO is defined and is in much better shape to offload RX now that
programmable devices are emerging. For TCP it's hard to see how IP parcels
would help significantly, but even for UDP we now have UDP GSO, sendmmsg,
and recvmmsg that mitigate the cost of system calls and interrupts to which
the draft refers. The reason these aren't standards in IETF is because
they're implementation techniques and not protocol (although I will point
out that GSO/GRO/sendmmsg/recvmmsg are in all Linux devices so that
effectively makes it a de facto implementation standard).

I am also concerned about the idea that intermediate devices would perform
reassembly. This has a whole bunch of implications like middleboxes are no
longer work conserving and seems to have the implicit requirement that it
has to be in the path of every packet in a parcel (i.e. even in the case of
the last hop performing reassembly. Also, as simply a matter of resources
and capabilities, hosts are in a much better position to perform tasks like
reassembly. I don't readily see that having intermediate devices perform
reassembly would be a win for hosts, and even if it were, host
implementations still would need the capability to perform reassembly
themselves since they will never rely on the network to always do it for
them.

Tom

>
>
> Thanks - Fred
>
>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Sunday, December 19, 2021 11:53 AM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]; Wes Eddy <[email-masked]>
> *Subject:* Re: [Int-area] IP parcels
>
>
>
> Hi, Fred (et al.),
>
>
>
> I use MacOS mail, IOS mail, and Thunderbird on Windows, all using default
> configurations, FWIW. I appear to be able to post inside everyone else’s
> responses. I don’t know if the IETF’s mailers are munging formats, though.
>
>
>
> - You still haven’t shown any evidence that end systems need to do all
> this extra work so they can somehow run faster, nor that this will be
> noticeably faster than large (i.e., 20-60KB) IPv4 packets.
>
>
>
> - You still haven’t shown any reason why this is feasible; in fact, below
> you add the idea of on-path fragmentation, which is largely deprecated
> because fragments won’t traverse tunnels (in your case, notably for single
> chunks larger than 64KB). Nevermind that the fragmentation is both
> expensive and slow-path at routers.
>
>
>
> - You have claimed that both routers and transports will somehow adopt
> this when we can’t even get reasonably large MTUs that already fit within
> IPv4 across heterogeneous enterprises.
>
>
>
> Any way forward with a lot of small packets inside one large one (where
> both chunks and total length are less than 64K) starts by proving there’s a
> need and it fixing how TCP interacts with its inherent burstiness and loss
> correlation.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Saturday, December 18, 2021 8:13 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]; Wes Eddy <[email-masked]>
> *Subject:* Re: [Int-area] IP parcels
>
>
>
> HI, Fred,
>
>
>
> If you have something longer than 64K, either as a single segment or
> multiple smaller segments, by setting total length to 0, you end up being
> dropped by legacy routers, which either ignore options they don’t
> understand or drop packets with options they don’t support.
>
>
>
> RFC793bis does talk about IPv6 jumbos, but this new work is out of scope
> for RFC793bis - furthermore, it’s too late. It has passed WGLC, IETF LC,
> and is currently in IESG review for publication.
>
>
>
> You also haven’t addressed why the IETF should be taking up this *new*
> work for IPv4, which I thought also had been considered ineligible.
>
>
>
> But overall, again, what’s the point? We can’t even get 64K IP packets
> through the Internet; making them larger doesn’t make that easier or more
> likely. Such large sizes are of diminishing benefit; routers already
> forward at 40Gbps per link for minimal packets and end systems have other
> problems that this exacerbates.
>
>
>
> On Dec 18, 2021, at 7:18 PM, Templin (US), Fred L <
> [email-masked]> wrote:
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Saturday, December 18, 2021 4:57 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]; Wes Eddy <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Int-area] IP parcels
>
>
>
> Having an IP packet have the opportunity to include lots of small
> transport packets assumes transport packets either work better or faster
> when they’re small. It’s the opposite.
>
>
>
> Joe
>
>
>
> —
>
> On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L <
> [email-masked]> wrote:
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, December 17, 2021 6:01 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Int-area] IP parcels
>
>
>
> Hi, Fred,
>
>
>
> I’m first concerned at the use of an IP option at all, due to the problems
> with *any* options forcing processing to slow-path.
>
>
>
> From TCP’s viewpoint, it seems like you’ve just created a nightmare for
> SACK and ECN, basically because you will encourage drops of large bursts of
> packets.
>
>
>
> Any part of the system that currently coalesces TCP packets is likely to
> generate errors here, because they might see only the first TCP segment.
>
>
>
> However, AFAICT the most significant consideration is that  the issue with
> per-packet performance is at the TCP and UDP layers, not as much at the IP
> layer.
>
>
>
> On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <
> [email-masked]> wrote:
>
>
>
> From: I-D-Announce [mailto:[email-masked]
> <[email-masked]>] On Behalf Of [email-masked]
> To: [email-masked]
> Internet-Drafts are also available by rsync at rsync.ietf.org
> ::internet-drafts
>
>
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Dec 2021 22:48:09 +0100

Le 19/12/2021 à 20:53, [email-masked] a écrit :
> Hi, Fred (et al.),
> 
>> On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>> 
>> Joe, your insistence on using html makes it impossible to respond 
>> to all of your points inline which is the reason for my top-posts.
>> 
> 
> I use MacOS mail, IOS mail, and Thunderbird on Windows, all using 
> default configurations, FWIW. I appear to be able to post inside 
> everyone else’s responses. I don’t know if the IETF’s mailers are 
> munging formats, though.

I think the IETF's mailers (smtp) dont mangle things at this level.
They dont change the format of a message, they just forward them.  They
might change the format of a message that is stored in the archive for
display on the web, but not the forwarded.

Rather, there is a difference between pure text in emails, MIME pure
text, MIME html pure text and MIME html fixed fonts.

Moreover, there is a difference between ' and ’ even for simple quotes.
  That difference shows how we speak different languages: the language of
the Mac and the language of Windows.  This difference stems from the
difference between 7-bit ASCII, ASCII and later versions such as UTF-8
and unicode.  A distinct quote symbol is present in all these versions.
  Each one is more beautiful than the other, but the meaning of a simple
quote is the same: it's a straight quote and not a backquote `.

At the same time, there are many quoting formats in other languages that
are not that popular in encoding systems.  For example the opening
quotes „ in German are rarely seen when quoting German words even though
we should.  Or the << in French.  In these languages there are no
straight quotes or back quotes.

To be fairer to these languages, one should offer more place for these
special characters in the encoding systems, and we should see more such
apparent mistakes in emails at IETF.

It is the same about the center dots: there are many encodings for these
bullet dots but rarely do we see them on emails.  Rather, we should have
systems that promote them more, because they are essentials in itemized
lists in English, and in the gender neutrality words in French.  These
are so important these days that they go beyond the importance of MIME
or html.  They should have been in the 7-bit ASCII.  And there are many
symbols in 7-bit ASCII that are not that important, and not used
currently.  So, the 7-bit ASCII should be updated.

I think just a few conversers send 7-bit ASCII and MIME-less html-less
emails.  These emails are relatively short and well thought, with
wiseness.  But even these emails are preceded by huge headers of SMTP;
they have a very low efficiency.  One might wonder why all the 'overhead'.

It is the same problem as with huge IPv6 headers for just a bit of
on-off data in IoT.

The huge size of SMTP headers compared to the short ASCII useful text
should not invite to send comparable size payloads (MIME, html, jpg,
mp4) just because the network can.

Maybe one wants an SMTP mechanism that makes small headers for small
payloads and bigger headers for bigger payloads, to be more fair.  Just
as we select the envelope size of a regular letter.

Alex

> - You still haven’t shown any evidence that end systems need to do 
> all this extra work so they can somehow run faster, nor that this 
> will be noticeably faster than large (i.e., 20-60KB) IPv4 packets.
> 
> - You still haven’t shown any reason why this is feasible; in fact, 
> below you add the idea of on-path fragmentation, which is largely 
> deprecated because fragments won’t traverse tunnels (in your case, 
> notably for single chunks larger than 64KB). Nevermind that the 
> fragmentation is both expensive and slow-path at routers.
> 
> - You have claimed that both routers and transports will somehow 
> adopt this when we can’t even get reasonably large MTUs that already 
> fit within IPv4 across heterogeneous enterprises.
> 
> IPv4 is over; even if you don’t think so, any way forward with
> larger packets starts with: a) getting ~64KB IP packets across the
> net b) after (a), prove that >64KB are needed based on the IPv6
> jumbo approach
> 
> Any way forward with a lot of small packets inside one large one 
> (where both chunks and total length are less than 64K) starts by 
> proving there’s a need and it fixing how TCP interacts with its 
> inherent burstiness and loss correlation.
> 
>> Parcels that contain a single segment whether 64K or considerably 
>> less are still sent as (singleton) parcels and not ordinary 
>> packets. That way, nodes in the network can know that it is OK to 
>> encapsulate and fragment since by asserting its interest in 
>> receiving parcels the destination has also subscribed to being
>> able to reassemble up to a full 64K. Parcels do not set (Payload
>> Length / Total Length) to 0; they set it to the length of the
>> first element of the parcel (which is also the same length of each
>>  non-final element of the parcel). What happens then is that
>> network equipment will see a unit with an L3 length that may be 
>> considerably shorter than the L2 length. You are right that legacy
>>  routers might not like this (or, they might truncate the packet 
>> according to L3 length), and so for paths that might traverse 
>> legacy routers the first-hop node that recognizes parcels instead 
>> encapsulates the parcel in an IPv4 or IPv6 header then performs 
>> (source) fragmentation if necessary. These IP fragments will then 
>> travel through legacy routers just fine. About RFC793bis, you and 
>> Wes Eddy know far more about its status than I do; I only noted 
>> that this is something with TCP implications and so made mention
>> of it in case there is still room for a few more engine tweaks
>> while the hood is still open. About IPv4, I am currently running
>> IPv4 edge networks with IPv4-in-IPv6 tunnel endpoints connected to
>> an IPv6 transit network and it works really good. End systems get
>> to use smaller addresses and smaller headers, and they can talk to 
>> remote correspondents using IPv4 as if they were all on the same 
>> IPv4 network. So yes, I think we might still want to consider IPv4 
>> for edge networks like that. About getting 64K packets across,
>> only the edge networks or end systems see them as large packets; in
>> the core thy are typically broken up into something much smaller by
>>  ingress nodes that apply segmentation/fragmentation. We don’t
>> need the core to move to jumbo links; we only need that at the
>> edges. ATM taught us that. About our “nail”, end systems get to see
>> larger packets/parcels and get to take advantage of the reduced
>> interrupts and system call overhead they provide. That is what
>> makes it worthwhile. Fred *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked] 
>> <mailto:[email-masked]>] *Sent:*Saturday, December 18, 2021 
>> 8:13 PM *To:*Templin (US), Fred L <[email-masked] 
>> <mailto:[email-masked]>> *Cc:[email-masked] 
>> <mailto:[email-masked]>; Wes Eddy <[email-masked] 
>> <mailto:[email-masked]>> *Subject:*Re: [Int-area] IP parcels 
>> HI, Fred, If you have one segment that’s less than 64K, you don’t 
>> need the parcel option at all. If you have something longer than 
>> 64K, either as a single segment or multiple smaller segments, by 
>> setting total length to 0, you end up being dropped by legacy 
>> routers, which either ignore options they don’t understand or drop 
>> packets with options they don’t support. RFC793bis does talk about 
>> IPv6 jumbos, but this new work is out of scope for RFC793bis - 
>> furthermore, it’s too late. It has passed WGLC, IETF LC, and is 
>> currently in IESG review for publication. You also haven’t 
>> addressed why the IETF should be taking up this *new* work for 
>> IPv4, which I thought also had been considered ineligible. But 
>> overall, again, what’s the point? We can’t even get 64K IP packets 
>> through the Internet; making them larger doesn’t make that easier 
>> or more likely. Such large sizes are of diminishing benefit; 
>> routers already forward at 40Gbps per link for minimal packets and 
>> end systems have other problems that this exacerbates. This seems
>> a lot like a huge hammer in search of a nail. Where’s the nail? Joe
>>  — Joe Touch, temporal epistemologist www.strayalpha.com 
>> <http://www.strayalpha.com/>
>> 
>> 
>> On Dec 18, 2021, at 7:18 PM, Templin (US), Fred L 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote: Joe, I never said that I wanted to restrict this to small 
>> transport segments; in fact, I want just the opposite – I want 
>> large segments. A perfectly legal parcel is one which includes 1 
>> ~64KB segment - another legal parcel is one which includes 64 of 
>> them! If you want bigger segments than that, then true jumbos are 
>> necessary and this spec does not preclude that. About RFC793(bis), 
>> I see there is a section on Jumbos and IP parcels is (sort of) an 
>> application of Jumbos. Fred *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked] 
>> <mailto:[email-masked]>] *Sent:*Saturday, December 18, 2021 
>> 4:57 PM *To:*Templin (US), Fred L <[email-masked] 
>> <mailto:[email-masked]>> *Cc:[email-masked] 
>> <mailto:[email-masked]>; Wes Eddy <[email-masked] 
>> <mailto:[email-masked]>> *Subject:*[EXTERNAL] Re: [Int-area] 
>> IP parcels  EXT email: be mindful of links/attachments.
>> 
>> 
>> 
>> 
>> Hi, Fred, Regarding 793bis, new ideas are out of scope. It’s 
>> supposed to be a roll-in of existing items only. Nevermind the 
>> problems below, which “TCP will find a way” doesn’t magically fix.
>>  The problem is this: - end systems need to send larger transport 
>> segments (not just IP segments) - if they can do that, they
>> should, filling up to the largest IP payload Having an IP packet
>> have the opportunity to include lots of small transport packets
>> assumes transport packets either work better or faster when they’re
>> small. It’s the opposite. Joe — Joe Touch, temporal epistemologist
>> On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote: Joe, TCP will find a way to adapt – it always has. I also 
>> see that TCP is currently undergoing a second edition revision so 
>> the timing seems right to consider IP parcels in the analysis. I
>> am Cc’ing the second edition editor for his information – Wesley, 
>> please consider this new concept called “IP Parcels” as it relates 
>> to your document. Here is the latest draft version – it expands on 
>> the “Motivation” section and adds a number of important feature 
>> such as a new “Parcels Permitted” TCP option: 
>> <https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/> 
>> Fred *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked] 
>> <mailto:[email-masked]>] *Sent:*Friday, December 17, 2021 
>> 6:01 PM *To:*Templin (US), Fred L <[email-masked] 
>> <mailto:[email-masked]>> *Cc:[email-masked] 
>> <mailto:[email-masked]> *Subject:*Re: [Int-area] IP parcels Hi, 
>> Fred, I’m first concerned at the use of an IP option at all, due to
>> the problems with *any* options forcing processing to slow-path.
>> From TCP’s viewpoint, it seems like you’ve just created a nightmare
>> for SACK and ECN, basically because you will encourage drops of
>> large bursts of packets. This will also increase the bustiness of
>> TCP, i.e., rather than letting the ACKs support pacing. Any part of
>> the system that currently coalesces TCP packets is likely to
>> generate errors here, because they might see only the first TCP
>> segment. However, AFAICT the most significant consideration is that
>> the issue with per-packet performance is at the TCP and UDP layers,
>> not as much at the IP layer. So what problem is this trying to
>> solve? Joe — Joe Touch, temporal epistemologist www.strayalpha.com
>> <http://www.strayalpha.com/>
>> 
>> 
>> 
>> 
>> On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote: 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:[email-masked] 
>> <mailto:[email-masked]>] On Behalf 
>> [email-masked] <mailto:[email-masked]> Sent: 
>> Friday, December 17, 2021 5:00 PM To:[email-masked] 
>> <mailto:[email-masked]> Subject: I-D Action: 
>> draft-templin-intarea-parcels-00.txt
>> 
>> 
>> 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.
>> 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.
>> 
>> 
>> <https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/>
>> 
<https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00>
>> 
>> 
>> Internet-Drafts are also available by rsync atrsync.ietf.org 
>> <http://rsync.ietf.org/>::internet-drafts
>> 
>> 
>> _______________________________________________ I-D-Announce 
>> mailing list [email-masked] <mailto:[email-masked]> 
>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>> Internet-Draft directories:http://www.ietf.org/shadow.html 
>> <http://www.ietf.org/shadow.html> 
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>> 
>> _______________________________________________ Int-area mailing 
>> list [email-masked] <mailto:[email-masked]> 
>> <https://www.ietf.org/mailman/listinfo/int-area>
> 
> 
> _______________________________________________ Int-area mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/int-area