Le 19/12/2021 à 20:53, to...@strayalpha.com a écrit :
Hi, Fred (et al.),
On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L
<fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>>
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
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
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:*to...@strayalpha.com
<mailto:to...@strayalpha.com>[mailto:to...@strayalpha.com
<mailto:to...@strayalpha.com>] *Sent:*Saturday, December 18, 2021
8:13 PM *To:*Templin (US), Fred L <fred.l.temp...@boeing.com
<mailto:fred.l.temp...@boeing.com>> *Cc:*int-area@ietf.org
<mailto:int-area@ietf.org>; Wes Eddy <w...@mti-systems.com
<mailto:w...@mti-systems.com>> *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
<fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>>
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:*to...@strayalpha.com
<mailto:to...@strayalpha.com>[mailto:to...@strayalpha.com
<mailto:to...@strayalpha.com>] *Sent:*Saturday, December 18, 2021
4:57 PM *To:*Templin (US), Fred L <fred.l.temp...@boeing.com
<mailto:fred.l.temp...@boeing.com>> *Cc:*int-area@ietf.org
<mailto:int-area@ietf.org>; Wes Eddy <w...@mti-systems.com
<mailto:w...@mti-systems.com>> *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
<fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>>
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/
<https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/>
Fred *From:*to...@strayalpha.com
<mailto:to...@strayalpha.com>[mailto:to...@strayalpha.com
<mailto:to...@strayalpha.com>] *Sent:*Friday, December 17, 2021
6:01 PM *To:*Templin (US), Fred L <fred.l.temp...@boeing.com
<mailto:fred.l.temp...@boeing.com>> *Cc:*int-area@ietf.org
<mailto:int-area@ietf.org> *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
<fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>>
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:i-d-announce-boun...@ietf.org
<mailto:i-d-announce-boun...@ietf.org>] On Behalf
ofinternet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent:
Friday, December 17, 2021 5:00 PM To:i-d-annou...@ietf.org
<mailto:i-d-annou...@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.
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/
<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
<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 i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
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>
orftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
_______________________________________________ Int-area mailing
list Int-area@ietf.org <mailto:Int-area@ietf.org>
https://www.ietf.org/mailman/listinfo/int-area
<https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ 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
