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

I think what we need to see is an overall view of how this is going to expand MTU across the Internet or at least at first in intranets (with the Internet to follow), not specs for little pieces of it. That and some indication that there is buy-in for this among hardware vendors. This has been

[Int-area] Re: [EXTERNAL] Re: New Version Notification for draft-bonica-intarea-icmp-op-exp-00.txt

I wonder if a more useful way to do this would be a cross reference index maintained by IANA? > -Original Message- > From: Carlos Pignataro > Sent: Friday, June 21, 2024 10:07 AM > To: Bob Hinden > Cc: Ron Bonica ; int-area@ietf.org > Subject: [EXTERNAL] [Int-area] Re: New Version Notif

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

> Whether something is "legitimate" is a matter of opinion, protocol > conformance typically is not. In the real world, protocol conformance involves how people interpret the specs (which have historically been quite loose) and what developers of things like firewalls have to do to keep real wor

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

Legitimate reasons for a middle box to look at transport headers: Firewalls need to look at port numbers to perform their quite necessary job. Anything forwarding packets (including NICs) needs to make sure TCP packets for a given IP/port/IP/port go through the same path to avoid re-ordering. N

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

It may not break the formal definition of any protocol, but it breaks common usage patterns in a way that will prevent most sites from using it. > Again, this proposal doesn't break any protocol. If someone is already using > RSS with plain TCP and UDP packets then that will continue to work wi

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

Not including the port numbers in the hash is insufficient. You end up with all the traffic on one or two cores. What you are saying is this proposal will effectively break all unmodified NICs. > To include port numbers in RSS hash would require some changes. An > unmodified NIC would probably

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

It’s definitely a problem for the 10G x7-- NICs that Intel is currently selling (I’ve been working on porting the driver). It would require coordinated firmware and driver updates because the driver to firmware interface isn’t defined for this case. I don’t want to publicly say why, but I woul

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

But they aren’t independent. There are going to be dozens of places where it scans the packet in order to extract the port number from the ULP headers (TCP, UDP, etc). Those will all break. And that includes all of the processing offload and packet routing done in the NIC. And those are just

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

I would say that, in theory, that’s not a show stopper, but in practice it is a lot of work to implement – enough to suggest that you wouldn’t get enough implementations to make it useable. From: Int-area On Behalf Of to...@strayalpha.com Sent: Thursday, March 21, 2024 10:46 AM To: Toerless Eck

Re: [Int-area] [EXTERNAL] Re: draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop"

In many cases, the whole point of using ping and traceroute is to verify that the entire route between nodes works. The PROBE approach doesn’t provide all of the needed functionality. From: Warren Kumari Sent: Monday, January 22, 2024 3:23 PM To: Robinson, Herbie ; Bill Fenner Cc: Internet

Re: [Int-area] [EXTERNAL] Re: draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop"

I think the ICMP problem needs to be addressed. Perhaps with an IPv4 option to embed the identity of the router (IPv6 address or some other way to identify the owner). One of the main purposes of traceroute is to identify the router that is dropping packets. It will not be helpful if all the

Re: [Int-area] [EXTERNAL] Re: Jumbo frame side meeting at IETF118 - notes

At some point, it becomes ridiculous to keep band-aiding 40+ year old hardware designs with ever increasing software complexity. The hard thing to know is when you hit that tipping point. From: Templin (US), Fred L Sent: Tuesday, December 19, 2023 4:44 PM To: Robinson, Herbie ; Paul Vixie

Re: [Int-area] [EXTERNAL] Re: Jumbo frame side meeting at IETF118 - notes

If we are going much beyond 9K, the hardware has to change, because a 32 bit CRC doesn’t cut it for really large packets. If the hardware has to change, we can push MTU negotiation into the hardware. And completely bypass the momentum involved with getting every existing implementation on the

Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)

period. If you are incorporating FEC in this design, whoever is designing the FEC is going to know way more about this than I do. Other sources to pursue would be designers of disk or tape hardware blocking. From: Templin (US), Fred L Sent: Monday, November 13, 2023 6:08 PM To: Robinson, Herbie

Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)

harder to do in software. Something to think about. From: Templin (US), Fred L Sent: Monday, November 13, 2023 5:19 PM To: Robinson, Herbie ; Tom Herbert ; Templin (US), Fred L Cc: int-area@ietf.org Subject: RE: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels

Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)

The NICs I have worked on have a mode that allows packets with CRC failures to be delivered with a status bit indicating the CRC error. If I remember correctly, CRC logic amounts to just a handful for gates; so, arranging to disable it would not be worth the effort at the standardization level.

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

, September 29, 2023 11:12 AM To: Robinson, Herbie Cc: Tom Herbert ; int-area ; tsvwg Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments

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

I have a couple of observations There is a desire to make host to network signals processable in fast router paths without variable length packet processing. Yet at the same time, there is a requirement for encryption. Processing variable length packets is going to be a lot easier in the fast

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

I would agree it must not be there when DF is 1. When DF is zero, there is always the possibility that a forwarding router will fragment the packet. From a practical standpoint, one wants the originator of the packet to provide the option whenever sending to a different subnet. I would also s

Re: [Int-area] [EXTERNAL] Re: [IPv6] New Draft - ICMPv6 Loopback

What about taking advantage of the ICMP error mechanism? >From Phone From: Int-area on behalf of Florian Obser Sent: Wednesday, June 7, 2023 8:15:21 AM To: Luigi IANNONE Cc: i...@ietf.org ; int-area@ietf.org Subject: [EXTERNAL] Re: [Int-area] [IPv6] New Draft

Re: [Int-area] [EXTERNAL] draft-augustyn-intarea-ipref: security

AH headers would be an issue. In theory, they have been deprecated, but they are still widely supported. From: Int-area On Behalf Of waldemar Sent: Tuesday, March 28, 2023 9:45 AM To: int-area@ietf.org Subject: [EXTERNAL] [Int-area] draft-augustyn-intarea-ipref: security [EXTERNAL SENDER: This

Re: [Int-area] [EXTERNAL] Re: Rebooting Addressing Discussion - quantum resistant IPv6

IPSec is owned by another working group (IP Security Maintenance and Extensions (ipsecme) (ietf.org)). I’m not sure who owns Mobile IPv6 or CGA. From a higher level, what is needed here is a list of all the areas (RFCs, IANA assignments) whic

Re: [Int-area] Call for Adoption - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters draft

Yes. From: Int-area On Behalf Of Juan Carlos Zuniga (juzuniga) Sent: Wednesday, August 31, 2022 1:42 PM To: int-area@ietf.org; Wassim Haddad Subject: [EXTERNAL] [Int-area] Call for Adoption - IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters draft [EXTERNA

Re: [Int-area] [EXTERNAL] Re: Call for WG adoption of draft-templin-intarea-parcels-10

Fred Templin Wrote: > Tom: >>The algorithm isn't the problem, it's supporting new protocols and multiple >>checksums in a packet in hardware. >But Tom, how hard can this be? Instead of running the Internet checksum 1 time >over N octets of data simply run it M times over N/M octet chunks of the da

Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-eastlake-rfc7042bis-07.txt

I concur. From: Int-area On Behalf Of Carsten Bormann Sent: Wednesday, June 22, 2022 12:44 PM To: Donald Eastlake Cc: Internet Area ; draft-eastlake-rfc7042...@ietf.org Subject: [EXTERNAL] Re: [Int-area] New Version Notification for draft-eastlake-rfc7042bis-07.txt [EXTERNAL SENDER: This email

Re: [Int-area] [EXTERNAL] Re: MCP Hint Option

. What if the IPv6 MCPHINT was conveyed in a routing header with a new routing type and zero for segments left? I cringe a little bit, but it is a sort of routing. From: Erik Kline Sent: Saturday, May 28, 2022 12:41 AM To: Robinson, Herbie Cc: int-area@ietf.org Subject: [EXTERNAL] Re: [Int

[Int-area] MCP Hint Option

I would like to propose a small (8 page) RFC for the working group to take up. This is small option that can drastically improve multi-core IPSec performance in some situations. draft-robinson-intarea-mcphint-00 - Multiple Core Performance Hint Option (ietf.org)

Re: [Int-area] IP Parcels improves performance for end systems

I think this is a really good idea; although, it could be a bridge too far. It certainly won’t get implemented quickly. I still remember implementing path MTU discovery thinking about the big performance win I was going to get in IPv6 from 9K packets (vs 1500 byte packets) only to discover tha

Re: [Int-area] [EXTERNAL] Re: IP Parcels improves performance for end systems

> The nice thing about TSO/GSO/GRO is that they don't require any > changes to the protocol as just implementation techniques, also > they're one sided opitmizations meaning for instance that TSO can be > used at the sender without requiring GRO to be used at the receiver. > My understanding is tha