Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Yeah - I often wonder what IP would look like if it were more like Ethernet, i.e., when you add shims (Q-tags or encapsulation), you don’t actually reduce the payload size. It’s somewhat counterintuitive, but it certainly puts the work of dealing with longer packets at the endpoints that made t

Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet?

All waists, like all layers except those that touch the physical (e.g., MAC protocols) are relative. It’s a lot like the ‘end’ in E2E. It was thought to imply “that which can be kicked”, but it’s really “that which *I* can kick”. Once you accept this relativity, everything else just works - inc

Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet?

, it’s not solved. Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L > wrote: > > Joe, yes MTU was hard – very hard – but it is now solved. > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [

Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet?

ld obviate the need for frag/reassembly except at the uppermost app layer. Joe > > Fred > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Friday, December 03, 2021 7:33 AM >

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hi, Fred, These both address a way to support *fragmentation*. I clearly said what we need is a way to stop fragmenting (it was a wish list after all). Ethernet never fragments because it just keeps adding headers. Nothing in the docs below does that. THAT, in a nutshell, is what’s missing, as

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

, and all the problems that implies, I do not see how the IETF could > get out of dealing with link MTU variation. (Doing this on a tunnel basis is > one of the features I think Fred Templin is arguing for.) > > Yours, > Joel > > On 12/3/2021 10:21 PM, to...@strayalpha.com

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

> > On Dec 3, 2021, at 8:38 PM, Dino Farinacci wrote: > > >> My point, which appears not to be tracking, is I *wish* protocol layers >> didn’t have such strict MTUs, but rather expanded as headers were added *at >> all layers*, in the same *spirit* as Ethernet does. > > The Internet can do t

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

> > On Dec 7, 2021, at 7:36 AM, Dino Farinacci wrote: > >> That may help, but only in limited cases. >> >> E.g., let’s say you run IPsec tunnel mode for IPv6, which eats the majority >> of that space. Now that traffic runs over a second IPsec tunnel that you >> don’t know about. >> >> That’s

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

On Dec 7, 2021, at 12:15 PM, Brian E Carpenter wrote: > > On 08-Dec-21 05:30, to...@strayalpha.com wrote: > ... >>> But you make another point which is pretty fundamental and foundational. >>> Should data links be MTU-less, so to speak? And can they really do that.

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

I think we’re generally in agreement. My view is that fragmentation is currently a necessary evil. Evil that should be avoided where possible, but necessary that MUST be supported. Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 7, 2021, at 3:46 PM, Dino Farinacci wrote:

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

On Dec 7, 2021, at 3:47 PM, Dino Farinacci wrote: > > And note if you get rid of data link MTUs, your head-of-line-blocking issue > gets worse. Also note 1280 is not 53, and hence we have an international > large scale network running, unlike ATM. It’s more like I want to get rid of the reduct

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

. Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 7, 2021, at 4:56 PM, Dino Farinacci wrote: > > Since you can't FEC IP fragments, the apps have to do it. And since the apps > do it, they fragment on IP MTU boundaries. > > Dino > >>

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hi, Fred, > On Dec 7, 2021, at 5:38 PM, Templin (US), Fred L > wrote: > ... > This conversation is missing some fundamental points – really the most > important > points – which are the minimum sizes guaranteed to work everywhere. For IPv6, > the minimum MTU/MRU are 1280/1500. They work only b

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hi, Fred, > On Dec 8, 2021, at 10:43 AM, Templin (US), Fred L > wrote: > > Joe, let’s forget about 1280 for the time being but please describe a path > where an > IP packet no larger than 576 (DF=0) would be dropped due to a size > restriction and/or > fragmentation. What would RFC3819 have t

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hi, Fred, > On Dec 8, 2021, at 11:52 AM, Templin (US), Fred L > wrote: > > Joe, RFC3819, Section 2 in particular gives BCPs for setting link MTUs. NATs and tunnels don’t have control over the link MTUs over which they operate; the user doesn’t have control over how those are composed or inter

Re: [Int-area] [EXTERNAL] Side meeting follow-up: What exact features do we want from the Internet?

wrote: > > Joe, I am having a hard time seeing your response as anything other than a > non-answer to my question. > > Fred > >> -Original Message- >> From: to...@strayalpha.com [mailto:to...@strayalpha.com] >> Sent: Wednesday, December 08, 2021 12:11 P

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hi, Alex, > On Dec 17, 2021, at 12:53 AM, Alexandre Petrescu > wrote: > > Le 15/12/2021 à 19:56, Templin (US), Fred L a écrit : >> Alex, >>> A new feature in an ALv2 would be that instead of just a >>> frag-reassembly from sender to receiver, one would consider >>> group-degroup of packets too,

Re: [Int-area] Where/How is the features innovation happening?

Globally unique != static. They can be randomized and varied over time, e.g., as are Ethernet MAC addresses, exactly for the reasons you note. Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 17, 2021, at 11:46 AM, Brian E Carpenter > wrote: > > On 18-Dec-21 07:48, Geoff

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.

Re: [Int-area] IP parcels

ture 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> &g

Re: [Int-area] IP parcels

el 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

Re: [Int-area] IP parcels

ller 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 th

Re: [Int-area] [EXTERNAL] IP parcels

> > 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. >

Re: [Int-area] IP parcels

FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. the current ones to extend option space after the SYN (draft-ietf-tcpm-tcp-edo). Although I appreciate their zeal for optimization, implementers of GRO/GSO still need to play by the rules of TCP and UDP. It’s not clear t

Re: [Int-area] IP parcels

Hi, Tom, > On Jan 27, 2022, at 2:46 PM, Tom Herbert wrote: > > On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com > wrote: >> >> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. >> the current ones to extend option space after the SY

Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

> On Feb 25, 2022, at 12:02 AM, Toerless Eckert wrote: > >> Abstract >> >>Routing and addressing are inexorably tied, and the scalability of > > ^ > Nit: >prepend "In the Internet architecture" > > E.g.: If we would have a better architecture, including LISP, we would > arguably h

Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

Hi, Dino, Yes, ML can help deal with unpredictable link issues *if* there are some underlying statistics at work. However, it’s generally more useful to track such links as faulty and replace them than to use AI to “adapt” to their failure patterns. I looked at ML techniques for predicting con

Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

FWIW... > On Feb 25, 2022, at 3:10 PM, Dino Farinacci wrote: > >> Is LISP really part of the Internet Architecture ? I thought (unfortunately) >> not. E.g.: i don't think i can become an Internet transit ISP without >> participating >> in the "native" BGP routing. "Hey, i don't want these gigan

Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

FWIW: > On Feb 28, 2022, at 9:46 AM, Toerless Eckert wrote: > > I just said you can unfortunately not claim to be an Internet ISP and > not carry the whole bloody BGP routing table by just using LISP > (unfortunately). > > Aka: Joe touch pointed out that something like LISP (on-demand routing

Re: [Int-area] tunneling and recursion (was: Re: New Version Notification for draft-li-int-aggregation-00.txt)

— Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 28, 2022, at 9:54 AM, Toerless Eckert wrote: > > On Fri, Feb 25, 2022 at 08:19:42PM -0800, to...@strayalpha.com wrote: >> I disagree; a tunnel (done correctly) is isomorphic to a link. There’s no >&g

Re: [Int-area] tunneling and recursion (was: Re: New Version Notification for draft-li-int-aggregation-00.txt)

> On Feb 28, 2022, at 8:00 PM, Dino Farinacci wrote: > >> There is a base case to the recursion, i.e., where logical information meets >> fermions and bosons (literally). But that tells you only that base layer; it >> tells you nothing about the meaning of the headers you see inside, e.g., in

Re: [Int-area] New draft: The IETF Will Continue Maintaining IPv4 (draft-schoen-intarea-ietf-maintaining-ipv4)

> On Mar 15, 2022, at 1:04 PM, Brian E Carpenter > wrote: > > FWIW I do not consider the minor wastage of IPv4 addresses that > the same authors are concerned about to be serious enough to need > fixing. +1 on that, especially. I.e., regardless of IPv6, this is working in too far in the margi

Re: [Int-area] The IETF Will Continue Maintaining IPv4 (draft-schoen-intarea-ietf-maintaining-ipv4) Re: 202203190720.AYC

Whether this document is needed or not, it would be useful to have ti focus on IPv4 issues. Many of the examples of protocol updates in Sec 6 are not related to IPv4, e.g., TCP and DNS. The only arguable inclusion would be multicast DNS, but there is a big difference between extensions that wor

Re: [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation

Some comments: The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with in-band discovery (PLPMTUD), but asserts (in the first paragraph) that the group term “path MTU discovery” isn’t deployed due to security concerns. I have seen no such concerns about PLPMTUD - if you are aware

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-11.txt

Hi, all, This is largely an in-place update, with a few minor changes (typos, updating statistics, etc.). Most of the changes shown are due to differences in word wrap. It serves as the basis moving forward. Mark and I are hoping to run a pass on this and get it ready in the next few months.

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-12.txt

Hi, all, This version includes all pending updates and feedback, largely from Gorry Fairhurst (thanks). Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 27, 2022, at 5:02 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Inter

Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number

Hi, Bob, > On Apr 5, 2023, at 4:22 AM, Robert Moskowitz wrote: > > I am in the process of reving draft > > draft-ietf-intarea-schc-ip-protocol-number > > and adding support for schc as an ethertype and tcp/udp port number as I said > I would do back in Nov. Sigh. I understand maybe Ethertyp

Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number

s for why. > > SCHC as a port number was added by others, primarily Pacal Thubert for UDP > firewall traversal. He will be providing the text for that use case. > > Back to writing on this bumpy train ride... > > Bob > > On 4/6/23 00:13, to...@strayalpha.com <mail

Re: [Int-area] I-D Action: draft-templin-intarea-ipid-ext-00.txt

Hi, Fred (et al.), It might be useful to be clear whether this option MUST NOT be used on atomic datagrams (i.e., where IPv4 DF==1 or when not source fragmented) and that it cannot be used for purposes other than reassembly (as the regular ID is per RFC 6484). Joe — Dr. Joe Touch, temporal

Re: [Int-area] I-D Action: draft-templin-intarea-ipid-ext-00.txt

Hi, Fred (et al.), It might be useful to be clear whether this option MUST NOT be used on atomic datagrams (i.e., where IPv4 DF==1 or when not source fragmented) and that it cannot be used for purposes other than reassembly (as the regular ID is per RFC 6484). Joe — Dr. Joe Touch, temporal

Re: [Int-area] New Version Notification for draft-herbert-net2hostsig-00.txt

I’ve already commented on other lists, but to state here, IMO, UDP options exist in a space that the UDP header makes available. I do not think it is ever appropriate to use transport headers or signals to communicate with network devices. Joe — Dr. Joe Touch, temporal epistemologist www.stray

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

On Mar 20, 2024, at 9:35 PM, Toerless Eckert wrote: > > On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote: >>> In other words, Destination Option Headers do not have fundamentally >>> distinct >>> processing requirements on the destination host examining it than any other >>> possible

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

> On Mar 21, 2024, at 8:01 AM, Tom Herbert wrote: > >> I haven’t seen it mentioned yet (apologies if so), but there is a big >> difference between extension headers and encapsulated protocols. >> >> Extension headers - no matter how many - can each refer back to the base >> header. Same for th

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

On Mar 21, 2024, at 6:36 PM, Tom Herbert wrote: > > On Thu, Mar 21, 2024 at 5:38 PM to...@strayalpha.com > wrote: >> >> On Mar 21, 2024, at 8:01 AM, Tom Herbert wrote: >> >> I haven’t seen it mentioned yet (apologies if so), but there is a big >> d

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

> On Mar 21, 2024, at 7:18 PM, Tom Herbert wrote: > > On Thu, Mar 21, 2024 at 6:52 PM to...@strayalpha.com > wrote: >> >> On Mar 21, 2024, at 6:36 PM, Tom Herbert wrote: >>> >>> On Thu, Mar 21, 2024 at 5:38 PM to...@strayalpha.com >>>

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

> >> You’ve just described a transport protocol that the intermediate nodes know. > > > Joe, > > A transport protocol doesn't meet the requirements. They don't work with any > transport protocol other than themselves, They do when you define them that way, i.e., “here’s a transport protocol

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

On Mar 21, 2024, at 8:48 PM, Tom Herbert wrote: > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com > <mailto:to...@strayalpha.com> <mailto:to...@strayalpha.com>> wrote: >> >>> >>>> You’ve just described a transport protocol

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

On Mar 21, 2024, at 10:58 PM, Tom Herbert wrote: > >> Again, I’m not saying it’s not useful. I’m saying it’s just another >> transport - one with particular properties, but still just a transport. > > Extension headers are not transport protocols per the standard, > RFC8200 clearly distinguishe

[Int-area] Re: ICMP Considerations

Hi, Ron, Unreliable - how is that not assumed? They’re sent as IP packets. Rate limited - there isn’t actually such a requirement. Most ICMPs are defined as SHOULD be sent, which allows for endpoints that would otherwise be overloaded to rate limit, but that could also backfire - ICMP messages

[Int-area] Re: [tsvwg] UDP options [was IP Parcels and Advanced Jumbos (AJs)]

F list > <mailto:ts...@ietf.org>> >> Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced >> Jumbos (AJs)] >> >> >> >> EXT email: be mindful of links/attachments. >> >> >> >> That works

[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L > wrote: > >> Indeed. But if sendmsg() and recvmsg() can and do generate RFC2675 packets, >> it means that any discussion of obsoleting RFC2675 should be >> off the table. > > No one that I know of has suggested obsoleting RFC2675 - my docum

[Int-area] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

> On Sep 27, 2024, at 8:02 PM, Brian E Carpenter > wrote: > >> We COULD have a new option with a longer length, but that’s not in our >> baseline draft. > > Wouldn't that be tricky, because the options follow the whole payload as I > understand it? So a JumboUDPgram has to be received in ful

[Int-area] Re: [EXTERNAL] [tsvwg] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

;>; IPv6 List <mailto:i...@ietf.org>>; tsvwg IETF list <mailto:ts...@ietf.org>> > Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced > Jumbos (AJs)] > > EXT email: be mindful of links/attachments. > > > That works for me.. &

[Int-area] Re: [tsvwg] UDP options [was IP Parcels and Advanced Jumbos (AJs)]

> On Sep 30, 2024, at 8:08 AM, Templin (US), Fred L > wrote: > > > Please review the UDP options doc. There is no “end *following* UDP > > options”; the options consume the entire surplus space. > > Yes, so IP parcels and AJs will update the base UDP options spec. For IP > parcels and AJs,

[Int-area] Re: [tsvwg] [EXTERNAL] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

> On Sep 30, 2024, at 8:41 AM, Templin (US), Fred L > wrote: > > >> For parcels/AJs >= 64K, the overall length appears in the Parcel Payload > >> Length of the HBH option and > >> the UDP length is set to 0. The IP parcels draft specifies that UDP Length > >> = 0 means that there will be > >>

[Int-area] Re: Presentation on analog MTU that fell off of the Int-Area agenda

Hi, Matt, > On Nov 6, 2024, at 7:09 AM, Matt Mathis wrote: > > The deck is pretty much self explanatory and only 11 slides. Networks are > Analog but MTU is not >

[Int-area] Re: [tsvwg] UDP options [was IP Parcels and Advanced Jumbos (AJs)]

Chown >> <mailto:tim.ch...@jisc.ac.uk>>; Internet Area >> <mailto:Int-area@ietf.org>>; IPv6 List >> <mailto:i...@ietf.org>>; tsvwg IETF list >> <mailto:ts...@ietf.org>> >>> Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and

[Int-area] Re: [tsvwg] UDP options [was IP Parcels and Advanced Jumbos (AJs)]

Hi, Lloyd, > On Nov 19, 2024, at 3:58 PM, lloyd.w...@yahoo.co.uk > wrote: > > ... > When UDP-Lite (RFC3828) was proposed, it was eventually shunted to its own IP > protocol number, rather than risk messing up existing UDP implementations and > semantics for even a very minor change. I gather

[Int-area] Re: Observation of: draft-karstens-intarea-multicast-application-port

Hi, all, Agreed - it is useful. Speaking from the ports review team, I would ask whether the current requested port is already deployed; I recommend replacing the current text with “TBD” until an assignment has actually been made, and avoiding indicating a specific number until coordinated wit

[Int-area] Re: Call for Agenda Items @IETF122

Requesting a slot to present the current status of draft-ietf-intarea-tunnels and propose it is ready for WGLC. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 14, 2025, at 12:08 PM, Wassim Haddad > wrote: > > Dear all, > > In preparation for the Intarea WG meeting

[Int-area] Re: New Version Notification for draft-white-intarea-reordering-00.txt

he goal of this document could be described as gathering the current > wisdom around the implications, positive and negative, of L2 resequencing on > IP. > > Greg > >> On Mar 12, 2025, at 5:32 PM, to...@strayalpha.com wrote: >> >>  Hi Greg, >> >>

[Int-area] Re: New Version Notification for draft-white-intarea-reordering-00.txt

d be out of scope for the draft to >> explore non-IP use cases. >> >> Perhaps the goal of this document could be described as gathering the >> current wisdom around the implications, positive and negative, of L2 >> resequencing on IP. >> >> Greg >> >

[Int-area] Re: New Version Notification for draft-white-intarea-reordering-00.txt

Hi Greg, FWIW, it might be useful to note that some L2s maintain ordering for their own purposes, e.g., ATM did so to simplify fragmentation and reassembly in its own protocol layers. Others may rely on in-order delivery for control messages (do Ethernet BPDUs require this?). I.e., it’s not al

[Int-area] Re: Regarding draft-ietf-intarea-tunnels-15

Hi, Tiger, > On Jul 22, 2025, at 6:32 AM, Tiger Xu wrote: > > Hi all, > > I > find this architectural draft quite valuable. Furthermore, since UDP has > been widely used as an effective tunneling > > technology, such as MPLS-over-UDP > (https://datatracker.ietf.org/doc/rfc7510/), it would b