Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Fri, Mar 22, 2024 at 12:17 PM Brian E Carpenter wrote: > > On 23-Mar-24 03:40, Robinson, Herbie wrote: > > Legitimate reasons for a middle box to look at transport headers: > > > > Firewalls need to look at port numbers to perform their quite necessary job. > > Steve Bellovin pointed out in 1999 that such firewalls should be in the > destination host**. That works very well, and in particular it scales > perfectly in proportion to the number of hosts in the Internet, so doesn't > need hardware assist. > > Firewall vendors don't agree and never have done. Brian, That functionality is certainly in Android and iOS I would imagine. > > Unfortunately for Tom's argument, firewalls at enterprise network boundaries > are widespread and hosts without adequate self-protection are common. It's a > sad state of affairs. It will be interesting to see whether QUIC manages to > effect change. There might be some argument for enterprise firewalls for the purpose of protecting network resources. One example is the filtering packets that contain Hop-by-Hop Options _might_ be reasonable in some circumstances since they are directed towards routers and not just end hosts, so filtering them conceptually protects the enterprise's network resources from attack. Although, I'd prefer that they remove HBH at the edge instead of dropping like in draft-herbert-eh-inflight-removal (that's also in the ipv4eh draft). Also, it probably never makes sense to accept packets with Routing Headers from the Internet into a limited domain. Tom > > ** https://www.cs.columbia.edu/~smb/papers/distfw.pdf > > Brian > > > > > 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. > > > > Note that firewalls usually have a hardware assisted fast path and a > > software based slow path. Any new protocol features will kick packets into > > the slow path until the hardware gets updated (and that’s if the hardware > > gets updated). > > > > -- > > > > Hello, > > > > Interestingly, there is a similar discussion going on in Spring around the > > C-SID draft, about whether people think it is legitimate for intermediate > > nodes to be able to parse / process / check information that are supposed > > to be used by end nodes or not. This goes with checksum, port numbers, > > segment IDs, etc. > > > > I think that acknowledging the possibility for middleboxes to look at and > > modify fields that are supposed to be looked at and checked by end nodes is > > an issue, and breaks fundamental end to end assumptions that are > > foundational in the Internet design. Thus, I think we should allow shim > > headers (you can name them IPv4 extension headers if you want) to be > > deployed between IPv4 header and Transport layer protocol, provided they > > get a proper protocol number. Of course, this will break the operation of > > middleboxes that try to look at information in transport headers, but they > > should not look at those information in the first place, or at least do it > > in a robust way. > > > > Best regards, > > > > Antoine > > > > *From:* Int-area > <mailto:int-area-boun...@ietf.org>> *On Behalf Of *Tom Herbert > > *Sent:* vendredi 22 mars 2024 04:49 > > *To:* Joe Touch mailto:to...@strayalpha.com>> > > *Cc:* Toerless Eckert mailto:t...@cs.fau.de>>; int-area > > mailto:int-area@ietf.org>> > > *Subject:* Re: [Int-area] New Version Notification for > > draft-herbert-ipv4-eh-03.txt > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com > > <mailto:to...@strayalpha.com> >
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Fri, Mar 22, 2024 at 9:12 AM Robinson, Herbie wrote: > > > 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 world threats from making the > Internet totally useless. What seems to be happening is things that are > necessary get done while adhering to the developers best efforts to adhere to > the specs and real world utilization. Eventually, what really happens is > things which are necessary enough to be widely used (like firewalls) dictate > what the specs didn't say when the firewalls were designed. > > > For applications and hosts firewalls are not all necessary to do their job > > and > > have created way more problems for developers than they solve. > > Umm, are you really trying to claim that firewalls are not necessary? Herbie, Yes, I'm saying that. I know this is true because whenever I connect to WIFI at the local coffee shop or the airport I get no indication that the network is even running a firewall, much less any guarantee that their running a firewall that's well maintained, that the devices are up to date with latest vendor patches, or that they have a reasonable and sufficient security policy. I rely solely on my application and host OS which I can control for security, malware detection, virus scanning, etc. So some anonymous firewall that thinks they can protect me better is more likely to cause problems or reduce my security (like if they don't forward my IPsec or QUIC packets because the firewall thinks that hiding data from them is insecure). If there was some real standard for firewalls that had broad conformance, ubiquitous deployment, and consistent policies then I might think differently-- but until that happens I believe firewalls are more part of the problem than the solution. Tom > If it wasn't for firewalls, the Internet would be pretty much useless. I > wish that were not so, but... > > > In fact, in the 6man meeting the other day someone pointed out that the > > effect of NAT has been to move the problems and complexity out of the > > network into the host and application-- as a host developer I can say that > > this > > statement is spot on. > > NAT is a red herring -- it's not the only reason firewalls need to look at > ports to do their job. Then again, NAT It is a really good argument for not > enhancing IPv4 (so that NAT will go away). > > BTW, I am a host developer and protocol stack maintainer. I see this as a > huge amount of work to implement something no-one will be able to use for 2-3 > decades. Especially when it's all available via IPv6, now. > > > Right, and this is exactly what drives use to limit packets on the Internet > > to > > perpetually use the least common denominator of support in the network. > > The result is an ossified Internet that we can no longer > > evolve-- IMO that's not a good thing! > > And how does defining something no-one will be able to use for two or three > decades solve that problem -- better than IPv6 which already has a 2 decade > head start? ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Fri, Mar 22, 2024 at 7:40 AM Robinson, Herbie wrote: > > Legitimate reasons for a middle box to look at transport headers: > Herbie, Whether something is "legitimate" is a matter of opinion, protocol conformance typically is not. > > > Firewalls need to look at port numbers to perform their quite necessary job. For applications and hosts firewalls are not all necessary to do their job and have created way more problems for developers than they solve. In fact, in the 6man meeting the other day someone pointed out that the effect of NAT has been to move the problems and complexity out of the network into the host and application-- as a host developer I can say that this statement is spot on. > > 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. That would be great if TCP was the only transport protocol. But it's not. What about UDP, DCCP, SCTP, GRE, IPsec, IPIP, IP fragments, and others? There is a simple answer for this, use the IPv6 flow label instead of port number to get the proper effect regardless of the encapsulated IP protocol and routers don't need to parse deep into the packet to find the port numbers. IPv4 doesn't have a flow label, but this draft proposes using IPID for that with non-fragmented packets. > > Note that firewalls usually have a hardware assisted fast path and a software > based slow path. Any new protocol features will kick packets into the slow > path until the hardware gets updated (and that’s if the hardware gets > updated). Right, and this is exactly what drives use to limit packets on the Internet to perpetually use the least common denominator of support in the network. The result is an ossified Internet that we can no longer evolve-- IMO that's not a good thing! Tom > > > > > > > > Hello, > > > > Interestingly, there is a similar discussion going on in Spring around the > C-SID draft, about whether people think it is legitimate for intermediate > nodes to be able to parse / process / check information that are supposed to > be used by end nodes or not. This goes with checksum, port numbers, segment > IDs, etc. > > > > I think that acknowledging the possibility for middleboxes to look at and > modify fields that are supposed to be looked at and checked by end nodes is > an issue, and breaks fundamental end to end assumptions that are foundational > in the Internet design. Thus, I think we should allow shim headers (you can > name them IPv4 extension headers if you want) to be deployed between IPv4 > header and Transport layer protocol, provided they get a proper protocol > number. Of course, this will break the operation of middleboxes that try to > look at information in transport headers, but they should not look at those > information in the first place, or at least do it in a robust way. > > > > Best regards, > > > > Antoine > > > > From: Int-area On Behalf Of Tom Herbert > Sent: vendredi 22 mars 2024 04:49 > To: Joe Touch > Cc: Toerless Eckert ; int-area > Subject: Re: [Int-area] New Version Notification for > draft-herbert-ipv4-eh-03.txt > > > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com > wrote: > > > > > > 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 > header A, after which you can use any transport protocol, as indicated in > field X”. > > > > and intermediate nodes cannot robustly parse transport headers > > > > They can’t parse these either. But, if upgraded to do so for headers “A”, as > per above. > > > > This has to be L3 protocol. > > > > It’s not. It’s L4, or at least that’s what it is* to IP. > > > > Joe, > > > > Please give one concrete example of a transport protocol explicitly designed > to be processed and modified by intermediate nodes. If you say TCP as in > modifying port numbers for NAT, I'll point out it that the TCP was never > designed for this, it breaks TCP Auth option, and QUIC closed this > architectural aberration by encrypting the transport layer so that > intermediate nodes can't muck with it :-) > > > > IMO, network nodes have no business participating in transport layer, doing > so has led to a lot of protocol ossification. > > > > Tom > > > > > > > > IPv6 can call them extensions becau
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Fri, Mar 22, 2024 at 7:45 AM to...@strayalpha.com wrote: > > 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 distinguishes extension headers from upper layer > protocols which can be transport layer protocols. > > > IPv6 EH = extension headers to IPv6 > > IMO, IPv6 EH per this draft = just another transport protocol Joe, I disagree. EH is not a transport protocol. There's already precedent for supporting EH in IPv4 in AH and ESP. No one would ever call these transport layer protocols. The same thing is true for other EH if they are enabled for IPv4 just like ESP and AH were enabled. Tom > > RFC8200 does not apply to this proposal. > > There is NOTHING that can be done for IPv4 to permit legacy endpoints to > silently ignore an EH when so desired by the sender. That’s what makes IPv6 > EHs different than this (IMO, again) transport protocol. > > It’s misleading to call this proposal an EH or having to do with IPv4. > It doesn’t help the programmer or user by doing so. > It doesn’t imbue the proposed solution with any properties a transport > protocol couldn’t have, by design. > > I don’t think this is being proposed in the correct IETF area; it belongs in > TSVWG. > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 9:01 PM to...@strayalpha.com wrote: > > On Mar 21, 2024, at 8:48 PM, Tom Herbert wrote: > > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com > wrote: >> >> >> >> >>> 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 >> header A, after which you can use any transport protocol, as indicated in >> field X”. >> >> and intermediate nodes cannot robustly parse transport headers >> >> >> They can’t parse these either. But, if upgraded to do so for headers “A”, as >> per above. >> >> This has to be L3 protocol. >> >> >> It’s not. It’s L4, or at least that’s what it is* to IP. > > > Joe, > > Please give one concrete example of a transport protocol explicitly designed > to be processed and modified by intermediate nodes. > > > The one in this draft. > > ... > IMO, network nodes have no business participating in transport layer, doing > so has led to a lot of protocol ossification. > > > Nodes participate in the protocols that they know about. Joe, Sure. Before TLS spun up, intermediate nodes were commonly parsing HTML into TCP to rewrite content to put in their own ads and doing other nefarious things. Basically, anything in plaintext is often considered fair game. But, the fact that they can do something non-conformant hardly justifies it or makes it robust. This is exactly why there is a trend to encrypt as much of the packet as possible like in QUIC. > > There are BITW stacks that process IPsec. As noted many times, NATs do this > for TCP. There have been BITW devices that coalesce or split TCP packets. > > No, this isn’t possible for protocols designed to NOT allow it > (authentication, encryption, etc.). > > But the protocol defined in this draft IS designed to allow - and encourage - > just that. > > It does’t make it “not a transport”. It makes it a “transport that > intermediate nodes know they can modify”. > > 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 distinguishes extension headers from upper layer protocols which can be transport layer protocols. Tom > > Joe > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com wrote: > > > > 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 > header A, after which you can use any transport protocol, as indicated in > field X”. > > and intermediate nodes cannot robustly parse transport headers > > > They can’t parse these either. But, if upgraded to do so for headers “A”, > as per above. > > This has to be L3 protocol. > > > It’s not. It’s L4, or at least that’s what it is* to IP. > Joe, Please give one concrete example of a transport protocol explicitly designed to be processed and modified by intermediate nodes. If you say TCP as in modifying port numbers for NAT, I'll point out it that the TCP was never designed for this, it breaks TCP Auth option, and QUIC closed this architectural aberration by encrypting the transport layer so that intermediate nodes can't muck with it :-) IMO, network nodes have no business participating in transport layer, doing so has led to a lot of protocol ossification. Tom > IPv6 can call them extensions because all IPv6 nodes already know what to > do with them, even for codepoints they’ve never seen. IPv4 implementations > have no knowledge of this new transport protocol - only those who have been > upgraded. > > No different in principle - or implementation - than DCCP or SCTP. > No easier to deploy. > No more unique utility, IMO. > > Joe > > *All protocol layers are relative, so you COULD do the following: > > IPa IPb UDPc UDPd > > To IPa, its view of itself is layer 3, IPb is layer 4, not an extension to > layer 3. > > To IPb, its view of itself is layer 3, IPa is layer 2 and UDPc is layer 4. > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024, 7:28 PM to...@strayalpha.com wrote: > > > 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 > >>> 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 > difference between extension headers and encapsulated protocols. > >>>> > >>>> Extension headers - no matter how many - can each refer back to the > base header. Same for the first encapsulated protocol. > >>>> > >>>> E.g.: > >>>> > >>>> IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > >>>> But: > >>>> IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of > the EH’s can also refer back to IPv6a > >>>> > >>>> I see NO way to do this with any mechanism for IPv4 except options > (whose space is limited). There’s no way to redefine protocol processing to > ensure that information can be “Carried” forward across EHs. > >>>> > >>>> This seems like a show-stopper; has it been addressed? > >>>> > >>>> > >>>> Joe, > >>>> > >>>> It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In > >>>> practice, host stacks have already accounted for this so I don't see > >>>> this as a problem. > >>>> > >>>> Tom > >>>> > >>>> > >>>> There’s a big difference and it relates to discussions we've had > about UDP options. > >>>> > >>>> With IPsec, the assumption is “if I add it, it MUST be checked”, so > an endpoint that doesn’t know to check would drop the packet as expected. > >>> > >>> Joe, > >>> > >>> As you know from the discussions on UDP Options, I believe that if > >>> someone sends security information in a packet then the information > >>> MUST be verified. It's always better to drop something you don't > >>> understand, rather than accept it and put the user at risk for > >>> security or data corruption. > >> > >> I understand; for ESP, the data is also modified and not useful. > >> For EH, we can debate whether it’s important to *force* checks t at the > receiver. > > > > Joe, > > > > There's nothing to debate. > > We can debate what IPsec requires and whether that was an appropriate > choice. > What it currently requires is not under debate, of course. > > >> > >> But either way, there are also options that you might want a legacy > receiver to allow, and this approach won’t do that. So it’s necessarily > limited. > >> > >>>> But that means these extensions can only be useful where they MUST be > supported; you can’t send them to (or through) legacy devices (or NATs) and > have them work correctly. > >>> > >>> We can't send AH, ESP, DCCP, SCTP, GRE through NAT either. For that > >>> matter, has any ever tested if IPv6 EH can make it through NAT. In any > >>> case, from IPv6 data we already know that extension headers will > >>> probably ever only be useful in limited domains, so I don't believe > >>> NAT traversal is a showstopper. > >> > >> Whether EH *does* make it through any NAT is different than whether it > could. It could - there’s enough information. > >> > >> This approach for IPv4 cannot - because it doesn’t change the base > protocol. > > > > IPv4 works the same way as IPv6. > > Not for EHs. An existing IPv6 NAT can skip over EHs because they were > defined when IPv6 was defined; an existing IPv4 NAT cannot. > > >>>> In which case, rather than this mechanism, you could as easily do > basically ANYTHING else too - because it’s no longer a matter of backward > compatibility. > >>> > >>> But isn't that the *whole point* of an extensible protocol like IP?... > >> > >> My point is that you’re NOT extending IP. > > > > I guess it depends on what you mean by "extending". To me "extension" > > headers are a mechanism to "extend" a protocol. > > Yes, but you’re not extending IP. You’re running a protoco
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
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 > > 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 > >> difference between extension headers and encapsulated protocols. > >> > >> Extension headers - no matter how many - can each refer back to the base > >> header. Same for the first encapsulated protocol. > >> > >> E.g.: > >> > >> IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > >> But: > >> IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of the > >> EH’s can also refer back to IPv6a > >> > >> I see NO way to do this with any mechanism for IPv4 except options (whose > >> space is limited). There’s no way to redefine protocol processing to > >> ensure that information can be “Carried” forward across EHs. > >> > >> This seems like a show-stopper; has it been addressed? > >> > >> > >> Joe, > >> > >> It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In > >> practice, host stacks have already accounted for this so I don't see > >> this as a problem. > >> > >> Tom > >> > >> > >> There’s a big difference and it relates to discussions we've had about UDP > >> options. > >> > >> With IPsec, the assumption is “if I add it, it MUST be checked”, so an > >> endpoint that doesn’t know to check would drop the packet as expected. > > > > Joe, > > > > As you know from the discussions on UDP Options, I believe that if > > someone sends security information in a packet then the information > > MUST be verified. It's always better to drop something you don't > > understand, rather than accept it and put the user at risk for > > security or data corruption. > > I understand; for ESP, the data is also modified and not useful. > For EH, we can debate whether it’s important to *force* checks t at the > receiver. Joe, There's nothing to debate. The requirements are well established. If a host receives an AH or ESP Header it MUST either validate ICV or decrypt, or drop the packet. If a host receives a Frag Header it MUST reassemble the packet before processing after the Frag Header. If a host receives a Routing Header it must process it and can only continue past the Header when segments left equals zero. If a host receives an unrecognized Hop-by-Hop or Destination option and the high order two bits of the option type are nonzero then the host MUST discard the packet. > > But either way, there are also options that you might want a legacy receiver > to allow, and this approach won’t do that. So it’s necessarily limited. > > >> But that means these extensions can only be useful where they MUST be > >> supported; you can’t send them to (or through) legacy devices (or NATs) > >> and have them work correctly. > > > > We can't send AH, ESP, DCCP, SCTP, GRE through NAT either. For that > > matter, has any ever tested if IPv6 EH can make it through NAT. In any > > case, from IPv6 data we already know that extension headers will > > probably ever only be useful in limited domains, so I don't believe > > NAT traversal is a showstopper. > > Whether EH *does* make it through any NAT is different than whether it could. > It could - there’s enough information. > > This approach for IPv4 cannot - because it doesn’t change the base protocol. IPv4 works the same way as IPv6. If some device supports IPv6 EH through NAT then they could support IPv4. In fact, there's a lot of implementation to be shared. > > >> > >> In which case, rather than this mechanism, you could as easily do > >> basically ANYTHING else too - because it’s no longer a matter of backward > >> compatibility. > > > > But isn't that the *whole point* of an extensible protocol like IP?... > > My point is that you’re NOT extending IP. I guess it depends on what you mean by "extending". To me "extension" headers are a mechanism to "extend" a protocol. > > This is just a protocol layer like any other. It doesn’t really have any > relation to IP. IPv4 endpoints don’t know how to skip them if they don’t > support or understand them. Correct. That's the benefit of extension headers compared to IP options. > > > to allow innovation and extensions to be able to solve problems th
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
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 > difference between extension headers and encapsulated protocols. > > Extension headers - no matter how many - can each refer back to the base > header. Same for the first encapsulated protocol. > > E.g.: > > IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > But: > IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of the EH’s > can also refer back to IPv6a > > I see NO way to do this with any mechanism for IPv4 except options (whose > space is limited). There’s no way to redefine protocol processing to ensure > that information can be “Carried” forward across EHs. > > This seems like a show-stopper; has it been addressed? > > > Joe, > > It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In > practice, host stacks have already accounted for this so I don't see > this as a problem. > > Tom > > > There’s a big difference and it relates to discussions we've had about UDP > options. > > With IPsec, the assumption is “if I add it, it MUST be checked”, so an > endpoint that doesn’t know to check would drop the packet as expected. Joe, As you know from the discussions on UDP Options, I believe that if someone sends security information in a packet then the information MUST be verified. It's always better to drop something you don't understand, rather than accept it and put the user at risk for security or data corruption. > > But that means these extensions can only be useful where they MUST be > supported; you can’t send them to (or through) legacy devices (or NATs) and > have them work correctly. We can't send AH, ESP, DCCP, SCTP, GRE through NAT either. For that matter, has any ever tested if IPv6 EH can make it through NAT. In any case, from IPv6 data we already know that extension headers will probably ever only be useful in limited domains, so I don't believe NAT traversal is a showstopper. > > In which case, rather than this mechanism, you could as easily do basically > ANYTHING else too - because it’s no longer a matter of backward compatibility. But isn't that the *whole point* of an extensible protocol like IP?... to allow innovation and extensions to be able to solve problems that would never have been foreseen when the protocol was first developed. And not everything we do can be backwards compatible, if that were a requirement IETF never could have created IPv6. > > The idea of a chain of headers appears to have shown itself not very tenable > for IPv6; I can’t see why we would want to emulate it in a protocol that (as > others noted) I thought we were no longer evolving. I believe there are a lot of people in IETF that would disagree with that sentiment. Tom > > Joe > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 2:36 PM Brian E Carpenter wrote: > > On 22-Mar-24 09:04, Tom Herbert wrote: > > On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L > > wrote: > >> > >> Brian, > >> > >>> Why should the IETF spend effort on upgrading IPv4 capabilities at this > >>> point? > >> > >> For air/land/sea/space mobile Internetworking, we expect to engage > >> steady-state IP > >> fragmentation over some paths, but IPv4 will still be in the picture for a > >> long time to > >> come and IPv4 fragmentation has known limitations (e.g., RFC4963). IPv4 > >> fragmentation > >> using the IPv6 Fragment Header (adapted for IPv4) would address many of > >> the issues. > >> > >> This is just to name one example. Another example is adapting IPv6 HBH > >> options to > >> carry IP parcels and Advanced Jumbos in IPv4 packets for operation over > >> networks > >> where IPv4 will still be used for the long term. > >> > >> IPv4 is going to be around for a long time in many networks, so making it > >> work > >> more like IPv6 seems like a useful improvement. > > > > Yes, we still have IPv4 users that need the capabilities. If everyone > > were on IPv6 we wouldn't need this. > > So this proposal hinders IPv6 adoption. I think it would lead to an > "interesting" IETF Last Call discussion. Hi Brian, Well I knew going in this would be provocative :-) Actually, I believe this accelerates IPv6 adoption. We're essentially unifying portions IPv4 and IPv6 so that makes a complete transition that much easier. If people adopt the hacky alternatives I mentioned then it's likely they'll just propagate those into IPv6 (that's another effect we've seen, some people "adopt" IPv6 but still treat it like IPv4). Besides, we've been working on IPv6 for what, thirty years, I really doubt *this* is the thing that will get the blame for how long adoption is taking :-). > > > > > To be a little more direct, one purpose of the draft is to nullify a > > persistent argument against using extension headers: "They don't work > > with IPv4". > > I was told in Seattle in March 1994 that the Internet was opaque to > new IPv4 options - that's the main reason I stopped work on > https://datatracker.ietf.org/doc/draft-carpenter-aeiou/, in fact. > I understand that you've bypassed that problem in the ipv4-eh > design, but surely the deployment problem here will be worse than > it is for IPv6 extension headers - IPv4 middleboxes and firewalls > are much more widely deployed than they were in 1994. > > > We've seen the same story play out in a number of proposals. It goes > > like this: "We want to annotate packets with ancillary network layer > > information like extension headers are designed for, but we still have > > a large number of users still on IPv4 and so using extension headers > > is a showstopper." Unfortunately, all the alternatives for getting > > similar functionality in IPv4 have proven to be essentially hacks > > (like having intermediate devices parse UDP payloads, or somehow use > > VLAN as metadata and turn Ethernet into an E2E protocol). And of > > course, IP options are "not an option"... > > Right. But there you've implicitly accepted the limited domain > model, which many in the IETF consider heresy. Sure, but there's also many in IETF that realize the practicality of the limited domain model in real world deployment. Tom > > Brian > > > > > Tom > > > >> > >> Fred > >> > >>> -Original Message- > >>> From: Int-area On Behalf Of Brian E Carpenter > >>> Sent: Thursday, March 21, 2024 11:59 AM > >>> To: int-area@ietf.org > >>> Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notification for > >>> draft-herbert-ipv4-eh-03.txt > >>> > >>> EXT email: be mindful of links/attachments. > >>> > >>> > >>> > >>> On 22-Mar-24 03:53, Robinson, Herbie wrote: > >>>> 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. > >&g
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L wrote: > > Brian, > > > Why should the IETF spend effort on upgrading IPv4 capabilities at this > > point? > > For air/land/sea/space mobile Internetworking, we expect to engage > steady-state IP > fragmentation over some paths, but IPv4 will still be in the picture for a > long time to > come and IPv4 fragmentation has known limitations (e.g., RFC4963). IPv4 > fragmentation > using the IPv6 Fragment Header (adapted for IPv4) would address many of the > issues. > > This is just to name one example. Another example is adapting IPv6 HBH > options to > carry IP parcels and Advanced Jumbos in IPv4 packets for operation over > networks > where IPv4 will still be used for the long term. > > IPv4 is going to be around for a long time in many networks, so making it work > more like IPv6 seems like a useful improvement. Yes, we still have IPv4 users that need the capabilities. If everyone were on IPv6 we wouldn't need this. To be a little more direct, one purpose of the draft is to nullify a persistent argument against using extension headers: "They don't work with IPv4". We've seen the same story play out in a number of proposals. It goes like this: "We want to annotate packets with ancillary network layer information like extension headers are designed for, but we still have a large number of users still on IPv4 and so using extension headers is a showstopper." Unfortunately, all the alternatives for getting similar functionality in IPv4 have proven to be essentially hacks (like having intermediate devices parse UDP payloads, or somehow use VLAN as metadata and turn Ethernet into an E2E protocol). And of course, IP options are "not an option"... Tom > > Fred > > > -Original Message- > > From: Int-area On Behalf Of Brian E Carpenter > > Sent: Thursday, March 21, 2024 11:59 AM > > To: int-area@ietf.org > > Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notification for > > draft-herbert-ipv4-eh-03.txt > > > > EXT email: be mindful of links/attachments. > > > > > > > > On 22-Mar-24 03:53, Robinson, Herbie wrote: > > > 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. > > > > I'll say it because nobody else has (recently). > > > > Why should the IETF spend effort on upgrading IPv4 capabilities at this > > point? > > > > Brian > > > > > > > > *From:* Int-area *On Behalf Of > > > *to...@strayalpha.com > > > *Sent:* Thursday, March 21, 2024 10:46 AM > > > *To:* Toerless Eckert > > > *Cc:* int-area > > > *Subject:* [EXTERNAL] Re: [Int-area] New Version Notification for > > > draft-herbert-ipv4-eh-03.txt > > > > > > *[**EXTERNAL SENDER**: This email originated from outside of Stratus > > > Technologies. Do not click links or open attachments unless you > > recognize the sender and know the content is safe.]*** > > > > > > --- > > -- > > -- > > -- > > ------ > > --- > > > > > > On Mar 20, 2024, at 9:35 PM, Toerless Eckert > > <mailto:t...@cs.fau.de>> 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 protocol header (e.g.: UDP, TCP), or at
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 11:16 AM Robinson, Herbie wrote: > > 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. Herbie, Maybe. But I think it's ironic that the same argument is used to keep on IPv4 instead of moving to IPv6 since IPv6 also "breaks" things! (of course, if everyone had switched to IPv6 then we wouldn't need this proposal :-) ) Like any other new protocol deployed the benefits needed to be measured against the cost. That can be considered on a use case basis. We can also consider individual EH. For instance, some users might want to use Fragment Header instead of IPv4 fragmentation for the larger IPID space-- this really doesn't break any offloads more than plain IP fragmentation does. Tom > > > 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 with > > ports > > as input (although I wouldn't be surprised if this doesn't work for some > > NICs if > > IP options are present). Yes, the port information is not available to an > > unmodified NIC. But I don't see that as being any different than an > > unmodified > > NIC that can't extract port information from protocols other than UDP and > > TCP like the aforementioned DCCP, SCTP, ESP, AH, etc. Also, port extraction > > can't work with fragmented UDP and TCP packets. > > > > So I don't see that IPv4 EH breaks anything anymore than using a protocol > > other than UDP or TCP. And if a site doesn't want to use IPv4 EH or risk > > using > > any other protocol than TCP or UDP or even fragmentation then that's their > > business. > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 9:54 AM Robinson, Herbie wrote: > > 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. Herbie, 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 with ports as input (although I wouldn't be surprised if this doesn't work for some NICs if IP options are present). Yes, the port information is not available to an unmodified NIC. But I don't see that as being any different than an unmodified NIC that can't extract port information from protocols other than UDP and TCP like the aforementioned DCCP, SCTP, ESP, AH, etc. Also, port extraction can't work with fragmented UDP and TCP packets. So I don't see that IPv4 EH breaks anything anymore than using a protocol other than UDP or TCP. And if a site doesn't want to use IPv4 EH or risk using any other protocol than TCP or UDP or even fragmentation then that's their business. Tom > > > To include port numbers in RSS hash would require some changes. An > > unmodified NIC would probably just hash over IP addresses and maybe > > protocol numbers. > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 9:11 AM Robinson, Herbie wrote: > > 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 would hazard a guess there is no way that would ever happen. > > > > And from a practical standpoint, one needs NICs to scan packets and route > different streams to different receive queues -- it’s still not possible for > a single core to handle a 10G data stream. Especially if you are also > breaking checksum offload, etc. Herbie, This only would break protocol specific checksum offload where the device needs to parse the packet to set the checksum. It would not break protocol agnostic checksum offload. We've been pleading with NIC vendors for more than ten years to support protocol agnostic checksum offload precisely because protocol specific checksum offload is so fragile and so narrow in use case. Unfortunately, some vendors have refused to listen, and I don't believe we shouldn't move the Internet forward just to accommodate them. TSO will similarly work if the device supports a generic mechanism. To include port numbers in RSS hash would require some changes. An unmodified NIC would probably just hash over IP addresses and maybe protocol numbers. To round it out the list of basic NIC offload, LRO would also require some changes. But LRO never really was deployed much anyway because it really wants to be programmed. Fully programmable NICs may change this story. Tom > > > > As for NICs, I don't think that is much of a problem any more. We now > expect them to be programmable to easily support new protocols. So > skipping over some new EH to find port numbers isn't much of an issue > (actually, it's the same code they would use with IPv6 so it's just a > matter of enabling the protocol numbers for new EH). > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 8:18 AM Robinson, Herbie wrote: > > 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 a few things I could think of in 2 minutes… Hi Herbie, But none of those things break any *protocol standard*. When intermediate nodes do deep parsing into packets to find port numbers they are not following a standard protocol, they are doing that on their own accord. And note that port number extraction is an opportunistic mechanism, it only works when a device has support for specific protocols in a packet. For instance, most devices can extract ports from TCP and UDP, but can they extract them from DCCP or SCTP? What about GRE or IPIP and other tunneling protocols? Even if they do all of those, they can't extract port numbers from an ESP packet. So port number extraction already doesn't work in a bunch of cases, and IPv4 EH doesn't create a new problem in that regard. As for NICs, I don't think that is much of a problem any more. We now expect them to be programmable to easily support new protocols. So skipping over some new EH to find port numbers isn't much of an issue (actually, it's the same code they would use with IPv6 so it's just a matter of enabling the protocol numbers for new EH). >From the POV of intermediate nodes, extension headers are just another protocol they might see. If they want to parse them that's fine, if they want to ignore them like they would need to do with ESP or some other protocol they don't implement that's fine. What they shouldn't do is just drop packets because they don't approve of the protocols they encapsulate. If we accept that they can do that, then we're accepting the ossification of the Internet as status quo. Tom > > > > In the host it's not a horrible amount of work since extension headers > are mostly independent of the IP protocol and we'll be able to share a > lot of implementation. For instance, supporting Fragment Header in > IPv4 is fairly straightforward, most of the logic dealing with > fragments in reassembly is agnostic to the IP protocol (except for > using the addresses to match fragments to the reassembly queue). I > imagine it's probably less than fifty Lines of Code to support IPv4 > Fragment Header in Linux. > > Support in routers is already there inasmuch that they can forward > packets of any unresognized IP Protocol. Router support for IPv4 HBH > or the IPv4 flow label is completely optional. > > Tom > > > > > > > > > > > From: Int-area On Behalf Of to...@strayalpha.com > > Sent: Thursday, March 21, 2024 10:46 AM > > To: Toerless Eckert > > Cc: int-area > > Subject: [EXTERNAL] Re: [Int-area] New Version Notification for > > draft-herbert-ipv4-eh-03.txt > > > > > > > > [EXTERNAL SENDER: This email originated from outside of Stratus > > Technologies. Do not click links or open attachments unless you recognize > > the sender and know the content is safe.] > > > > > > > > > > > > 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 protocol header (e.g.: UDP, TCP), or at least we could not find > > such a description > > for any such guiding rules or treatment differences in RFC8200. > > > > > > Yes, that's mostly how all the IP protocols are implemented. > > Processing of an encapsulated protocol isn't completely independent, > > for instance the pseudo header for the TCP and UDP checksum is > > different for IPv4 and IPv6. > > > > > > Right. But it seems unrelated to whether or not a header is an extension > > header, > > TCP and UDP not being extension headers for example. > > > > > > > > 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 the first encapsulated protocol. > > > > > > > > E.g.: > > > > > > > > IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > > > > But: > > > > IPv6a EHb EHc TCP… T
Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 7:54 AM Robinson, Herbie wrote: > > 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. Herbie, In the host it's not a horrible amount of work since extension headers are mostly independent of the IP protocol and we'll be able to share a lot of implementation. For instance, supporting Fragment Header in IPv4 is fairly straightforward, most of the logic dealing with fragments in reassembly is agnostic to the IP protocol (except for using the addresses to match fragments to the reassembly queue). I imagine it's probably less than fifty Lines of Code to support IPv4 Fragment Header in Linux. Support in routers is already there inasmuch that they can forward packets of any unresognized IP Protocol. Router support for IPv4 HBH or the IPv4 flow label is completely optional. Tom > > > > From: Int-area On Behalf Of to...@strayalpha.com > Sent: Thursday, March 21, 2024 10:46 AM > To: Toerless Eckert > Cc: int-area > Subject: [EXTERNAL] Re: [Int-area] New Version Notification for > draft-herbert-ipv4-eh-03.txt > > > > [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. > Do not click links or open attachments unless you recognize the sender and > know the content is safe.] > > > > > > 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 protocol header (e.g.: UDP, TCP), or at least we could not find such > a description > for any such guiding rules or treatment differences in RFC8200. > > > Yes, that's mostly how all the IP protocols are implemented. > Processing of an encapsulated protocol isn't completely independent, > for instance the pseudo header for the TCP and UDP checksum is > different for IPv4 and IPv6. > > > Right. But it seems unrelated to whether or not a header is an extension > header, > TCP and UDP not being extension headers for example. > > > > 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 the first encapsulated protocol. > > > > E.g.: > > > > IP1 IP2 IP3 TCP…. TCP uses a > pseudo header based on IP3 > > But: > > IPv6a EHb EHc TCP… TCP uses a pseudo header based on > IPv6a; each of the EH’s can also refer back to IPv6a > > > > I see NO way to do this with any mechanism for IPv4 except options (whose > space is limited). There’s no way to redefine protocol processing to ensure > that information can be “Carried” forward across EHs. > > > > This seems like a show-stopper; has it been addressed? > > > > Joe > > ___ > 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
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 7:46 AM to...@strayalpha.com wrote: > > 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 protocol header (e.g.: UDP, TCP), or at least we could not find such > a description > for any such guiding rules or treatment differences in RFC8200. > > > Yes, that's mostly how all the IP protocols are implemented. > Processing of an encapsulated protocol isn't completely independent, > for instance the pseudo header for the TCP and UDP checksum is > different for IPv4 and IPv6. > > > Right. But it seems unrelated to whether or not a header is an extension > header, > TCP and UDP not being extension headers for example. > > > 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 the first encapsulated protocol. > > E.g.: > > IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > But: > IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of the EH’s > can also refer back to IPv6a > > I see NO way to do this with any mechanism for IPv4 except options (whose > space is limited). There’s no way to redefine protocol processing to ensure > that information can be “Carried” forward across EHs. > > This seems like a show-stopper; has it been addressed? Joe, It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In practice, host stacks have already accounted for this so I don't see this as a problem. Tom > > Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
On Thu, Mar 21, 2024 at 12:36 AM Bob Hinden wrote: > > Tom, > > > On Mar 21, 2024, at 2:20 PM, Tom Herbert > > wrote: > > > > On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert wrote: > >> > >> Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet > >> Protocol > >> Number being an "IPv6 Extension Header" or not, the answer was that in his > >> interpretation it is simply whether the header itself has it's own "Next > >> Header" > >> field using the IANA Assigned Internet Protocol Numbers registry - or not. > > > > Thanks for asking. So by this definition IPv4 already supports > > extension headers :-). > > As I remember it, Authentication Header (AH) and Encapsulating Security > Payload (ESP) were first developed for IPv6 and then adapted to IPv4. Bob, Yes, that is one of the motivations to support other extension headers in IPv4. Basically, we're just backporting useful forward looking features from IPv6 to IPv4. Tom > > Bob > > > > > >> > >> In other words, Destination Option Headers do not have fundamentally > >> distinct > >> processing requirements on the destination host examining it than any other > >> possible protocol header (e.g.: UDP, TCP), or at least we could not find > >> such a description > >> for any such guiding rules or treatment differences in RFC8200. > > > > Yes, that's mostly how all the IP protocols are implemented. > > Processing of an encapsulated protocol isn't completely independent, > > for instance the pseudo header for the TCP and UDP checksum is > > different for IPv4 and IPv6. > > > >> > >> To me this means that it's simply a matter of consistency of simply > >> calling ESP and AH > >> "Extension Headers" when we do introduce this concept into IPv4. > > > > Agreed. > > > >> > >> Of course, this interpretation is not fully consistent with the way the > >> "IPv6 Extension Header" flag is used in the registry: IPv6 itself does not > >> have this > >> flag, so likely IPv4 should neither, even though both have this "next > >> header" field, > >> but maybe this can be explained by both ofg these being recursion instead > >> of extension > >> when happening in a header chain. > > > > Yes, although it's not clear to me how relevant the flag in the > > registry is. In any case, for IPv4 extension headers it makes sense to > > be consistent with IPv6. > > > > Tom > > > >> > >> Cheers > >>Toerless > >> > >> On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote: > >>> On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote: > >>>> We can treat them as EH for purposes of extension header ordering in > >>>> section 2.2. Also, IPv4 AH needs to be updated to take EH into account > >>>> as mentioned below. Other than that I don't believe there are any > >>>> substantive differences. > >>> > >>> Yes, i am trying to use ESP/AH as examples to understand the benefits > >>> of destination headers as opposed to just non-extension headers .. > >>> > >>>> No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel > >>>> changes to Linux will be straightforward. > >>> > >>> My question was not about differences in API between IPv4/IPv6, but > >>> between when > >>> ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they > >>> become > >>> extension because the kernel changes have been applied. > >>> > >>> Ul;timately, i am trying to understand whether, and if so WHY we should > >>> reclassify ESP and AH in IPv4 to be extension headers. Right now the only > >>> argument i would know would be "consistency with IPv6", but that by itself > >>> does not seem to be sufficient to change something for what's being > >>> deployed > >>> worldwide in so many places. So there should be a technical benefit. > >>> > >>> And if the answer is "it does not make any difference whatsoever", then i > >>> also > >>> wonder why we would want to do it... > >>> > >>>>> Any other functional differences ? Aka: i couldn't find a simple: > >>>>> > >>>>> "If i want to define a new protocol header
Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Wed, 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 protocol header (e.g.: UDP, TCP), or at least we could not find > > > such a description > > > for any such guiding rules or treatment differences in RFC8200. > > > > Yes, that's mostly how all the IP protocols are implemented. > > Processing of an encapsulated protocol isn't completely independent, > > for instance the pseudo header for the TCP and UDP checksum is > > different for IPv4 and IPv6. > > Right. But it seems unrelated to whether or not a header is an extension > header, > TCP and UDP not being extension headers for example. > > > > Of course, this interpretation is not fully consistent with the way the > > > "IPv6 Extension Header" flag is used in the registry: IPv6 itself does > > > not have this > > > flag, so likely IPv4 should neither, even though both have this "next > > > header" field, > > > but maybe this can be explained by both ofg these being recursion instead > > > of extension > > > when happening in a header chain. > > > > Yes, although it's not clear to me how relevant the flag in the > > registry is. In any case, for IPv4 extension headers it makes sense to > > be consistent with IPv6. > > Well, i started this thread because i was worried thart there was some > semantic > attached to the flag and changing it for existing protocols would cause > potential > behavioral changes we would not want. But seemingly there is no actual > semantic > implied, so we should be able to easily declare AH/ESP in IPv4 to be > extension headers when > your draft goes through. the flag in the registry probably would only impact > the > ability of packet parsers to parse at least the extension header chain. Toerless, Packet parsers would implement the protocol spec. If spec says there's a Next Header then we'll parse it as a Next Header. I don't believe the registry flags have any relevance to implementations. Tom > > Cheers > Toerless > > > Tom > > > > > > > > Cheers > > > Toerless > > > > > > On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote: > > > > On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote: > > > > > We can treat them as EH for purposes of extension header ordering in > > > > > section 2.2. Also, IPv4 AH needs to be updated to take EH into account > > > > > as mentioned below. Other than that I don't believe there are any > > > > > substantive differences. > > > > > > > > Yes, i am trying to use ESP/AH as examples to understand the benefits > > > > of destination headers as opposed to just non-extension headers .. > > > > > > > > > No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel > > > > > changes to Linux will be straightforward. > > > > > > > > My question was not about differences in API between IPv4/IPv6, but > > > > between when > > > > ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they > > > > become > > > > extension because the kernel changes have been applied. > > > > > > > > Ul;timately, i am trying to understand whether, and if so WHY we should > > > > reclassify ESP and AH in IPv4 to be extension headers. Right now the > > > > only > > > > argument i would know would be "consistency with IPv6", but that by > > > > itself > > > > does not seem to be sufficient to change something for what's being > > > > deployed > > > > worldwide in so many places. So there should be a technical benefit. > > > > > > > > And if the answer is "it does not make any difference whatsoever", then > > > > i also > > > > wonder why we would want to do it... > > > > > > > > > > Any other functional differences ? Aka: i couldn't find a simple: > > > > > > > > > > > > "If i want to define a new protocol header, should i call it an > > > > > > extension header or an ipv6 extension header - for Dummies" ? > > > > > > > > > > I think there are IPv6 extensio
Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert wrote: > > Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet > Protocol > Number being an "IPv6 Extension Header" or not, the answer was that in his > interpretation it is simply whether the header itself has it's own "Next > Header" > field using the IANA Assigned Internet Protocol Numbers registry - or not. Thanks for asking. So by this definition IPv4 already supports extension headers :-). > > In other words, Destination Option Headers do not have fundamentally distinct > processing requirements on the destination host examining it than any other > possible protocol header (e.g.: UDP, TCP), or at least we could not find such > a description > for any such guiding rules or treatment differences in RFC8200. Yes, that's mostly how all the IP protocols are implemented. Processing of an encapsulated protocol isn't completely independent, for instance the pseudo header for the TCP and UDP checksum is different for IPv4 and IPv6. > > To me this means that it's simply a matter of consistency of simply calling > ESP and AH > "Extension Headers" when we do introduce this concept into IPv4. Agreed. > > Of course, this interpretation is not fully consistent with the way the > "IPv6 Extension Header" flag is used in the registry: IPv6 itself does not > have this > flag, so likely IPv4 should neither, even though both have this "next header" > field, > but maybe this can be explained by both ofg these being recursion instead of > extension > when happening in a header chain. Yes, although it's not clear to me how relevant the flag in the registry is. In any case, for IPv4 extension headers it makes sense to be consistent with IPv6. Tom > > Cheers > Toerless > > On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote: > > On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote: > > > We can treat them as EH for purposes of extension header ordering in > > > section 2.2. Also, IPv4 AH needs to be updated to take EH into account > > > as mentioned below. Other than that I don't believe there are any > > > substantive differences. > > > > Yes, i am trying to use ESP/AH as examples to understand the benefits > > of destination headers as opposed to just non-extension headers .. > > > > > No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel > > > changes to Linux will be straightforward. > > > > My question was not about differences in API between IPv4/IPv6, but between > > when > > ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they > > become > > extension because the kernel changes have been applied. > > > > Ul;timately, i am trying to understand whether, and if so WHY we should > > reclassify ESP and AH in IPv4 to be extension headers. Right now the only > > argument i would know would be "consistency with IPv6", but that by itself > > does not seem to be sufficient to change something for what's being deployed > > worldwide in so many places. So there should be a technical benefit. > > > > And if the answer is "it does not make any difference whatsoever", then i > > also > > wonder why we would want to do it... > > > > > > Any other functional differences ? Aka: i couldn't find a simple: > > > > > > > > "If i want to define a new protocol header, should i call it an > > > > extension header or an ipv6 extension header - for Dummies" ? > > > > > > I think there are IPv6 extension headers and IPv4 extension headers. > > > IPv4 extension headers are probably just a subset of IPv6 extension > > > headers. > > > > That's certainly safer, e.g.: asking for a separate column in the IANA > > registry. > > > > > > be renamed to "IP/IPv6 Extension Header". But when this was done > > > > to AH/ESP, and there actually is a functional difference expressed by > > > > this extension header (as opposed to non-extension header) status, then > > > > what be the imapct of this ? Aka: I upgrade my linux kernel to extension > > > > header and all my AH/ESP breaks ? Or i do get the benefit of above > > > > (userland access) ? > > > > > > > > Would there be any (backward compatibility) reason to have new > > > > codepoints in IPv4 for ESP/AH > > > > with this extension header status and leave the existing (non extension > > > > header) codepoints alone ? > > > > > > No, I don't
Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
On Tue, Mar 5, 2024 at 8:56 AM Toerless Eckert wrote: > > On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote: > > We can treat them as EH for purposes of extension header ordering in > > section 2.2. Also, IPv4 AH needs to be updated to take EH into account > > as mentioned below. Other than that I don't believe there are any > > substantive differences. > > Yes, i am trying to use ESP/AH as examples to understand the benefits > of destination headers as opposed to just non-extension headers .. > > > No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel > > changes to Linux will be straightforward. > > My question was not about differences in API between IPv4/IPv6, but between > when > ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they become > extension because the kernel changes have been applied. > > Ul;timately, i am trying to understand whether, and if so WHY we should > reclassify ESP and AH in IPv4 to be extension headers. Right now the only > argument i would know would be "consistency with IPv6", but that by itself > does not seem to be sufficient to change something for what's being deployed > worldwide in so many places. So there should be a technical benefit. > > And if the answer is "it does not make any difference whatsoever", then i also > wonder why we would want to do it... Hi Toerless, Because there is no solution in IPv4 to carry ancillary data in packets, and we are seeing proposals being made for new protocols that eschew use of extension headers even for IPv6 use cases on the basis that EH isn't supported in IPv4. If IPv6 had achieved ubiquitous deployment then I'd agree that IPv4 EH wouldn't be needed, but IPv6 is not there yet particularly in enterprise networks. Until IPv6 reaches ubiquity, which could still be years away, there is a gap in features in IPv4 that is turning into a liability for IETF. An example workaround for IPv4 not having EH is draft-ravi-ippm-csig. This is a proposal to put E2E network layer information into L2 (which I consider a hack because L2 layer information is not routable end-to-end without assuming some proprietary switch support). HBH Options is designed precisely to carry the signaling described in draft-ravi-ippm-csig, however the authors stated that they don't want to use HBH because it is not supported in IPv4 and no IPv4 support is a showstopper for them. Another example is SPUD which would allow ancillary information in UDP with a shim header in UDP. UDP is supported in IPv4 and IPv6 and this scheme works up to the point that we want network devices to read the information from UDP payloads which might lead to incorrectness. If a network device were to write into UDP payload to modify data inflight, then the protocol is fundamentally not robust. That being said, use of the Fragment header would be a technical improvement over IPv4 fragmentation (ID field is larger). > > > > Any other functional differences ? Aka: i couldn't find a simple: > > > > > > "If i want to define a new protocol header, should i call it an > > > extension header or an ipv6 extension header - for Dummies" ? > > > > I think there are IPv6 extension headers and IPv4 extension headers. > > IPv4 extension headers are probably just a subset of IPv6 extension > > headers. > > That's certainly safer, e.g.: asking for a separate column in the IANA > registry. > > > > be renamed to "IP/IPv6 Extension Header". But when this was done > > > to AH/ESP, and there actually is a functional difference expressed by > > > this extension header (as opposed to non-extension header) status, then > > > what be the imapct of this ? Aka: I upgrade my linux kernel to extension > > > header and all my AH/ESP breaks ? Or i do get the benefit of above > > > (userland access) ? > > > > > > Would there be any (backward compatibility) reason to have new codepoints > > > in IPv4 for ESP/AH > > > with this extension header status and leave the existing (non extension > > > header) codepoints alone ? > > > > No, I don't think we need that. ESP/AH should be backwards compatible. > > For instance, if someone sends AH with HBH in IPv4 then they know that > > their using EH and AH would take into account mutable HBH options. If > > the packet is sent to a host that supports IPv4 EH then they would > > know how to process the AH with HBH correctly. If the packet is sent > > to a legacy node that doesn't support EH, then the packet will bv > > dropped since the host doesn't recognize protocol 0 (HBH). > > Not clear. What you are writing implies that the encoding on the wire would > change for
Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
Hi Toerless, thanks for the questions! On Mon, Mar 4, 2024 at 4:11 PM Toerless Eckert wrote: > > Just some questions about AH/ESP here: > > What actually is (so far, without your draft) the technical benefits > and/or differences of ESP and AH in IPv6 being classified as IPv6 > extension headers, as opposed in IPv4, where they are currently > defined as "yet another (next level) Protocol ? We can treat them as EH for purposes of extension header ordering in section 2.2. Also, IPv4 AH needs to be updated to take EH into account as mentioned below. Other than that I don't believe there are any substantive differences. > > Any difference in APIs for example ? I guess i might be able to implement > ESP/AH in IPv6 in user-level because i can expose extension header > to user-level UDP sockets (not 100% sure), whereas in IPv4 i would need > a (raw) IP socket to get them up to userland ?? No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel changes to Linux will be straightforward. > > Any other functional differences ? Aka: i couldn't find a simple: > > "If i want to define a new protocol header, should i call it an > extension header or an ipv6 extension header - for Dummies" ? > I think there are IPv6 extension headers and IPv4 extension headers. IPv4 extension headers are probably just a subset of IPv6 extension headers. > (at least for those examined only on the receiver obviously. HBH i do get. > > I think you did not write it explicitly, but i would assume the IANA > Assigned Internet Protocols Numbers column "IPv6 Extension Header" would Yes, we should request an IPv4 EH attribute in this table (or maybe a footnote) > be renamed to "IP/IPv6 Extension Header". But when this was done > to AH/ESP, and there actually is a functional difference expressed by > this extension header (as opposed to non-extension header) status, then > what be the imapct of this ? Aka: I upgrade my linux kernel to extension > header and all my AH/ESP breaks ? Or i do get the benefit of above > (userland access) ? > > Would there be any (backward compatibility) reason to have new codepoints in > IPv4 for ESP/AH > with this extension header status and leave the existing (non extension > header) codepoints alone ? No, I don't think we need that. ESP/AH should be backwards compatible. For instance, if someone sends AH with HBH in IPv4 then they know that their using EH and AH would take into account mutable HBH options. If the packet is sent to a host that supports IPv4 EH then they would know how to process the AH with HBH correctly. If the packet is sent to a legacy node that doesn't support EH, then the packet will bv dropped since the host doesn't recognize protocol 0 (HBH). There is no behavioral change at either the receiver or the sender if someone sends an AH with no other EH. The draft will need to update RFC4302 to describe AH processing with IPv4 EH present. RFC4303 needs an update as well, but that's just to say that EH after the ESP is covered by the encryption, but I don't believe that materially changes the requirements. Tom > > Cheers > Toerless > > On Thu, Feb 22, 2024 at 05:40:31PM -0800, Tom Herbert wrote: > > Hi, > > > > I updated the IPv4 extension headers draft. I structured it to be > > self-contained without any normative references for IPv6 RFCs. It's a > > little bigger, but about 80% of the text is cut-and-paste from other > > RFCs and drafts. > > > > Comments are appreciated! > > > > Tom > > > > -- Forwarded message - > > From: > > Date: Thu, Feb 22, 2024 at 5:29 PM > > Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt > > To: Tom Herbert > > > > > > A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has been > > successfully submitted by Tom Herbert and posted to the > > IETF repository. > > > > Name: draft-herbert-ipv4-eh > > Revision: 03 > > Title:IPv4 Extension Headers and Flow Label > > Date: 2024-02-23 > > Group:Individual Submission > > Pages:47 > > URL: https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-03.txt > > Status: https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/ > > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh > > Diff: https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-03 > > > > Abstract: > > > >This specification defines extension headers for IPv4 and an IPv4 > >flow label. The goal is to provide a uniform and feasible method of > >extensibility that is common between IPv4 and IPv6. > > > > > > > > The IETF Secretariat > > > > -- > --- > t...@cs.fau.de ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt
Hi, I updated the IPv4 extension headers draft. I structured it to be self-contained without any normative references for IPv6 RFCs. It's a little bigger, but about 80% of the text is cut-and-paste from other RFCs and drafts. Comments are appreciated! Tom -- Forwarded message - From: Date: Thu, Feb 22, 2024 at 5:29 PM Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-ipv4-eh Revision: 03 Title:IPv4 Extension Headers and Flow Label Date: 2024-02-23 Group:Individual Submission Pages:47 URL: https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-03.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh Diff: https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-03 Abstract: This specification defines extension headers for IPv4 and an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop"
From: Int-area on behalf of Warren Kumari Sent: 22 January 2024 14:39 Hi there all, I discovered that I'd somehow misnamed a draft that Juliusz Chroboczek , Toke Høiland-Jørgensen, and myself had written — somehow I'd managed to name it draft-chroboczek-int-v4-via-v6, instead of draft-chroboczek-intarea-v4-via-v6. Anyway, it is targeted at intarea, and so I renamed and submitted it, so that it will now actually show up in the IntArea list of documents… The document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. This isn't yet another "let's rewrite part of the header and override some bits", nor some new protocol / tunneling thing. It simply notes that routers only need to determine the outgoing interface (and usually MAC address) for a packet, and so it's perfectly acceptable for the next-hop for e.g 192.0.2.0/24<http://192.0.2.0/24> to be e.g 2001:db8::2342. The router don't care… While this may be initially surprising to many people, it's actually nothing "special", nor really groundbreaking - it's just how IP routing works. However, because it is surprising, it is not getting widely used — and that means that many interfaces need IPv4 addresses where they otherwise would not. In fact, this functionality is already supported in (at least!): Arista EOS (since EOS-4.30.1) The Babel protocol Linux (since kernel version 5.2) Mikrotik RouterOS (since before 7.11beta2) and the BGP protocol (see RFC8950 - "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop"). The BGP instantiation of this I have long known but have never quite got my mind around what an LSR such as OSPF has to offer here. OSPFv3, which some regard as IPv6, has been able to carry IPv4 prefix for some time and it crops up in e.g. ospf-sr-yang (although I do not think is as a particularly SR issue). It is complex in part because LSR has become an ever more tangled mesh of (sub-(sub-)...TLV and I find it hard to know what TLV are valid where. Also, the advertised prefix are associated with flags and OSPFv2 and OSPFv3 flags are different reflecting the different ideas of links and the like in IPv4 and IPv6 so if you are advertising an IPv4 prefix over an IPv6 transport, whose flags are relevant? Probably both as the transport might affect e.g. the flooding while the ultimate user needs the other set of flags. Like I say, I have yet to get my mind around this. Tom Petch So, if this already works, why are we writing a document?! A few reasons, including: 1: This behavior / capability is surprising to many people - this means that people are "forced" to use IPv4 addresses where they otherwise would not. 2: There should be an easy way to reference this type of behaviour/deployment - the genesis of this document that Babel supports this (RFC9229 - "IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol"<https://datatracker.ietf.org/doc/rfc9229/>), but had to describe the behavior because there was nothing to point at. 2: A large number of implementations don't currently support it (or, at least, the tooling / CLI / UI doesn't allow configurations like the above). 3: There are some unsettled questions around the ICMP behavior — e.g: if a router has to send an ICMP packet too big, and it doesn't have an IPv4 address, what should it do? We'd really appreciate review and feedback — again, this isn't documenting a major "change", but more noting this the design of command lines, tooling, etc should allow it. W ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: Jumbo frame side meeting at IETF118 - notes
On Mon, Dec 18, 2023, 5:31 PM Robinson, Herbie wrote: > 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 planet to actually implement PTB. > > > Maybe a larger MTU with that sort of negotiation would make sense for Ultra Ethernet (not sure where they are on that) Tom *From:* Int-area *On Behalf Of *Paul Vixie > *Sent:* Monday, December 18, 2023 8:12 PM > *To:* Tom Herbert ; Christian > Huitema > *Cc:* Gorry (erg) ; int-area > *Subject:* [EXTERNAL] Re: [Int-area] Jumbo frame side meeting at IETF118 > - notes > > > > *[**EXTERNAL SENDER**: This email originated from outside of Stratus > Technologies. Do not click links or open attachments unless you recognize > the sender and know the content is safe.]* > > > -- > > We've got to teach the system how to negotiate and/or discover this. 9000 > was about right for fast Ethernet but it's small at gigabit Ethernet and > above. > > > > Petabit is probably coming within our lifetimes. > > > > 9000 would be a great starting point and 64k after that but like the ibmpc > 640k memory threshold the lesson is that hard limits don't last. > > > > I've been happy with 9000 in my various campus networks. But more would be > better. > > > > Max speed changing by no more than 6x isn't the issue. Complexity of work > arounds, power utilization, cost, and future proofing are the drivers here. > > > > p vixie > > > > On Dec 18, 2023 12:52, Tom Herbert > wrote: > > On Mon, Dec 18, 2023 at 11:24 AM Christian Huitema > wrote: > > > > On 12/18/2023 9:15 AM, Kyle Rose wrote: > > > Right, I should have said*at best* a 6x improvement. The point I'm > trying > > > to get to is: how much sense does it make to try to make the public > > > internet safe for jumbo frames? I honestly don't know, and since I > wasn't > > > at the meeting, I don't know much much this was even a focus. > > > > It is certainly less that 6x, especially for encrypted transports. There > > is a fixed cost per packet, but is corresponds more or less to the > > encryption of a per packet header and checksum, so maybe 32 to 64 bytes. > > After that, the cost of encryption is linear with the size of the > message. > > > > That does not mean that we should not do it. How many of us remember > > mocking ATM and its 48 byte packet size? The max speed of ATM circuits > > then was maybe 150Mbps, and 48 bytes meant 2.6us. Guess what, at 10Gbps, > > 1500 bytes means 1.2us... > > Christian, > > Right, and at 1Tbps 1500 bytes means 12ns! With respect to Internet > protocols there's no reason to artificially limit MTUs to 1500 bytes, > or for that matter even 9000 bytes or 64K bytes with IPv6. > > Tom > > > > > -- Christian Huitema > > ___ > 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
Re: [Int-area] Jumbo frame side meeting at IETF118 - notes
On Mon, Dec 18, 2023 at 11:24 AM Christian Huitema wrote: > > On 12/18/2023 9:15 AM, Kyle Rose wrote: > > Right, I should have said*at best* a 6x improvement. The point I'm trying > > to get to is: how much sense does it make to try to make the public > > internet safe for jumbo frames? I honestly don't know, and since I wasn't > > at the meeting, I don't know much much this was even a focus. > > It is certainly less that 6x, especially for encrypted transports. There > is a fixed cost per packet, but is corresponds more or less to the > encryption of a per packet header and checksum, so maybe 32 to 64 bytes. > After that, the cost of encryption is linear with the size of the message. > > That does not mean that we should not do it. How many of us remember > mocking ATM and its 48 byte packet size? The max speed of ATM circuits > then was maybe 150Mbps, and 48 bytes meant 2.6us. Guess what, at 10Gbps, > 1500 bytes means 1.2us... Christian, Right, and at 1Tbps 1500 bytes means 12ns! With respect to Internet protocols there's no reason to artificially limit MTUs to 1500 bytes, or for that matter even 9000 bytes or 64K bytes with IPv6. Tom > > -- Christian Huitema ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Jumbo frame side meeting at IETF118 - notes
On Mon, Dec 18, 2023 at 8:38 AM Kyle Rose wrote: > > Apologies for not being able to make the meeting. Had I been able to attend, > the question I was going to ask was: with respect to overhead, there's a > constant factor 6x improvement when moving from 1500->9000 octets. How > quickly do hardware performance improvements typically reach 6x > packet-per-second throughput at ~the same cost (capex, power, etc.)? Kyle, It's not really constant. A larger MTU is opportunistic optimization, it's only useful when the host is sending large amounts of data and path MTU allows a larger MSS (for instance, we'll still see forty byte pure ACKs being sent). There should be a reduction in packets but probably much less than 6x I would think. Tom > > Kyle > > On Mon, Dec 18, 2023 at 11:15 AM Tim Chown > wrote: >> >> Hi, >> >> Apologies for the delay in posting these notes. Gorry and I held a side >> meeting in Prague on the topic of (lack of) use of jumbo frames, and what >> topics might lie within the IETF’s remit to help promote greater use. >> >> After talking to an AD it was suggested we raise the topic on the int-area >> list to gauge interest, rather than set up a new list at this stage. >> >> So, all thoughts and comments welcome... >> >> -- >> >> Jumbo frame side meeting, IETF118, 2-3pm Thu 9 November >> >> Convened by Tim Chown (Jisc) and Gorry Fairhurst (Univ Aberdeen) >> >> The meeting had no set agenda. The aim was to gather those interested in >> more widespread use of jumbo frames to gather and discuss what actions might >> be taken in or by the IETF and its WGs towards that goal. >> >> Comments: >> • There is no standard for Ethernet for frame sizes above 1500 bytes >> • Would it be useful to work towards a “certified jumbo” >> interoperability test? >> • NICs at 1Gbit/s+ should all use phase-locked loop (PLL). >> • What tools should we use to identify issues or errors in transmission >> at various MTU sizes? >> • Tim noted that Jisc’s 100G perfSONAR node at London showed no errors >> on its 9000 MTU interface – stats can be seen under the interface details >> section at https://ps-london-bw.perf.ja.net/toolkit/ >> • We should consider the relevance of MTU in respective IETF areas – >> INT, TSV and OPS >> • Jen Linkova has talked about networks with multiple sizes of MTU >> • There are providers who offer 9000 MTU networks, end-to-end, such as >> Hurrican Electric >> • Tim reported that many PBs of data are moved by the CERN experiments >> and a proportion of that is using 9000 MTU. Single stream TCP performance >> can be 2-3x better, depending on RTT and other factors. >> • What issues might there be in specific technologies, e.g. ND, BGP, >> ECMP, multipath TCP, …? >> • There is a perception that IXPs find 9000 MTU problematic >> • There are previous IETF I-Ds on MTU use, e.g. in IXPs – we should look >> at old drafts or any RFCs >> • There may be relevant presentations from *NOG and RIR member meetings >> • Improvements to host stacks can make the performance gains of jumbo >> frames less important, e.g. various offloading technologiesCan we get >> current measurements and data, e.g., via MAPRG? >> • We should look at hyperscalers; there is support there for 9000 MTU >> • IPsec, and any encapsulation that benefits from avoiding >> fragmentation, can work better with jumbo frames >> • We could look a Globus transfer logs to detect MD5 errors for evidence >> of issues in the application data not picked up at lower layers >> • There are other non-Ethernet technologies used in DCs with large frames >> • Does QUIC break offload due to its encryption? In practice QUIC uses >> a Max Datagram Packet size less than 1500. Might larger MTUs be useful for >> QUIC >> • Post-quantum scenarios were mentioned. >> • What about MTU discovery? There is anecdotal evidence of issues; Tim >> has seen this at a UK university where ICMPv6 PTB was being dropped. >> • PLPMTUD is specified by QUIC; useful when there’s no path back to a >> sender for receipt of an ICMP PTB message. >> >> Agreed actions: >> • Tim will ask Eric Vyncke (INT area AD) for support to create a >> “jumbo-discuss” IETF mail list >> • We will seek to collectively document the status of jumbo frames, >> focusing on what works (success stories), opportunities, gaps (potential >> work items in the IETF and elsewhere) and other open issues.
Re: [Int-area] Jumbo frame side meeting at IETF118 - notes
On Mon, Dec 18, 2023 at 8:15 AM Tim Chown wrote: > > Hi, > > Apologies for the delay in posting these notes. Gorry and I held a side > meeting in Prague on the topic of (lack of) use of jumbo frames, and what > topics might lie within the IETF’s remit to help promote greater use. > > After talking to an AD it was suggested we raise the topic on the int-area > list to gauge interest, rather than set up a new list at this stage. > > So, all thoughts and comments welcome... Sorry I missed the meeting, I have a couple of comments below... > > -- > > Jumbo frame side meeting, IETF118, 2-3pm Thu 9 November > > Convened by Tim Chown (Jisc) and Gorry Fairhurst (Univ Aberdeen) > > The meeting had no set agenda. The aim was to gather those interested in more > widespread use of jumbo frames to gather and discuss what actions might be > taken in or by the IETF and its WGs towards that goal. > > Comments: > • There is no standard for Ethernet for frame sizes above 1500 bytes > • Would it be useful to work towards a “certified jumbo” interoperability > test? > • NICs at 1Gbit/s+ should all use phase-locked loop (PLL). > • What tools should we use to identify issues or errors in transmission > at various MTU sizes? > • Tim noted that Jisc’s 100G perfSONAR node at London showed no errors on > its 9000 MTU interface – stats can be seen under the interface details > section at https://ps-london-bw.perf.ja.net/toolkit/ > • We should consider the relevance of MTU in respective IETF areas – INT, > TSV and OPS > • Jen Linkova has talked about networks with multiple sizes of MTU > • There are providers who offer 9000 MTU networks, end-to-end, such as > Hurrican Electric > • Tim reported that many PBs of data are moved by the CERN experiments > and a proportion of that is using 9000 MTU. Single stream TCP performance > can be 2-3x better, depending on RTT and other factors. This is going to be very dependent on implementation as well, particularly how effective GSO and GRO are and whether they are offloaded to hardware in TSO and LRO. > • What issues might there be in specific technologies, e.g. ND, BGP, > ECMP, multipath TCP, …? > • There is a perception that IXPs find 9000 MTU problematic > • There are previous IETF I-Ds on MTU use, e.g. in IXPs – we should look > at old drafts or any RFCs > • There may be relevant presentations from *NOG and RIR member meetings > • Improvements to host stacks can make the performance gains of jumbo > frames less important, e.g. various offloading technologiesCan we get current > measurements and data, e.g., via MAPRG? To a degree techniques like GSO and GRO help. But these are dependent on specific transport protocols. > • We should look at hyperscalers; there is support there for 9000 MTU I believe at least Google is using 9K MTUs in the datacenter for a while. This allows two 4K pages to be sent in TCP which maps to the OS concept of pages. When combined with header data split, this allows zero copy receive to user space via page flipping thereby eliminating expensive copies from the kernel to user space. Interestingly, there is a deployed use case of IPv6 jumbograms; this described in https://lwn.net/Articles/884104/ https://netdevconf.info/0x15/slides/35/BIG%20TCP.pdf. The basic idea is that the host stack can create TCP segments larger than 64K. GSO or TSO is always used to break up the jumbo segments into MTU sized segments for sending. In this way the jumbogram is never sent on the wire, but we get the performance advantages since it saves processing in the TCP stack. > • IPsec, and any encapsulation that benefits from avoiding fragmentation, > can work better with jumbo frames > • We could look a Globus transfer logs to detect MD5 errors for evidence > of issues in the application data not picked up at lower layers > • There are other non-Ethernet technologies used in DCs with large frames > • Does QUIC break offload due to its encryption? In practice QUIC uses a > Max Datagram Packet size less than 1500. Might larger MTUs be useful for QUIC > • Post-quantum scenarios were mentioned. > • What about MTU discovery? There is anecdotal evidence of issues; Tim > has seen this at a UK university where ICMPv6 PTB was being dropped. It's generally assumed that ICMP, including PTB, is unreliable. > • PLPMTUD is specified by QUIC; useful when there’s no path back to a > sender for receipt of an ICMP PTB message. > > Agreed actions: > • Tim will ask Eric Vyncke (INT area AD) for support to create a > “jumbo-discuss” IETF mail list > • We will seek to collectively document the status of jumbo frames, > focusing on what works (success stories), opportunities, gaps (potential work > items in the IETF and elsewhere) and other open issues. > • Tim will ask Eric Vyncke for a side meeting at a future IETF. > • We will seek to present relevant parts of the
[Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-02.txt
Hello, I posted a new version -02 of the IPv4 extension headers draft. The previous version was pushed a while back but I think there is a growing interest in using extension headers and lack of support for IPv6 is a gap. Any comments are appreciated! Thanks, Tom -- Forwarded message - From: Date: Fri, Dec 15, 2023 at 4:55 PM Subject: New Version Notification for draft-herbert-ipv4-eh-02.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-ipv4-eh-02.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-ipv4-eh Revision: 02 Title:IPv4 Extension Headers and Flow Label Date: 2023-12-16 Group:Individual Submission Pages:22 URL: https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-02.txt Status: https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh Diff: https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-02 Abstract: This specification defines extension headers for IPv4 and a definition of an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: "Identification Extension for the Internet Protocol" question
On Mon, Nov 27, 2023 at 12:42 PM Templin (US), Fred L wrote: > > Tom, > > > > I think the best way forward would be to simply define a HBH option > > > that includes an Identification extension to the standard Fragment > > > Header, as per my draft -05: > > > > > Hi Frad, > > > > The problem with that is that the correct processing of the Fragment > > Header would depend on a HBH option, so that HBH can't be ignored by > > the receiving host lest the fragment header is incorrectly processed. > > So the HBH option high order bits can't be 00 (skip when unknown). > > If the source has some sort of operational assurance that the destination will > recognize the HBH option, then it should be OK to include the option even if > the high order bits are 00. And, that is plenty good enough for me. Fred, Unfortunately, that probably wouldn't be good enough for IETF. IP is an inherently stateless protocol and receiver processing must be correctly done just based on a packet's contents; we can never assume that there is external context needed to correctly process IP packets. Introducing statefulness into IP makes it a best effort protocol (this is the first time someone's suggested this) that might work almost all the time-- like maybe 99.999%. But, 99.999% isn't 100% and that is enough to say the protocol isn't robust. In practice, at full Internet scale, someone, somewhere will inevitably see that some operation assurance fails-- when that happens it cannot lead to detrimental behaviors. If you can account for all possible behaviors and show that there are no detrimental behaviors in the edge condition, then the protocol might be considered robust. Tom > > Thanks - Fred > > > -Original Message- > > From: Tom Herbert > > Sent: Monday, November 27, 2023 11:31 AM > > To: Templin (US), Fred L > > Cc: int-area > > Subject: [EXTERNAL] Re: "Identification Extension for the Internet > > Protocol" question > > > > EXT email: be mindful of links/attachments. > > > > > > > > On Mon, Nov 27, 2023 at 9:24 AM Templin (US), Fred L > > wrote: > > > > > > Hi Tom, > > > > > > > -Original Message- > > > > From: Tom Herbert > > > > Sent: Monday, November 27, 2023 9:00 AM > > > > To: Templin (US), Fred L > > > > Cc: int-area > > > > Subject: Re: "Identification Extension for the Internet Protocol" > > > > question > > > > > > > > On Mon, Nov 27, 2023 at 8:01 AM Templin (US), Fred L > > > > wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > > -Original Message- > > > > > > From: Tom Herbert > > > > > > Sent: Friday, November 24, 2023 11:33 AM > > > > > > To: Templin (US), Fred L > > > > > > Cc: int-area > > > > > > Subject: Re: "Identification Extension for the Internet Protocol" > > > > > > question > > > > > > > > > > > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L > > > > > > wrote: > > > > > > > > > > > > > > Tom, please have another look at the draft – it gets the job done > > > > > > > without requiring any new kinds of IPv6 extension headers, HBH > > > > options, > > > > > > etc,: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > From the draft: "For an advanced Identification, this specification > > > > > > permits the source to include a second Fragment Header immediately > > > > > > following the first such that the two are bonded together to create > > > > > > a > > > > > > conceptual IPv6"-- How would this be processed for a legacy receiver > > > > > > that doesn't understand these headers are to be bonded? > > > > > > > > > > > > From the draft: "For the second Fragment Header, only the Next > > > > > > Header > > > > > > field is interpreted as a control field that MUST encode the value N > > > > > > corresponding to the next header to follow while the remaining 7 > > > > > > octets are interpreted
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Mon, Nov 27, 2023 at 9:24 AM Templin (US), Fred L wrote: > > Hi Tom, > > > -Original Message----- > > From: Tom Herbert > > Sent: Monday, November 27, 2023 9:00 AM > > To: Templin (US), Fred L > > Cc: int-area > > Subject: Re: "Identification Extension for the Internet Protocol" question > > > > On Mon, Nov 27, 2023 at 8:01 AM Templin (US), Fred L > > wrote: > > > > > > Hi Tom, > > > > > > > -Original Message- > > > > From: Tom Herbert > > > > Sent: Friday, November 24, 2023 11:33 AM > > > > To: Templin (US), Fred L > > > > Cc: int-area > > > > Subject: Re: "Identification Extension for the Internet Protocol" > > > > question > > > > > > > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L > > > > wrote: > > > > > > > > > > Tom, please have another look at the draft – it gets the job done > > > > > without requiring any new kinds of IPv6 extension headers, HBH > > options, > > > > etc,: > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > > > > > Hi Fred, > > > > > > > > From the draft: "For an advanced Identification, this specification > > > > permits the source to include a second Fragment Header immediately > > > > following the first such that the two are bonded together to create a > > > > conceptual IPv6"-- How would this be processed for a legacy receiver > > > > that doesn't understand these headers are to be bonded? > > > > > > > > From the draft: "For the second Fragment Header, only the Next Header > > > > field is interpreted as a control field that MUST encode the value N > > > > corresponding to the next header to follow while the remaining 7 > > > > octets are interpreted as an Identification Extension."-- This is > > > > repurposing fields in a standard protocol header. Even if it > > > > functionally works, this can break diagnostics and debugging tools in > > > > deployment. > > > > > > How would it be if instead of repurposing the fragmentation control fields > > > in the second Fragment Header we instead make them to be identical copies > > > of the same fields that occurred in the first Fragment Header? Then, the > > > Identification field in the first FH would contain the low-order 4 octets > > > while the Identification field in the second FH would contain the > > > high-order 4 octets of an 8-octet (64-bit) extended Identification, > > > while the fragmentation control fields are identical? I would ideally > > > like to be able to support Identification extension all the way out to > > > 128bits, but I would be happy with 64bits for now. > > > > Hi Fred, > > > > I think the question to be asked is what happens if we send two > > Fragment Headers to a host that is conformant with RFC8200 but unaware > > of the proposed semantics. I don't believe this would "just work" and > > probably a receiver would re-assemble the based on the first header > > resulting in an ill-formed fragment which I suppose would most likely > > timeout since reassembly wouldn't complete. Is the behavior > > deterministic? Are there security ramifications? etc. > > OK, I am willing to let this go. It might be worth adding something to an > "EH limits" draft saying what should be done with IPv6 packets that contain > more than one Fragment Header - should they simply be dropped, for instance? > > > > > IMO, defining a new Hop-by-Hop option for fragmentation still seems > > > > more palatable. > > > > > > This kind of comes back full circle to where this began, where in draft > > > versions > > > -05 and before my original proposal was to use a HBH option for > > > Identification > > > extension maintained separately from the Fragment Header: > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/05/ > > > > > > Are you suggesting to go back to that approach? > > > > > > > General comments: > > > > > > > > Defining a new Hop-by-Hop option for fragmentation still seems more > > > > palatable to me. > > > > > > Oh, so maybe what you are suggesting is a "full service&quo
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Mon, Nov 27, 2023 at 8:01 AM Templin (US), Fred L wrote: > > Hi Tom, > > > -Original Message----- > > From: Tom Herbert > > Sent: Friday, November 24, 2023 11:33 AM > > To: Templin (US), Fred L > > Cc: int-area > > Subject: Re: "Identification Extension for the Internet Protocol" question > > > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L > > wrote: > > > > > > Tom, please have another look at the draft – it gets the job done without > > > requiring any new kinds of IPv6 extension headers, HBH options, > > etc,: > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > Hi Fred, > > > > From the draft: "For an advanced Identification, this specification > > permits the source to include a second Fragment Header immediately > > following the first such that the two are bonded together to create a > > conceptual IPv6"-- How would this be processed for a legacy receiver > > that doesn't understand these headers are to be bonded? > > > > From the draft: "For the second Fragment Header, only the Next Header > > field is interpreted as a control field that MUST encode the value N > > corresponding to the next header to follow while the remaining 7 > > octets are interpreted as an Identification Extension."-- This is > > repurposing fields in a standard protocol header. Even if it > > functionally works, this can break diagnostics and debugging tools in > > deployment. > > How would it be if instead of repurposing the fragmentation control fields > in the second Fragment Header we instead make them to be identical copies > of the same fields that occurred in the first Fragment Header? Then, the > Identification field in the first FH would contain the low-order 4 octets > while the Identification field in the second FH would contain the > high-order 4 octets of an 8-octet (64-bit) extended Identification, > while the fragmentation control fields are identical? I would ideally > like to be able to support Identification extension all the way out to > 128bits, but I would be happy with 64bits for now. Hi Fred, I think the question to be asked is what happens if we send two Fragment Headers to a host that is conformant with RFC8200 but unaware of the proposed semantics. I don't believe this would "just work" and probably a receiver would re-assemble the based on the first header resulting in an ill-formed fragment which I suppose would most likely timeout since reassembly wouldn't complete. Is the behavior deterministic? Are there security ramifications? etc. > > > IMO, defining a new Hop-by-Hop option for fragmentation still seems > > more palatable. > > This kind of comes back full circle to where this began, where in draft > versions > -05 and before my original proposal was to use a HBH option for Identification > extension maintained separately from the Fragment Header: > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/05/ > > Are you suggesting to go back to that approach? > > > General comments: > > > > Defining a new Hop-by-Hop option for fragmentation still seems more > > palatable to me. > > Oh, so maybe what you are suggesting is a "full service" HBH option that > includes not only the (extended) Identification but also the same type of > fragmentation control fields that occur in the Fragment Header? So, in > other words, to support the fragmentation operation one would use this > new HBH option instead of (and not in addition to) the standard FH? If > so, I get the picture but I wonder how it would work. IPv6 extension > header order is: > > IPv6 header > Hop-by-Hop Options header > Destination Options header (note 1) > Routing header > Fragment header > Authentication header (note 2) > Encapsulating Security Payload header (note 2) > Destination Options header (note 3) > Upper-Layer header > > So, if fragmentation controls occurred in the HBH header, wouldn't it > foul up any intermediate destinations that may be named in a Routing > Header that follows? Even if we made it as a Destination Option and > not a HBH, the Routing Header still occurs internally to each fragment, > right? Can you picture a way to orchestrate the fragmentation and > reassembly processes at the HBH level that would not impede > Routing Header processing? Or, maybe as long as the headers > still appear in the same order as above everything just works out? > Yes, you are correct. Fragmentation in HBH with a Routing Header wouldn'
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Sat, Nov 25, 2023 at 12:07 AM Eric Vyncke (evyncke) wrote: > > Fred, > > > > Without any hat, I agree with Tom: any new protocol should be able to work > with legacy (== current) devices including routers on the path. > > > > Tom, rather than HbH (that would be processed by every router on the path and > whose fate is not too positive), I would rather suggest Dest Options as the > fragmentation is basically processed by the source and the final destination. Eric, Yes, if the option isn't processed by routers then Destination Options would be appropriate, but I believe Fred's intent is to allow fragmentation to happen inflight like with IPv4. In either cases of HBH or DestOpts, there is a risk of misinterpretation of the bits following the EH when the fragment option is used. For instance, if the NextHeader in DestOps is 6 and the fragment option is present then a router doing port filtering might skip over the DestOpts and incorrectly interpret the fragment as being a TCP header. I think a solution to that may be to have the reassembled Next Header in the fragment options and to set the NetxHdr in the EH to 59 (No Next Header). This would also ensure that the packet isn't misinterpreted at the receiving host if for some reason it doesn't process the fragment option. Tom > > > > Regards > > > > -éric > > > > From: Int-area on behalf of Tom Herbert > > Date: Friday, 24 November 2023 at 20:33 > To: Templin (US), Fred L > Cc: int-area > Subject: Re: [Int-area] "Identification Extension for the Internet Protocol" > question > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L > wrote: > > > > Tom, please have another look at the draft – it gets the job done without > > requiring any new kinds of IPv6 extension headers, HBH options, etc,: > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > Hi Fred, > > >From the draft: "For an advanced Identification, this specification > permits the source to include a second Fragment Header immediately > following the first such that the two are bonded together to create a > conceptual IPv6"-- How would this be processed for a legacy receiver > that doesn't understand these headers are to be bonded? > > >From the draft: "For the second Fragment Header, only the Next Header > field is interpreted as a control field that MUST encode the value N > corresponding to the next header to follow while the remaining 7 > octets are interpreted as an Identification Extension."-- This is > repurposing fields in a standard protocol header. Even if it > functionally works, this can break diagnostics and debugging tools in > deployment. > > IMO, defining a new Hop-by-Hop option for fragmentation still seems > more palatable. > > General comments: > > Defining a new Hop-by-Hop option for fragmentation still seems more > palatable to me. > > IMO, it would be better to discuss IPv4 and IPv6 in separate drafts. > For instance, the changes you're suggesting for IPv6 would be under > the auspices of 6man. IPv4 changes I suppose fall under int-area. I > also suspect it's more likely that an extended ID would be accepted > into IPv6 than IPv4. > > Also, I would suggest just focusing on what's needed for a larger > Fragment Identification to IP; I think there might be an argument to > be made for that. In particular, I suggest removing discussions or > references to IP Parcels or OMNI as they don't seem essential to the > goal of a larger fragment identifier. > > Tom > > > > > > > > > Thank you – Fred > > > > > > > > > > > > From: Templin (US), Fred L > > Sent: Tuesday, November 21, 2023 7:14 PM > > To: Tom Herbert ; Templin (US), Fred L > > > > Cc: int-area > > Subject: RE: [EXTERNAL] Re: "Identification Extension for the Internet > > Protocol" question > > > > > > > > Tom, > > > > > > > > >The bar for creating any new EH is high. If the data needs to be read or > > >modified by routers then Hop-by-Hop Options is appropriate, if it's only > > >read at the end host or intermediate nodes then Destination Options should > > >be used. > > > > > > > > The Identification needs to be included in the Per-Fragment headers, so I > > guess that means it needs to be “Hop-by-Hop Option”, right? > > > > > > > > Thanks - Fred > > > > > > > > From: Tom Herbert > > Sent: Tuesday, November 21, 2023 4:22 PM > > To: Templin (US), Fred L > > Cc: Templin (US), Fred L ; int-
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L wrote: > > Tom, please have another look at the draft – it gets the job done without > requiring any new kinds of IPv6 extension headers, HBH options, etc,: > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ Hi Fred, >From the draft: "For an advanced Identification, this specification permits the source to include a second Fragment Header immediately following the first such that the two are bonded together to create a conceptual IPv6"-- How would this be processed for a legacy receiver that doesn't understand these headers are to be bonded? >From the draft: "For the second Fragment Header, only the Next Header field is interpreted as a control field that MUST encode the value N corresponding to the next header to follow while the remaining 7 octets are interpreted as an Identification Extension."-- This is repurposing fields in a standard protocol header. Even if it functionally works, this can break diagnostics and debugging tools in deployment. IMO, defining a new Hop-by-Hop option for fragmentation still seems more palatable. General comments: Defining a new Hop-by-Hop option for fragmentation still seems more palatable to me. IMO, it would be better to discuss IPv4 and IPv6 in separate drafts. For instance, the changes you're suggesting for IPv6 would be under the auspices of 6man. IPv4 changes I suppose fall under int-area. I also suspect it's more likely that an extended ID would be accepted into IPv6 than IPv4. Also, I would suggest just focusing on what's needed for a larger Fragment Identification to IP; I think there might be an argument to be made for that. In particular, I suggest removing discussions or references to IP Parcels or OMNI as they don't seem essential to the goal of a larger fragment identifier. Tom > > > > Thank you – Fred > > > > > > From: Templin (US), Fred L > Sent: Tuesday, November 21, 2023 7:14 PM > To: Tom Herbert ; Templin (US), Fred L > > Cc: int-area > Subject: RE: [EXTERNAL] Re: "Identification Extension for the Internet > Protocol" question > > > > Tom, > > > > >The bar for creating any new EH is high. If the data needs to be read or > >modified by routers then Hop-by-Hop Options is appropriate, if it's only > >read at the end host or intermediate nodes then Destination Options should > >be used. > > > > The Identification needs to be included in the Per-Fragment headers, so I > guess that means it needs to be “Hop-by-Hop Option”, right? > > > > Thanks - Fred > > > > From: Tom Herbert > Sent: Tuesday, November 21, 2023 4:22 PM > To: Templin (US), Fred L > Cc: Templin (US), Fred L ; int-area > > Subject: [EXTERNAL] Re: "Identification Extension for the Internet Protocol" > question > > > > EXT email: be mindful of links/attachments. > > > > > > > On Tue, Nov 21, 2023, 2:45 PM Templin (US), Fred L > wrote: > > Tom, I am going to circle back again to where this all started many draft > versions ago. Based on > > my read of RFC6564 and how that was then taken up in RFC8200, it looks like > the barrier would > > be very high to specify any new extension header that does not begin with the > two 1-octet > > fields “Next Header” and “Hdr Ext Len”. The reason for that specification is > to ensure backwards > > compatibility for widely-deployed hardware in the rare event that a new > extension header would > > be defined. So, going back to what I said in earlier draft versions, wouldn’t > it be better if we just > > put the Identification extension in a Hop-by-Hop option instead of defining a > new Fragment > > Header type? > > > > Fred, > > > > The bar for creating any new EH is high. If the data needs to be read or > modified by routers then Hop-by-Hop Options is appropriate, if it's only read > at the end host or intermediate nodes then Destination Options should be used. > > > > Tom > > > > > > Fred > > > > From: Int-area On Behalf Of Templin (US), Fred L > Sent: Tuesday, November 21, 2023 1:30 PM > To: Tom Herbert > Cc: int-area > Subject: Re: [Int-area] [EXTERNAL] Re: "Identification Extension for the > Internet Protocol" question > > > > Tom, > > > > 4 bytes per packet worth of wasted transmission is a pain point experienced > by all nodes on > > the local (shared) transmission media as well as along the networked path – > not just for the > > original source and final destination. Conversely, an odd-sized roadblock in > the middle of a > > path of otherwise 8-octet-aligned stepping
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Tue, Nov 21, 2023, 2:45 PM Templin (US), Fred L wrote: > Tom, I am going to circle back again to where this all started many draft > versions ago. Based on > > my read of RFC6564 and how that was then taken up in RFC8200, it looks > like the barrier would > > be very high to specify any new extension header that does not begin with > the two 1-octet > > fields “Next Header” and “Hdr Ext Len”. The reason for that specification > is to ensure backwards > > compatibility for widely-deployed hardware in the rare event that a new > extension header would > > be defined. So, going back to what I said in earlier draft versions, > wouldn’t it be better if we just > > put the Identification extension in a Hop-by-Hop option instead of > defining a new Fragment > > Header type? > Fred, The bar for creating any new EH is high. If the data needs to be read or modified by routers then Hop-by-Hop Options is appropriate, if it's only read at the end host or intermediate nodes then Destination Options should be used. Tom > > Fred > > > > *From:* Int-area *On Behalf Of *Templin (US), > Fred L > *Sent:* Tuesday, November 21, 2023 1:30 PM > *To:* Tom Herbert > *Cc:* int-area > *Subject:* Re: [Int-area] [EXTERNAL] Re: "Identification Extension for > the Internet Protocol" question > > > > Tom, > > > > 4 bytes per packet worth of wasted transmission is a pain point > experienced by all nodes on > > the local (shared) transmission media as well as along the networked path > – not just for the > > original source and final destination. Conversely, an odd-sized roadblock > in the middle of a > > path of otherwise 8-octet-aligned stepping stones is a processing anomaly > experienced only > > by the forwarding nodes and end systems on the path. And, how bad would > that be, really? > > There is currently no hardware logic that recognizes the IPv6 Extended > Fragment Header > > (since it does not yet exist) and software logic can easily be made to > step around an 8-octet > > alignment anomaly until ASICs begin to emerge that can do it more > efficiently. > > > > So, I say we bend the rules and make the IPv6 Extended Fragment Header as > the sole > > exception IPv6 extension header that does not support 8-octet alignment. > All it would > > take is an update to RFC8200, but we already have to do that in order to > define a new > > extension header type. > > > > Fred > > > > *From:* Tom Herbert > *Sent:* Tuesday, November 21, 2023 1:11 PM > *To:* Templin (US), Fred L > *Cc:* int-area > *Subject:* [EXTERNAL] Re: [Int-area] "Identification Extension for the > Internet Protocol" question > > > > EXT email: be mindful of links/attachments. > > > > > > > On Tue, Nov 21, 2023, 12:15 PM Templin (US), Fred L 40boeing@dmarc.ietf.org> wrote: > > Tom, > > > > >The text you quoted says why we can't do that. If a frag header length is > not a multiple of eight bytes then the alignment requirements for all > subsequent extension headers and the payload are not met. >This potentially > breaks a receiving implementation that relies on alignment. > > > > I both do and don’t understand why this limitation applies here. > Currently, no IP protocol number exists for the IPv6 Extended Fragment > Header, so currently no receiving implementations recognize it. So, why > can’t we define one special-case IPv6 extension header that bends the > rules? As implementations are deployed to recognize it, they will naturally > accommodate the discontinuity in 8-octet aligned extension headers. > > Fred, > > > > The problem isn't with the new header, it's the effects on existing > extension headers that might follow it. > > > > > > With modern architectures, I would think that saving the network > transmission overhead of 4 wasted octets per message would outweigh the > processing drawbacks in having a discontinuity in 8-octet alignment. > Especially since no implementations currently exist. > > > > 4 bytes is 0.3% of minimum 1280 bytes MTU. I don't believe that is > significant enough savings to diverge from the long established > requirements of the standard. > > > > Tom > > > > Fred > > > > > > *From:* Tom Herbert > *Sent:* Tuesday, November 21, 2023 12:04 PM > *To:* Templin (US), Fred L > *Cc:* int-area > *Subject:* [EXTERNAL] Re: [Int-area] "Identification Extension for the > Internet Protocol" question > > > > EXT email: be mindful of links/attachments. > > > > > > > On Tue, Nov 21, 2023, 11
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Tue, Nov 21, 2023, 12:15 PM Templin (US), Fred L wrote: > Tom, > > > > >The text you quoted says why we can't do that. If a frag header length is > not a multiple of eight bytes then the alignment requirements for all > subsequent extension headers and the payload are not met. >This potentially > breaks a receiving implementation that relies on alignment. > > > > I both do and don’t understand why this limitation applies here. > Currently, no IP protocol number exists for the IPv6 Extended Fragment > Header, so currently no receiving implementations recognize it. So, why > can’t we define one special-case IPv6 extension header that bends the > rules? As implementations are deployed to recognize it, they will naturally > accommodate the discontinuity in 8-octet aligned extension headers. > Fred, The problem isn't with the new header, it's the effects on existing extension headers that might follow it. > > With modern architectures, I would think that saving the network > transmission overhead of 4 wasted octets per message would outweigh the > processing drawbacks in having a discontinuity in 8-octet alignment. > Especially since no implementations currently exist. > 4 bytes is 0.3% of minimum 1280 bytes MTU. I don't believe that is significant enough savings to diverge from the long established requirements of the standard. Tom > > > Fred > > > > > > *From:* Tom Herbert > *Sent:* Tuesday, November 21, 2023 12:04 PM > *To:* Templin (US), Fred L > *Cc:* int-area > *Subject:* [EXTERNAL] Re: [Int-area] "Identification Extension for the > Internet Protocol" question > > > > EXT email: be mindful of links/attachments. > > > > > > > On Tue, Nov 21, 2023, 11:44 AM Templin (US), Fred L 40boeing@dmarc.ietf.org> wrote: > > Section 8 of "Identification Extension for the Internet Protocol" proposes > a new IPv6 extension > header called the "Extended Fragment Header" that includes a 96-bit (12 > octet) Identification > field making the total length of the extension header 128-bits (16 octets): > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > However, the only reason for the 96-bit Identification field was to make > the whole > extension header be an integral multiple of 8 octets - what would be > preferable would > be to have only a 64-bit Identification field and limit the Extended > Fragment Header as > a whole to 96-bits (12 octets) which is not a multiple of 8 octets. > > The IPv6 Fragment Header is unique among IPv6 extension headers in that it > does not > include a "Hdr Ext Len" field that tells the length of the header in > 8-octet units. This > means that implementations must be able to determine its length (8 octets) > solely > based on the IP protocol number "44". The proposed IPv6 Extended Fragment > Header > would likewise not include a "Hdr Ext Len" field and would use a new IP > protocol > number to be assigned by IANA, with the IP protocol number determining the > extension header length. > > RFC8200, Section 4 states: > >"Each extension header is an integer multiple of 8 octets long, in >order to retain 8-octet alignment for subsequent headers." > > But, can an exception be made for the proposed IPv6 Extended Fragment > Header > with a 64-bit Identification field, making the total extension header > length 12 octets > which is not a integer multiple of 8? > > > > Hi Fred, > > > > The text you quoted says why we can't do that. If a frag header length is > not a multiple of eight bytes then the alignment requirements for all > subsequent extension headers and the payload are not met. This potentially > breaks a receiving implementation that relies on alignment. > > > > Tom > > > > > Thank you - Fred > > ___ > 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
Re: [Int-area] "Identification Extension for the Internet Protocol" question
On Tue, Nov 21, 2023, 11:44 AM Templin (US), Fred L wrote: > Section 8 of "Identification Extension for the Internet Protocol" proposes > a new IPv6 extension > header called the "Extended Fragment Header" that includes a 96-bit (12 > octet) Identification > field making the total length of the extension header 128-bits (16 octets): > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > However, the only reason for the 96-bit Identification field was to make > the whole > extension header be an integral multiple of 8 octets - what would be > preferable would > be to have only a 64-bit Identification field and limit the Extended > Fragment Header as > a whole to 96-bits (12 octets) which is not a multiple of 8 octets. > > The IPv6 Fragment Header is unique among IPv6 extension headers in that it > does not > include a "Hdr Ext Len" field that tells the length of the header in > 8-octet units. This > means that implementations must be able to determine its length (8 octets) > solely > based on the IP protocol number "44". The proposed IPv6 Extended Fragment > Header > would likewise not include a "Hdr Ext Len" field and would use a new IP > protocol > number to be assigned by IANA, with the IP protocol number determining the > extension header length. > > RFC8200, Section 4 states: > >"Each extension header is an integer multiple of 8 octets long, in >order to retain 8-octet alignment for subsequent headers." > > But, can an exception be made for the proposed IPv6 Extended Fragment > Header > with a 64-bit Identification field, making the total extension header > length 12 octets > which is not a integer multiple of 8? > Hi Fred, The text you quoted says why we can't do that. If a frag header length is not a multiple of eight bytes then the alignment requirements for all subsequent extension headers and the payload are not met. This potentially breaks a receiving implementation that relies on alignment. Tom > Thank you - Fred > > ___ > 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
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Tue, Nov 14, 2023 at 1:33 PM Templin (US), Fred L
wrote:
>
> Tom, RFC2675 was able to set different requirements for UDP checksums for
> classic jumbograms;
> using that precedent, why can't we set different requirements for IP parcels
> and advanced jumbos?
Fred,
That only changed the requirements for how the length field in the
pseudo header is computed. As RFC793 states it "is not an explicitly
transmitted quantity, but is computed". Your proposal would eliminate
the coverage of the whole transport layer payload which has been an
integral part of TCP and UDP checksum from the beginning.
>
> I get what you are saying about tucking a checksum into an IP
> option/extension header field. But,
> the problem with that is every time you extend an IP option/extension you
> have to normalize the
> field on an even 4-octet or 8-octet boundary. So, it eats up space you would
> rather not have to use.
Given a choice between repurposing a field in a standard widely
deployed protocol for a narrow use case that potentially risks
interoperability versus wasting a couple of bytes to avoid doing
that-- I would choose the latter.
Tom
>
> Thank you - Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 12:55 PM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel Halpern
> > ; int-area
> > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Tue, Nov 14, 2023 at 12:17 PM Templin (US), Fred L
> > wrote:
> > >
> > > Tom, what it means is that for IP parcels and advanced jumbos the rule
> > > for calculating the TCP and
> > > UDP checksums is different.
> >
> > Fred,
> >
> > Repurposing the TCP and UDP checksum fields is going to get a lot of
> > pushback and is probably a non-starter. Maybe the parcel option could
> > contain the checksum value.
> >
> > Tom
> >
> > > The rule is that the {TCP,UDP} checksum is calculated over the headers
> > > only while pretending that the payload following the headers is 0 octets.
> > > Meanwhile, each segment
> > > of the payload that follows the {TCP,UDP}/IP headers has its own CRC
> > > which is better integrity
> > > protection than had the segment been included in the {TCP,UDP} checksum.
> > >
> > > So, this is asking routers to check the integrity of the {TCP,UDP}/IP
> > > headers only - if there is an
> > > error at that level, mis-delivery is possible and so probably better to
> > > detect it as early as possible.
> > >
> > > Fred
> > >
> > > > -Original Message-
> > > > From: Tom Herbert
> > > > Sent: Tuesday, November 14, 2023 12:00 PM
> > > > To: Templin (US), Fred L
> > > > Cc: Templin (US), Fred L ;
> > > > Joel Halpern ; int-area > > > a...@ietf.org>
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > > Internet (IP Parcels and Advanced Jumbos)
> > > >
> > > > EXT email: be mindful of links/attachments.
> > > >
> > > >
> > > >
> > > > On Tue, Nov 14, 2023 at 11:51 AM Templin (US), Fred L
> > > > wrote:
> > > > >
> > > > > Tom, the checksum value gets written into the TCP or UDP header
> > > > > checksum field, so if it did not
> > > > > cover the TCP/UDP header fields in addition to the IP pseudo-header
> > > > > then there would be nowhere
> > > > > to place an integrity check for the transport layer port numbers.
> > > >
> > > > Fred,
> > > >
> > > > Sorry, I don't follow. The UDP and TCP checksum fields are set and
> > > > processed per RFC768 and RFC793. These are checksums over the pseudo
> > > > header, transport header, and transport payload. That's standard and
> > > > not something we can change. So I don't understand when you say "the
> > > > checksum does not extend to cover the parcel/jumbo body"
> > > >
> > > > Tom
> > > >
> > > > >
> > > > > It is a good point that checking integrity of layer 4 information at
> > > > > intermediate layer 3 hops may
> > > > > be crossing layers. But, the IP pseudo-header integrity check needs
> > > > > to go somewhere
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Tue, Nov 14, 2023 at 12:17 PM Templin (US), Fred L
wrote:
>
> Tom, what it means is that for IP parcels and advanced jumbos the rule for
> calculating the TCP and
> UDP checksums is different.
Fred,
Repurposing the TCP and UDP checksum fields is going to get a lot of
pushback and is probably a non-starter. Maybe the parcel option could
contain the checksum value.
Tom
> The rule is that the {TCP,UDP} checksum is calculated over the headers
> only while pretending that the payload following the headers is 0 octets.
> Meanwhile, each segment
> of the payload that follows the {TCP,UDP}/IP headers has its own CRC which is
> better integrity
> protection than had the segment been included in the {TCP,UDP} checksum.
>
> So, this is asking routers to check the integrity of the {TCP,UDP}/IP headers
> only - if there is an
> error at that level, mis-delivery is possible and so probably better to
> detect it as early as possible.
>
> Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 12:00 PM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel
> > Halpern ; int-area > a...@ietf.org>
> > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Tue, Nov 14, 2023 at 11:51 AM Templin (US), Fred L
> > wrote:
> > >
> > > Tom, the checksum value gets written into the TCP or UDP header checksum
> > > field, so if it did not
> > > cover the TCP/UDP header fields in addition to the IP pseudo-header then
> > > there would be nowhere
> > > to place an integrity check for the transport layer port numbers.
> >
> > Fred,
> >
> > Sorry, I don't follow. The UDP and TCP checksum fields are set and
> > processed per RFC768 and RFC793. These are checksums over the pseudo
> > header, transport header, and transport payload. That's standard and
> > not something we can change. So I don't understand when you say "the
> > checksum does not extend to cover the parcel/jumbo body"
> >
> > Tom
> >
> > >
> > > It is a good point that checking integrity of layer 4 information at
> > > intermediate layer 3 hops may
> > > be crossing layers. But, the IP pseudo-header integrity check needs to go
> > > somewhere and IPv6
> > > does not include a checksum field in the IPv6 header.
> > >
> > > Thank you - Fred
> > >
> > > > -Original Message-
> > > > From: Tom Herbert
> > > > Sent: Tuesday, November 14, 2023 11:02 AM
> > > > To: Templin (US), Fred L
> > > > Cc: Templin (US), Fred L ;
> > > > Joel Halpern ; int-area > > > a...@ietf.org>
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > > Internet (IP Parcels and Advanced Jumbos)
> > > >
> > > > EXT email: be mindful of links/attachments.
> > > >
> > > >
> > > >
> > > > On Tue, Nov 14, 2023 at 10:36 AM Templin (US), Fred L
> > > > wrote:
> > > > >
> > > > > Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums
> > > > > cover only the pseudo-header
> > > > > of the IP header followed by the fields of the {TCP, UDP} header
> > > > > itself; the checksum does not extend
> > > > > to cover the parcel/jumbo body. In this way, it is very much like the
> > > > > IPv4 header checksum and covers
> > > > > only header fields and no data octets. The reason for this is that
> > > > > the IP parcel and advanced jumbo
> > > > > data segments each have their own CRCs for integrity verification.
> > > >
> > > > Fred,
> > > >
> > > > So this is a type of new checksum of L4 checksum, not the TCP/UDP
> > > > checksum defined in RFC793/RFC768? Do you really need this checksum to
> > > > cover the transport layer header, could it just be over pseudo header?
> > > > (that would greatly simplify router operations)
> > > >
> > > > Tom
> > > >
> > > >
> > > > >
> > > > > Fred
> > > > >
> > > > > > -Original Message-
> > > > > > From: Tom Herbert
> > > > > > Sent: Tuesday, November 14, 2023 10:02 AM
> > > > &
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Tue, Nov 14, 2023 at 11:51 AM Templin (US), Fred L
wrote:
>
> Tom, the checksum value gets written into the TCP or UDP header checksum
> field, so if it did not
> cover the TCP/UDP header fields in addition to the IP pseudo-header then
> there would be nowhere
> to place an integrity check for the transport layer port numbers.
Fred,
Sorry, I don't follow. The UDP and TCP checksum fields are set and
processed per RFC768 and RFC793. These are checksums over the pseudo
header, transport header, and transport payload. That's standard and
not something we can change. So I don't understand when you say "the
checksum does not extend to cover the parcel/jumbo body"
Tom
>
> It is a good point that checking integrity of layer 4 information at
> intermediate layer 3 hops may
> be crossing layers. But, the IP pseudo-header integrity check needs to go
> somewhere and IPv6
> does not include a checksum field in the IPv6 header.
>
> Thank you - Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 11:02 AM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel
> > Halpern ; int-area > a...@ietf.org>
> > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Tue, Nov 14, 2023 at 10:36 AM Templin (US), Fred L
> > wrote:
> > >
> > > Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums cover
> > > only the pseudo-header
> > > of the IP header followed by the fields of the {TCP, UDP} header itself;
> > > the checksum does not extend
> > > to cover the parcel/jumbo body. In this way, it is very much like the
> > > IPv4 header checksum and covers
> > > only header fields and no data octets. The reason for this is that the IP
> > > parcel and advanced jumbo
> > > data segments each have their own CRCs for integrity verification.
> >
> > Fred,
> >
> > So this is a type of new checksum of L4 checksum, not the TCP/UDP
> > checksum defined in RFC793/RFC768? Do you really need this checksum to
> > cover the transport layer header, could it just be over pseudo header?
> > (that would greatly simplify router operations)
> >
> > Tom
> >
> >
> > >
> > > Fred
> > >
> > > > -Original Message-
> > > > From: Tom Herbert
> > > > Sent: Tuesday, November 14, 2023 10:02 AM
> > > > To: Templin (US), Fred L
> > > > Cc: Templin (US), Fred L ; Joel Halpern
> > > > ; int-area
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > > Internet (IP Parcels and Advanced Jumbos)
> > > >
> > > > EXT email: be mindful of links/attachments.
> > > >
> > > >
> > > >
> > > > On Tue, Nov 14, 2023 at 8:11 AM Templin (US), Fred L
> > > > wrote:
> > > > >
> > > > > Tom, thinking more about this IPv6 does not verify header checksums
> > > > > at every hop – only at the
> > > > >
> > > > > final destination. So, how would it be if we simply made header
> > > > > checksum verification a SHOULD
> > > > >
> > > > > at intermediate hops but a MUST at the final destination?
> > > >
> > > > Fred,
> > > >
> > > > So if I understand correctly, this would be validating the TCP and UDP
> > > > checksum at intermediate hops? Frankly, that's going to be a hard sell
> > > > to router vendors, they don't generally have the capability to compute
> > > > those checksums. Also, it's not guaranteed that a TCP and UDP checksum
> > > > are guaranteed to be maintained to be correct while the packet is
> > > > inflight. I believe in current specifications this For instance,
> > > > draft-mizrahi-spring-l4-checksum-srv6-00 would potentially make
> > > > checksums incorrect while packets are inflight.
> > > >
> > > > Tom
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Thanks - Fred
> > > > >
> > > > >
> > > > >
> > > > > From: Int-area On Behalf Of Templin (US),
> > > > > Fred L
> > > > > Sent: Tuesday, November 14, 2023 7:28 AM
> > &g
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Tue, Nov 14, 2023 at 10:36 AM Templin (US), Fred L
wrote:
>
> Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums cover only
> the pseudo-header
> of the IP header followed by the fields of the {TCP, UDP} header itself; the
> checksum does not extend
> to cover the parcel/jumbo body. In this way, it is very much like the IPv4
> header checksum and covers
> only header fields and no data octets. The reason for this is that the IP
> parcel and advanced jumbo
> data segments each have their own CRCs for integrity verification.
Fred,
So this is a type of new checksum of L4 checksum, not the TCP/UDP
checksum defined in RFC793/RFC768? Do you really need this checksum to
cover the transport layer header, could it just be over pseudo header?
(that would greatly simplify router operations)
Tom
>
> Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Tuesday, November 14, 2023 10:02 AM
> > To: Templin (US), Fred L
> > Cc: Templin (US), Fred L ; Joel Halpern
> > ; int-area
> > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Tue, Nov 14, 2023 at 8:11 AM Templin (US), Fred L
> > wrote:
> > >
> > > Tom, thinking more about this IPv6 does not verify header checksums at
> > > every hop – only at the
> > >
> > > final destination. So, how would it be if we simply made header checksum
> > > verification a SHOULD
> > >
> > > at intermediate hops but a MUST at the final destination?
> >
> > Fred,
> >
> > So if I understand correctly, this would be validating the TCP and UDP
> > checksum at intermediate hops? Frankly, that's going to be a hard sell
> > to router vendors, they don't generally have the capability to compute
> > those checksums. Also, it's not guaranteed that a TCP and UDP checksum
> > are guaranteed to be maintained to be correct while the packet is
> > inflight. I believe in current specifications this For instance,
> > draft-mizrahi-spring-l4-checksum-srv6-00 would potentially make
> > checksums incorrect while packets are inflight.
> >
> > Tom
> >
> > >
> > >
> > >
> > >
> > >
> > > Thanks - Fred
> > >
> > >
> > >
> > > From: Int-area On Behalf Of Templin (US),
> > > Fred L
> > > Sent: Tuesday, November 14, 2023 7:28 AM
> > > To: Tom Herbert
> > > Cc: Joel Halpern ; int-area
> > >
> > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > Internet (IP Parcels and Advanced Jumbos)
> > >
> > >
> > >
> > > Tom, the IP parcel / advanced jumbo header checksum is on the same order
> > > of complexity as the
> > >
> > > IPv4 header checksum and covers a similar amount of header data – the
> > > checksum does not run
> > >
> > > over the entire length of the parcel/jumbo. Routers that accept IP
> > > parcels and advanced jumbos
> > >
> > > would need to verify the IP addresses and {TCP,UDP} port numbers if they
> > > receive a parcel that
> > >
> > > was flagged as a CRC error by lower layers – that is all.
> > >
> > >
> > >
> > > Thanks - Fred
> > >
> > >
> > >
> > > From: Tom Herbert
> > > Sent: Monday, November 13, 2023 3:38 PM
> > > To: Templin (US), Fred L
> > > Cc: Joel Halpern ; int-area
> > >
> > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > Internet (IP Parcels and Advanced Jumbos)
> > >
> > >
> > >
> > > EXT email: be mindful of links/attachments.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L
> > > wrote:
> > >
> > > Joel, I am asking this only for IP parcels and advanced jumbos over links
> > > that support them natively.
> > > When a router with a link that supports IP parcels and advanced jumbos
> > > natively receives an
> > > ethernet frame with bad CRC, it first checks to see if it is an IP
> > > parcel/advanced jumbo. If so, the
> > > router performs an integrity check on the {TCP,UDP}/IP headers and
> > > discards the frame if the
> > > header checksum is incorrect. Only if the {TCP,UD}/IP h
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Tue, Nov 14, 2023 at 8:11 AM Templin (US), Fred L
wrote:
>
> Tom, thinking more about this IPv6 does not verify header checksums at every
> hop – only at the
>
> final destination. So, how would it be if we simply made header checksum
> verification a SHOULD
>
> at intermediate hops but a MUST at the final destination?
Fred,
So if I understand correctly, this would be validating the TCP and UDP
checksum at intermediate hops? Frankly, that's going to be a hard sell
to router vendors, they don't generally have the capability to compute
those checksums. Also, it's not guaranteed that a TCP and UDP checksum
are guaranteed to be maintained to be correct while the packet is
inflight. I believe in current specifications this For instance,
draft-mizrahi-spring-l4-checksum-srv6-00 would potentially make
checksums incorrect while packets are inflight.
Tom
>
>
>
>
>
> Thanks - Fred
>
>
>
> From: Int-area On Behalf Of Templin (US), Fred L
> Sent: Tuesday, November 14, 2023 7:28 AM
> To: Tom Herbert
> Cc: Joel Halpern ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
>
>
> Tom, the IP parcel / advanced jumbo header checksum is on the same order of
> complexity as the
>
> IPv4 header checksum and covers a similar amount of header data – the
> checksum does not run
>
> over the entire length of the parcel/jumbo. Routers that accept IP parcels
> and advanced jumbos
>
> would need to verify the IP addresses and {TCP,UDP} port numbers if they
> receive a parcel that
>
> was flagged as a CRC error by lower layers – that is all.
>
>
>
> Thanks - Fred
>
>
>
> From: Tom Herbert
> Sent: Monday, November 13, 2023 3:38 PM
> To: Templin (US), Fred L
> Cc: Joel Halpern ; int-area
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
>
>
> EXT email: be mindful of links/attachments.
>
>
>
>
>
>
> On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L
> wrote:
>
> Joel, I am asking this only for IP parcels and advanced jumbos over links
> that support them natively.
> When a router with a link that supports IP parcels and advanced jumbos
> natively receives an
> ethernet frame with bad CRC, it first checks to see if it is an IP
> parcel/advanced jumbo. If so, the
> router performs an integrity check on the {TCP,UDP}/IP headers and discards
> the frame if the
> header checksum is incorrect. Only if the {TCP,UD}/IP header checksum is
> correct does the
> router forward the (errored) frame. This procedure is repeated at every IP
> forwarding hop
> along the parcel/jumbo-capable path to the final destination.
>
>
>
> Fred,
>
>
>
> This would mean that routers would not only have process L4 headers in flight
> which is already an architectural abomination they often do, they'd also have
> to compute header checksums on L4. It's unlikely router vendors are going to
> be excited to do that. IMO, it would be better to avoid having routers dabble
> in L4 at all for this.
>
>
>
> Tom
>
>
>
>
> Fred
>
> > -Original Message-
> > From: Joel Halpern
> > Sent: Monday, November 13, 2023 2:53 PM
> > To: Templin (US), Fred L
> > Cc: int-area@ietf.org
> > Subject: [EXTERNAL] Re: [Int-area] A new link service model for the
> > Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > You seem to be asking that every router in the Internet deliver frames
> > with bad Ethernet CRCs.(which may have bad destination addresses, since
> > routers do not check upper layer checksums) This is asking every router
> > and eveyr link to pay a significant in the hope that sometimes someone
> > may be able to safely reconstruct the frame.
> >
> > Or are you proposing this for some other network that is not IETF business?
> >
> > Yours,
> >
> > Joel
> >
> > On 11/13/2023 5:43 PM, Templin (US), Fred L wrote:
> > > Joel, I don't mind leaving the IEEE specs alone and allowing the receiver
> > > to deliver errored
> > > frames to upper layers along with a CRC error flag. The CRC error flag
> > > would also make for
> > > a good indication to the IP layer of when the IP addresses and port
> > > numbers should be
> > > checked for consistency so there is value in continuing to let the CRC do
> > > its work.
> > >
> > > About delay and disruption tolerance, IP parcels and advanced jumbos
> >
Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L wrote:
> Joel, I am asking this only for IP parcels and advanced jumbos over links
> that support them natively.
> When a router with a link that supports IP parcels and advanced jumbos
> natively receives an
> ethernet frame with bad CRC, it first checks to see if it is an IP
> parcel/advanced jumbo. If so, the
> router performs an integrity check on the {TCP,UDP}/IP headers and
> discards the frame if the
> header checksum is incorrect. Only if the {TCP,UD}/IP header checksum is
> correct does the
> router forward the (errored) frame. This procedure is repeated at every IP
> forwarding hop
> along the parcel/jumbo-capable path to the final destination.
>
Fred,
This would mean that routers would not only have process L4 headers in
flight which is already an architectural abomination they often do, they'd
also have to compute header checksums on L4. It's unlikely router vendors
are going to be excited to do that. IMO, it would be better to avoid having
routers dabble in L4 at all for this.
Tom
> Fred
>
> > -Original Message-
> > From: Joel Halpern
> > Sent: Monday, November 13, 2023 2:53 PM
> > To: Templin (US), Fred L
> > Cc: int-area@ietf.org
> > Subject: [EXTERNAL] Re: [Int-area] A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > You seem to be asking that every router in the Internet deliver frames
> > with bad Ethernet CRCs.(which may have bad destination addresses, since
> > routers do not check upper layer checksums) This is asking every router
> > and eveyr link to pay a significant in the hope that sometimes someone
> > may be able to safely reconstruct the frame.
> >
> > Or are you proposing this for some other network that is not IETF
> business?
> >
> > Yours,
> >
> > Joel
> >
> > On 11/13/2023 5:43 PM, Templin (US), Fred L wrote:
> > > Joel, I don't mind leaving the IEEE specs alone and allowing the
> receiver to deliver errored
> > > frames to upper layers along with a CRC error flag. The CRC error flag
> would also make for
> > > a good indication to the IP layer of when the IP addresses and port
> numbers should be
> > > checked for consistency so there is value in continuing to let the CRC
> do its work.
> > >
> > > About delay and disruption tolerance, IP parcels and advanced jumbos
> present a ready-made
> > > vehicle for supporting performance maximization, carrying FEC data,
> etc. And, this will be
> > > important for more than just space systems with their long delay links
> - it will become more
> > > and more important for all air/land/sea/space mobility scenarios as
> the Internet becomes
> > > more and more mobile and more and more interplanetary. I think that
> should already be
> > > of interest to Intarea.
> > >
> > > Fred
> > >
> > >> -Original Message-
> > >> From: Joel Halpern
> > >> Sent: Monday, November 13, 2023 1:59 PM
> > >> To: Templin (US), Fred L
> > >> Cc: int-area@ietf.org
> > >> Subject: [EXTERNAL] Re: [Int-area] A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
> > >>
> > >> EXT email: be mindful of links/attachments.
> > >>
> > >>
> > >>
> > >> Top posting two small but important points to Fred:
> > >>
> > >> 1) Changing Ethernet CRC behavior is up to IEEE. IETF is not free to
> > >> redefine that.
> > >>
> > >> 2) There are approaches for links with long delays (sometimes even
> > >> longer than the 8 minutes to which you refer). If you want to propose
> > >> different mechanisms, have the discussion with the delay tolerant
> > >> networking working group. It would be rather odd to change IPv6 for
> > >> that case, and even odder to do without their making a request for a
> change.
> > >>
> > >> Yours,
> > >>
> > >> Joel
> > >>
> > >> On 11/13/2023 4:40 PM, Templin (US), Fred L wrote:
> > >>> Hi Tom,
> > >>>
> > >>> On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
> > >>> wrote:
> > >>>> Hi Tom, see below for responses:
> > >>>>
> > >>>>> -Original Message-
> > >>>>> From: Int-area On Behalf Of Tom
> Herbert
> > >>>>> S
Re: [Int-area] A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Mon, Nov 13, 2023, 4:41 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Hi Tom, > > On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L > wrote: > > > > Hi Tom, see below for responses: > > > > > -Original Message- > > > From: Int-area On Behalf Of Tom Herbert > > > Sent: Monday, November 13, 2023 12:39 PM > > > To: Templin (US), Fred L > > > Cc: int-area@ietf.org > > > Subject: [EXTERNAL] Re: [Int-area] A new link service model for the > Internet (IP Parcels and Advanced Jumbos) > > > > > > EXT email: be mindful of links/attachments. > > > > > > > > > > > > On Mon, Nov 13, 2023 at 11:58 AM Templin (US), Fred L > > > wrote: > > > > > > > > Here is something everyone should read and become familiar with > taken from Section 5 of the latest > > > > version of "IP Parcels and Advanced Jumbos": > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > > > > > > > > A new link service model is offered that will be essential for > supporting air/land/sea/space mobile > > > > Internetworking. IP Parcels and Advanced Jumbos are the vehicles > that support end-to-end as > > > > opposed to hop-by-hop link error detection in the new model. > > > > > > > > This is a truly transformational concept for the Internet - many may > already know about it, but > > > > everyone should become aware of it. > > > > > > Hi Fred, > > > > > > Some comments in line. > > > > > > > > > > > Fred > > > > --- > > > > 5. IP Parcel and Advanced Jumbo Link Service Model > > > > > > > >The classical Internetworking link service model requires each > link > > > >in the path to apply a link-layer packet integrity check often > termed > > > >a "Cyclic Redundancy Check (CRC)". The link near-end calculates > and > > > >appends a CRC code value (often 4 octets) to each packet pending > > > >transmission, and the link far-end verifies the CRC upon packet > > > >receipt. If the CRC is incorrect, the link far-end > unconditionally > > > >discards the packet. This process is repeated for each link in > the > > > >path so that only packets that pass all link-layer CRC checks are > > > >delivered to the final destination. > > > > > > > >While this link service model has contributed to the unparalleled > > > >success of terrestrial Internetworks (including the global public > > > >Internet), new uses in which significant delays or disruptions can > > > >occur are not as well supported. For example, a path that > contains > > > >links with significant bit errors may be challenged to pass a > > > >majority percentage of packets since loss due to CRC failures can > > > >occur at any hop while each packet lost must be retransmitted. > With > > > >the advent of space-domain Internetworking, the long delays > > > >associated with interplanetary signal propagation can also often > > > >render any retransmissions useless especially when communications > > > >latency is critical. > > > > > > How would this compare to an L2 reliable protocol that is able to > > > retransmit over links in the path that are particularly lossy? If > > > latency is critical then we probably can't do any better than > > > retransmitting at L2. > > > > Link-layer retransmissions are still beneficial on low-delay links yes. > But, if > > slightly errored data is still received after N tries, the errored data > should be > > forwarded to the next hop toward the final destination instead of simply > > dropped. Link-layer retransmissions on long-delay links (like 4min OWLT > > from earth to mars) might not be as beneficial. > > > > > >IP parcels and advanced jumbos now offer a new link service model; > > > >instead of requiring an independent CRC at each intermediate link > > > >hop, IP parcels and advanced jumbos include a CRC code with each > > > >segment that is calculated and inserted by the original source and > > > >verified by the final destination. > > > > > > So basically this is an end to end CRC and we'd have to disable the L2 > > > CRC, like Et
Re: [Int-area] A new link service model for the Internet (IP Parcels and Advanced Jumbos)
On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L wrote: > > Hi Tom, see below for responses: > > > -Original Message- > > From: Int-area On Behalf Of Tom Herbert > > Sent: Monday, November 13, 2023 12:39 PM > > To: Templin (US), Fred L > > Cc: int-area@ietf.org > > Subject: [EXTERNAL] Re: [Int-area] A new link service model for the > > Internet (IP Parcels and Advanced Jumbos) > > > > EXT email: be mindful of links/attachments. > > > > > > > > On Mon, Nov 13, 2023 at 11:58 AM Templin (US), Fred L > > wrote: > > > > > > Here is something everyone should read and become familiar with taken > > > from Section 5 of the latest > > > version of "IP Parcels and Advanced Jumbos": > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > > > > > > A new link service model is offered that will be essential for supporting > > > air/land/sea/space mobile > > > Internetworking. IP Parcels and Advanced Jumbos are the vehicles that > > > support end-to-end as > > > opposed to hop-by-hop link error detection in the new model. > > > > > > This is a truly transformational concept for the Internet - many may > > > already know about it, but > > > everyone should become aware of it. > > > > Hi Fred, > > > > Some comments in line. > > > > > > > > Fred > > > --- > > > 5. IP Parcel and Advanced Jumbo Link Service Model > > > > > >The classical Internetworking link service model requires each link > > >in the path to apply a link-layer packet integrity check often termed > > >a "Cyclic Redundancy Check (CRC)". The link near-end calculates and > > >appends a CRC code value (often 4 octets) to each packet pending > > >transmission, and the link far-end verifies the CRC upon packet > > >receipt. If the CRC is incorrect, the link far-end unconditionally > > >discards the packet. This process is repeated for each link in the > > >path so that only packets that pass all link-layer CRC checks are > > >delivered to the final destination. > > > > > >While this link service model has contributed to the unparalleled > > >success of terrestrial Internetworks (including the global public > > >Internet), new uses in which significant delays or disruptions can > > >occur are not as well supported. For example, a path that contains > > >links with significant bit errors may be challenged to pass a > > >majority percentage of packets since loss due to CRC failures can > > >occur at any hop while each packet lost must be retransmitted. With > > >the advent of space-domain Internetworking, the long delays > > >associated with interplanetary signal propagation can also often > > >render any retransmissions useless especially when communications > > >latency is critical. > > > > How would this compare to an L2 reliable protocol that is able to > > retransmit over links in the path that are particularly lossy? If > > latency is critical then we probably can't do any better than > > retransmitting at L2. > > Link-layer retransmissions are still beneficial on low-delay links yes. But, > if > slightly errored data is still received after N tries, the errored data > should be > forwarded to the next hop toward the final destination instead of simply > dropped. Link-layer retransmissions on long-delay links (like 4min OWLT > from earth to mars) might not be as beneficial. > > > >IP parcels and advanced jumbos now offer a new link service model; > > >instead of requiring an independent CRC at each intermediate link > > >hop, IP parcels and advanced jumbos include a CRC code with each > > >segment that is calculated and inserted by the original source and > > >verified by the final destination. > > > > So basically this is an end to end CRC and we'd have to disable the L2 > > CRC, like Ethernet CRC, everywhere along the path for it to work? > > It would still work with Ethernet CRC enabled along the path, but the Ethernet > CRCs would be redundant with the parcel/advanced jumbo segment CRCs. It > might be OK to leave Ethernet CRCs in place, but have the link far end forward > any packets with link errors instead of dropping - but, then the Ethernet CRC > operations would essentially be wasted energy so better to disable them. > > > >Each inte
Re: [Int-area] New Version Notification for draft-herbert-net2hostsig-00.txt
On Mon, Oct 23, 2023 at 1:10 PM Linda Dunbar wrote: > > Tom, > > I find your draft very interesting. I have a couple of questions: Hi Linda, > > what kind of applications are capable of sending signals/requests to the > network? I think it's any application that wants to request network services with characteristics appropriate to the application. Streaming video, video chat, vehicle communication, file transfer, gaming, etc. The idea is that tickets can be used to request a rich set of services provided to the application. > Section 2.3 Network Services: do you see UE sending signals to the network? > Or should it be the Application Controller notify all potential ingress nodes > (i.e. UPFs) I believe UEs should send the signals. I believe the UPF would interpret the host to network signals to identify the application characteristics. This is much more accurate than identifying applications based on IP addresses and port numbers which I believe they do today. Note that even if the UE is sending the signal, the signal content was created by the network and can be authenticated and validated that the user is authorized to use the expressed services. > is the signal to the network reflected by the Transport Protocol? Yes, if the signal is marked as "to be reflected". draft-herbert-fast-07 has some details about how reflection could be implemented > Can IPv6 extension header or flow labels be used to indicate its request to > the network? I'm partial to using Hop-by-Hop Options extension headers. They are extensible and really the only protocol mechanism designed for host to network signaling (and network to host signaling as well). There have been some efforts to commandeer some bits from the flow label, but flow label can only give at most 20 bits of information, all the bits in the flow label are commonly set to a simple hash for a flow, and there's an expectation that the flow label can't change for the lifetime of a transport connection (requests for network services might change over the course of a connection). The problem with HBH extension headers is that they experience a high drop rate on the Internet. The draft discussed some mitigations and there is work in 6man to address this. Tom > > > Thank you. > > Linda > > -Original Message- > From: Int-area On Behalf Of Tom Herbert > Sent: Friday, September 29, 2023 9:24 AM > To: to...@strayalpha.com > Cc: int-area ; tsvwg ; Michael Richardson > > Subject: Re: [Int-area] New Version Notification for > draft-herbert-net2hostsig-00.txt > > On Wed, Sep 27, 2023 at 8:10 PM to...@strayalpha.com > wrote: > > > > 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, > > I tend to agree, but there are a couple of proposals in tsvwg for this so it > is referenced in the draft for completeness trying to cover as much as > possible. > > Tom > > > > > Joe > > > > — > > Dr. Joe Touch, temporal epistemologist > > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.s > > trayalpha.com%2F=05%7C01%7Clinda.dunbar%40futurewei.com%7C0689ac4 > > ab0c247d77bfe08dbc0f7cb4d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7 > > C638315942723729557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FYKpk > > kDA1h83b6eqgTObg5ffxrRbr5tDuK8GbGRnY4M%3D=0 > > > > On Sep 27, 2023, at 4:10 PM, Tom Herbert > > wrote: > > > > Hi, > > > > I've posted a use case and motivation document for Host to Network > > Signaling. > > > > I apologize for cross posting, but I believe this most likely falls in > > the intarea, however we've seen some proposals that could use a common > > protocol framework being presented in tsvwg. > > > > The goal of this document is to motivate discussion on the topic, and > > I believe that it may be significant enough to warrant work on this in > > IETF. > > > > Please review and comment! > > > > Thanks, > > Tom > > > > -- Forwarded message - > > From: > > Date: Wed, Sep 27, 2023 at 4:09 PM > > Subject: New Version Notification for draft-herbert-net2hostsig-00.txt > > To: Tom Herbert > > > > > > A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has > > been successfully submitted by Tom Herbert and posted to the IETF > > repository. > > > > Name: draft-herbert-net2hostsig >
[Int-area] Fwd: New Version Notification for draft-herbert-fast-07.txt
Hi, I have posted a new version of FAST. I apologize for cross posting, I believe this topic likely belongs in int-area, however there has been related discussion in tsvwg. General discussion of host to network signaling is removed and draft-herbert-host2netsig is referenced for that. FAST is now described as a carrier protocol for host to network signaling. Added descriptions and requirements for removing tickets from packets, including by removing the Hop-by-Hop Options header containing tickets. Made various clarifications to protocol format description. Added a section on router implementation considerations. Added a request for an IANA registry for Ticket Types. Any comments are welcome! Tom -- Forwarded message - From: Date: Sat, Oct 7, 2023 at 1:55 PM Subject: New Version Notification for draft-herbert-fast-07.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-fast-07.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-fast Revision: 07 Title:Firewall and Service Tickets Date: 2023-10-07 Group:Individual Submission Pages:24 URL: https://www.ietf.org/archive/id/draft-herbert-fast-07.txt Status: https://datatracker.ietf.org/doc/draft-herbert-fast/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-fast Diff: https://author-tools.ietf.org/iddiff?url2=draft-herbert-fast-07 Abstract: This document describes the Firewalls and Service Tickets (FAST) protocol. This is a generic and extensible protocol for hosts to signal network nodes to request services or to gain admission into a network. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied (in the latter case the ticket serves as a service profile). Applications request tickets from a local agent in their network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to packets. A single ticket may provide both firewall and service ticket information and semantics. Tickets are sent in IPv6 Hop-by-Hop options. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-host2netsig-00.txt
Hi, This is an update to the host to network signaling draft. Note the name is now properly host2netsig. Other changes include: * Add suggestion that signals could be in a namespace managed by IANA and allow vendors to define their own signals * Added a use case that host to network signals could be used as routing hints * Describe motivation and requirement for removing host to network signals from packets in flight, gave example of how this might be done in Hop-by-Hop Options * Added a requirement to define a common carrier protocol for host to network signals * Added a requirement to define a key distribution protocol if signals are encrypted Any feedback is appreciated! Thanks, Tom -- Forwarded message - From: Date: Wed, Oct 4, 2023 at 7:01 AM Subject: New Version Notification for draft-herbert-host2netsig-00.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-host2netsig-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-host2netsig Revision: 00 Title:Host to Network Signaling Date: 2023-10-04 Group:Individual Submission Pages:25 URL: https://www.ietf.org/archive/id/draft-herbert-host2netsig-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-host2netsig/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-host2netsig Abstract: This document discusses the motivations, use cases, and requirements for Host to Network Signaling. In Host to Network Signaling, hosts annotate packets with information that is intended for consumption by on-path elements. Signals may be used to request services on a per packet basis from on-path elements, to request admission into the network, or to provide diagnostics and tracing information. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tsvwg] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
Hi Dan, Thanks for the comments. On Tue, Oct 3, 2023 at 3:46 PM Dan Wing wrote: > > On Sep 29, 2023, at 9:36 AM, Tom Herbert > wrote: > > > On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie > wrote: > > > OK, I see where you are coming from and it makes sense. Hopefully that will > become clear when the IANA Considerations section gets completed. > > Just out of curiosity, how would key distribution and updating work for the > encryption? > > > Herbie, > > That's a very good question, and probably one of the more interesting > sub-problems of host networking that we'll have to solve! That is: How > do we implement distributed security with potentially multiple nodes > performing decryption of the data in the high performance datapath? > > > > Great document. Thanks for gathering all the information in one place. Thanks! > > > The key distribution solution (or obfuscation distribution solution) will > likely require softening the third bullet of > https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig-00#section-6, > >* Host to network signaling MUST be be stateless within the network. > In particular intermediate nodes MUST NOT be required to create > and maintain state for transport layer connections. I think that refers more to the data plane, not necessarily the control plane. > > > To avoid that state the network element would have to dictate the keys (or > the obfuscation) using some spiffy algorithm of its own design. But another > requirement nearly prohibits the network from dictating keys (or > obfuscation), because the endpoint doesn't necessarily know when a different > path is chosen by the network and getting two disparate networks to cooperate > on keying (or obfuscation) seems hard. It reads: > >* Host to network signaling MUST work in a multi-homed and multi- > path environments. For instance, if two packets are sent for a > flow that are annotated with the same a host to network signal, > the signal can be properly processed even if there are no common > on-path nodes for the two packets. Yes, but I would assume that different paths usually means different paths in the same network. Like maybe a mobile device moving from one base station of a provider to the next. If the device crosses into a limited domain, then maybe it needs to get a new signal. > > > > Regarding TCP being the predominant transport protocol: sure, but QUIC is > giving TCP a run for its money, so to speak. The popularity of TCP is not > detrimental to UDP proposals which seek to differentiate certain UDP packets > within the same flow. TCP can't prioritize packets within the same flow > because of in-order delivery. Sure, I will replace 'the' with 'a' :-) > > > The last bullet of > https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig-00#section-5.3 > says > >* The flow label is expected to be unchanged for the duration of a > flow so there is no means to change service parameters mid-flow or > per packet. > > which seems at conflict with IPv6's automatic flow labels you had previously > brought to my attention > (https://ripe82.ripe.net/presentations/20-azimov.ripe82.pdf). The requirement stems from the fact that some stateful firewalls expect consistent routing of all packets in a flow so we had to turn off flow label modulation as the default. In a limited domain, it would be okay to change flow labels mid-flow. In fact, there seems to be a renewed interest in Random Packet Spraying, one of the goals of Ultra Ethernet, and randomly setting the flow label on each packet of a flow would be a pretty easy way to accomplish that if network nodes use the flow label in ECMP-- of course, I wouldn't want to do that when sending on the Internet :-) Tom > > -d > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
On Fri, Sep 29, 2023 at 4:41 PM Kiran Makhijani wrote: > > Hi Tom, > > Section 6, last part is bit garbled. > > "A request can be a detailed list of services requested for a flow, > and the provide signal encapsulates the services to be provider." > > Do you mean "the provider signal encapsulates the services to be > provided”? Also are you saying that host can ask network what services > it can offer? Yes, I will reword it to be clearer. > > "The response to a request is the signal data that the host or > application can attach to its packets." > > The response part is unclear to me. Maybe related to the previous > sentence (or not) Is this a response from the network A (in your > dumbbell topology)? The idea is that an application makes a request for services to an agent in its local network, the agent replies with the signal data that the host attaches to its packet to get the granted services applied. Will try to reword to be clearer. > > Had additional questions from requirements perspective: > > 1. Will the intermediate nodes processing these signals end up doing > decrypt-process-encrypt again? They would just decrypt. Signals are not modifiable (if they were then that would fall under the auspices of network to host signals) > > 2. Should there be a requirement on mutability of signal data? E.g. Yes. > Are nodes authorized/permitted to modify metadata or parameters for a > signal? No, signals are not mutable. See above. Network to host signals would be though. > > 3. In some cases that interest me, it is sufficient that host > communicates its service request to the network it is attached to. > Intelligent network edges can take care of the service delivery from > then on. Would it make sense to allow edge nodes to map to internal > service construct and remove the signal. I am asking this because it > is one way to not mitigate signal exposure of the packets transiting > through the network. Although encryption will serve the purpose but > thought I should still ask. Yes, if there's only one possible consumer of the signal then I think it makes sense to remove the signal once it has been consumed. If Hop-by-Hop Options are used to carry the signal then it can be removed by removing the Hop-by-Hop Options Header (described draft-herbert-eh-inflight-removal) > > Thanks for putting the requirements together. Thanks for the feedback! Tom > Cheers, > Kiran > > > > On September 27, 2023 at 4:11:39 PM, Tom Herbert > (tom=40herbertland@dmarc.ietf.org > (mailto:tom=40herbertland@dmarc.ietf.org)) wrote: > > > Hi, > > > > I've posted a use case and motivation document for Host to Network > > Signaling. > > > > I apologize for cross posting, but I believe this most likely falls in > > the intarea, however we've seen some proposals that could use a common > > protocol framework being presented in tsvwg. > > > > The goal of this document is to motivate discussion on the topic, and > > I believe that it may be significant enough to warrant work on this in > > IETF. > > > > Please review and comment! > > > > Thanks, > > Tom > > > > -- Forwarded message - > > From: > > Date: Wed, Sep 27, 2023 at 4:09 PM > > Subject: New Version Notification for draft-herbert-net2hostsig-00.txt > > To: Tom Herbert > > > > > > A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been > > successfully submitted by Tom Herbert and posted to the > > IETF repository. > > > > Name: draft-herbert-net2hostsig > > Revision: 00 > > Title: Host to Network Signaling > > Date: 2023-09-27 > > Group: Individual Submission > > Pages: 22 > > URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt > > Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/ > > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig > > > > > > Abstract: > > > > This document discusses the motivations, use cases, and requirements > > for Host to Network Signaling. In Host to Network Signaling, a hosts > > annotate packets with information that is intended for consumption by > > on-path elements. Signals may be used to request services on a per > > packet basis from on-path elements to request admission into the > > network or to provide diagnostics and tracing information. > > > > > > > > The IETF Secretariat > > > > ___ > > 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
Re: [Int-area] [tsvwg] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie wrote: > > OK, I see where you are coming from and it makes sense. Hopefully that will > become clear when the IANA Considerations section gets completed. > > Just out of curiosity, how would key distribution and updating work for the > encryption? Herbie, That's a very good question, and probably one of the more interesting sub-problems of host networking that we'll have to solve! That is: How do we implement distributed security with potentially multiple nodes performing decryption of the data in the high performance datapath? Tom > > From: Int-area On Behalf Of Tom Herbert > Sent: Friday, 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 unless you recognize the sender and > know the content is safe.] > > On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie > <mailto:Herbie.Robinson=40stratus@dmarc.ietf.org> wrote: > > > > I have a couple of observations > > > > > > In section 2.2, you make the claim that the actual host to network services > > should be vendor specific. Yet in section 2.3, the example services you > > mention are all things that should, in fact, be standardized. > > The relevant text is: "An outcome of this design is that there is no > requirement for a standard set of signals that all networks must > support; signals can be defined in each provider network per their > needs and the network services they offer." > > It's not so much about being vendor specific, it's more about avoiding > a "one size fits all" approach. An automotive network may offer very > different services than a mobile network which may be different than a > cloud provider. There may be a common set of signals for each of these > types of networks, but I think we want to avoid mandating that the > services and their signals have to be used by everyone. > > > While I am willing to accept that there are examples where vendor specific > > services should be supported, the main focus should be a model for > > describing standard services as well. I am speaking as the maintainer of > > host networking software and by extension the applications that use it. > > Asking applications to interface to potentially hundreds of different > > vendor protocols is unmanageable (from the standpoint of the application > > developer) and will most like result in none of them using any of it. > > Yes, applications should only need one protocol. For the actual > signals, they only have to support the carrier in packets. For > requesting signals, I would envision that applications contact an > agent in the network that makes their request. Maybe something like > REST with some XML description of parameterizations. Since these > requests are not inline with the data path, the requests for services > could be a rich set of parameters (frame rate, latency, > anti-censorship, etc.). The set of possible parameters could be > standard, but it becomes a network specific thing to turn these > parameters into a signal for the services they support in the network > the host can use with its packets. > > > Re: > > > > |Name: draft-herbert-net2hostsig > > |Revision: 00 > > |Title: Host to Network Signaling > > |Date: 2023-09-27 > > |Group: Individual Submission > > |Pages: 22 > > |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt > > |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig > > |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie wrote: > > I have a couple of observations > Hi Herbie, Thanks for the comments! > 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 path (all it takes is a barrel shifter) than > decrypting parts of a packet; so, it would appear that these are conflicting > requirements. Both are, of course, implementable with the appropriate > hardware resources, but I suspect it will take a lot of persuading to get any > vendors to do that. I think variable length headers and decryption have different motivations and are orthogonal. Encryption is needed to hide sensitive data from observers. Host to network signals needed to be encrypted (or at least obfuscated) to prevent abuse of the signals. I suppose if the signals were restricted in a limited domain maybe the requirement for encryption. But, given that there's a need for hosts to network signaling in public networks, I think we need a good solution and it will have to be efficient (maybe network nodes can maintain some sort of cache of signal being received so they only have to decrypt once or something like that) Variable length headers provide extensibility. For variable length header processing, I tend to agree that this problem is being solved (hopefully, we can move past this as being a "headache" in high performance datapath processing). We should be able to leverage constructs like TLVs in network layer protocols but with some judicious limits for practicality (see draft-ietf-6man-eh-limits for example). There's another option here also, just because a protocol allows something to be variable length doesn't mean the length *has* to be variable length. For instance, suppose we define a host to network signal in a Hop-by-Hop Option that has a fixed size. If that's the only HBH option being used in the network, then the option is not only fixed length, it's also always at the same offset in packets. Network devices can process the signal without any variable length processing. Effectively, it's a means to extend the IP header with a fixed length. It's an opportunistic optimization that would never apply in the open Internet, but inside a limited domain where the admin has control over the network infrastructure it is feasible. > > In section 2.2, you make the claim that the actual host to network services > should be vendor specific. Yet in section 2.3, the example services you > mention are all things that should, in fact, be standardized. The relevant text is: "An outcome of this design is that there is no requirement for a standard set of signals that all networks must support; signals can be defined in each provider network per their needs and the network services they offer." It's not so much about being vendor specific, it's more about avoiding a "one size fits all" approach. An automotive network may offer very different services than a mobile network which may be different than a cloud provider. There may be a common set of signals for each of these types of networks, but I think we want to avoid mandating that the services and their signals have to be used by everyone. > While I am willing to accept that there are examples where vendor specific > services should be supported, the main focus should be a model for describing > standard services as well. I am speaking as the maintainer of host > networking software and by extension the applications that use it. Asking > applications to interface to potentially hundreds of different vendor > protocols is unmanageable (from the standpoint of the application developer) > and will most like result in none of them using any of it. Yes, applications should only need one protocol. For the actual signals, they only have to support the carrier in packets. For requesting signals, I would envision that applications contact an agent in the network that makes their request. Maybe something like REST with some XML description of parameterizations. Since these requests are not inline with the data path, the requests for services could be a rich set of parameters (frame rate, latency, anti-censorship, etc.). The set of possible parameters could be standard, but it becomes a network specific thing to turn these parameters into a signal for the services they support in the network the host can use with its packets. > > In section 6, I would also claim that it's a requirement that any vendor > specific services must be registered with the IANA and fully described in > documentation provide free of charge by the vendor. Per above, I think it might be the service parameters they used should be registered. The actual se
Re: [Int-area] New Version Notification for draft-herbert-net2hostsig-00.txt
On Wed, Sep 27, 2023 at 8:10 PM to...@strayalpha.com wrote: > > 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, I tend to agree, but there are a couple of proposals in tsvwg for this so it is referenced in the draft for completeness trying to cover as much as possible. Tom > > Joe > > — > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > On Sep 27, 2023, at 4:10 PM, Tom Herbert > wrote: > > Hi, > > I've posted a use case and motivation document for Host to Network Signaling. > > I apologize for cross posting, but I believe this most likely falls in > the intarea, however we've seen some proposals that could use a common > protocol framework being presented in tsvwg. > > The goal of this document is to motivate discussion on the topic, and > I believe that it may be significant enough to warrant work on this in > IETF. > > Please review and comment! > > Thanks, > Tom > > -- Forwarded message - > From: > Date: Wed, Sep 27, 2023 at 4:09 PM > Subject: New Version Notification for draft-herbert-net2hostsig-00.txt > To: Tom Herbert > > > A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been > successfully submitted by Tom Herbert and posted to the > IETF repository. > > Name: draft-herbert-net2hostsig > Revision: 00 > Title:Host to Network Signaling > Date: 2023-09-27 > Group:Individual Submission > Pages:22 > URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt > Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/ > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig > > > Abstract: > > This document discusses the motivations, use cases, and requirements > for Host to Network Signaling. In Host to Network Signaling, a hosts > annotate packets with information that is intended for consumption by > on-path elements. Signals may be used to request services on a per > packet basis from on-path elements to request admission into the > network or to provide diagnostics and tracing information. > > > > The IETF Secretariat > > ___ > 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
Re: [Int-area] [tsvwg] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
On Wed, Sep 27, 2023 at 11:24 PM Huangyihong (Rachel) wrote: > > Hi Tom, > > I notice that the draft discusses mainly about host to network signaling, > while the draft name is "net2hostsig"... somehow may confuse people also > looking at net2host signals. Ooops, that's a typo. Thanks for putting it out. Tom > > BR， > Rachel > > > -邮件原件- > > 发件人: tsvwg 代表 Tom Herbert > > 发送时间: 2023年9月28日 7:11 > > 收件人: int-area ; tsvwg > > 抄送: Michael Richardson > > 主题: [tsvwg] Fwd: New Version Notification for > > draft-herbert-net2hostsig-00.txt > > > > Hi, > > > > I've posted a use case and motivation document for Host to Network > > Signaling. > > > > I apologize for cross posting, but I believe this most likely falls in the > > intarea, > > however we've seen some proposals that could use a common protocol > > framework being presented in tsvwg. > > > > The goal of this document is to motivate discussion on the topic, and I > > believe > > that it may be significant enough to warrant work on this in IETF. > > > > Please review and comment! > > > > Thanks, > > Tom > > > > -- Forwarded message - > > From: > > Date: Wed, Sep 27, 2023 at 4:09 PM > > Subject: New Version Notification for draft-herbert-net2hostsig-00.txt > > To: Tom Herbert > > > > > > A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been > > successfully submitted by Tom Herbert and posted to the IETF repository. > > > > Name: draft-herbert-net2hostsig > > Revision: 00 > > Title:Host to Network Signaling > > Date: 2023-09-27 > > Group:Individual Submission > > Pages:22 > > URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt > > Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/ > > HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig > > > > > > Abstract: > > > >This document discusses the motivations, use cases, and requirements > >for Host to Network Signaling. In Host to Network Signaling, a hosts > >annotate packets with information that is intended for consumption by > >on-path elements. Signals may be used to request services on a per > >packet basis from on-path elements to request admission into the > >network or to provide diagnostics and tracing information. > > > > > > > > The IETF Secretariat > > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt
Hi, I've posted a use case and motivation document for Host to Network Signaling. I apologize for cross posting, but I believe this most likely falls in the intarea, however we've seen some proposals that could use a common protocol framework being presented in tsvwg. The goal of this document is to motivate discussion on the topic, and I believe that it may be significant enough to warrant work on this in IETF. Please review and comment! Thanks, Tom -- Forwarded message - From: Date: Wed, Sep 27, 2023 at 4:09 PM Subject: New Version Notification for draft-herbert-net2hostsig-00.txt To: Tom Herbert A new version of Internet-Draft draft-herbert-net2hostsig-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-net2hostsig Revision: 00 Title:Host to Network Signaling Date: 2023-09-27 Group:Individual Submission Pages:22 URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig/ HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig Abstract: This document discusses the motivations, use cases, and requirements for Host to Network Signaling. In Host to Network Signaling, a hosts annotate packets with information that is intended for consumption by on-path elements. Signals may be used to request services on a per packet basis from on-path elements to request admission into the network or to provide diagnostics and tracing information. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [EXTERNAL] Re: [IPv6] FW: I-D Action: draft-templin-intarea-ipid-ext-04.txt
On Fri, Sep 1, 2023 at 8:51 AM Templin (US), Fred L wrote: > > Tom, > > > Fred, > > > > I'm still not seeing it. If an extended ID is used then AFAIK this > > would mean that in order for a receiver to correctly reassemble the > > packet it MUST process the extended ID. > > There is a test that the sender uses to determine whether the receiver > recognizes > the option. That's not sufficiently robust. The ping test creates a quasi flow state that isn't reliable. Obviously it doesn't support multicast, but can even fail for unicast if the destination happens to be an anycast address or the destination host to reboot with a different image that no longer recognizes the option. And if a receiver were to ever ignore the extended ID, then that potentially could lead to data corruption which is very bad. > > > This means that the option cannot be ignored by the receiver. > > Receivers that ignore the HBH option will be identified by the test and > will not be subject to Identification Extension. > > > If this is the case, then for a > > Hop-by-Hop Option the higher order type bits cannot be 00 (not ignore > > unrecognized type). However, if the high order bits are not 00 for a > > Hop-by-Hop Option then any intermediate node in the path could drop > > the packet if it doesn't recognize the option which would effectively > > render the solution undeployable. > > I want for the high order bits to be 00. > > > I would suggest that instead of trying to use either a Hop-by-Hop or > > Destination Option for the extended ID, create a new type of > > Fragmentation Extension Header for this purpose. This could be a > > sixteen byte EH that could contain up to a 96 bit identifier. > > It is an idea I had considered, but then asking intermediate IPv6 nodes to > check for an extended Fragment Header would really be no different than > asking the intermediate nodes to check for a HBH option. I think the HBH > option is better because it is the first thing the intermediate nodes will > see. > Why do intermediate nodes need to check for a Fragment Header? At best, an intermediate node might try to parse over the extension headers to find the transport layer for filtering, but for a fragment they can't parse past the Fragment Header. Adding a new type of Fragment Header would equally prevent intermediate nodes from parsing past the Fragment Header (except maybe in the case that the node wants to parse the first fragment). > > For IPv4, I'm not sure given the current state of IP Options support > > in routers that it's feasible to add a new IP option for this. As an > > alternative I'd suggest to use the Fragment Header defined in RFC8200 > > in IPv4. This is discussed in section 2.1.2 of draft-herbert-ipv4-eh. > > I have thought many times about adopting IPv6 extension headers in > IPv4 packets and have proposed it several times with no uptake. An IPv4 > option seems like a cleaner uptake for the IPv4 architecture. It's likely a case where real world considerations trump aspirations of architectural purity. Tom > > Fred > > > Tom > > > > > > > > Fred > > > > > > > -Original Message- > > > > From: Templin (US), Fred L > > > > Sent: Friday, September 01, 2023 8:11 AM > > > > To: 'Tom Herbert' ; Templin (US), > > > > Fred L > > > > Cc: int-area@ietf.org; i...@ietf.org > > > > Subject: Re: [IPv6] [Int-area] FW: I-D Action: > > > > draft-templin-intarea-ipid-ext-04.txt > > > > > > > > Tom, see below: > > > > > > > > > Hi Fred, > > > > > > > > > > I don't see how the Hop-by-Hop Option can work. In IPv6, fragmentation > > > > > is always end to end so a Hop-by-Hop Option really isn't appropriate. > > > > > It should be a Destination Option, but then we'd have to have DestOps > > > > > before the Frag header but after any Routing Header which would > > > > > diverge from the recommended EH ordering in section 4.1 of RFC8200. > > > > > Also, it seems the high order bits of the option type can't be 00 > > > > > (presumably the option must be processed in order to correctly perform > > > > > reassembly), if this is done in a Hop-by-Hop Options then an > > > > > intermediate node may drop the packet even though it doesn't care > > > > > about fragmentation. > > > > > > > > This started out as a destination option *after* the Fragment header > > > > but *before* > > > > the Routing header according to the orde
Re: [Int-area] [IPv6] FW: I-D Action: draft-templin-intarea-ipid-ext-04.txt
On Fri, Sep 1, 2023 at 8:17 AM Templin (US), Fred L wrote: > > Tom, a correction: > > > This started out as a destination option *after* the Fragment header but > > *before* > > the Routing header according to the order stipulated in RFC8200. > > I meant a destination option *before* both the routing and fragment headers > per > Section 4.1 of RFC8200. But regardless, I now still do want to use hop-by-hop. Fred, I'm still not seeing it. If an extended ID is used then AFAIK this would mean that in order for a receiver to correctly reassemble the packet it MUST process the extended ID. This means that the option cannot be ignored by the receiver. If this is the case, then for a Hop-by-Hop Option the higher order type bits cannot be 00 (not ignore unrecognized type). However, if the high order bits are not 00 for a Hop-by-Hop Option then any intermediate node in the path could drop the packet if it doesn't recognize the option which would effectively render the solution undeployable. I would suggest that instead of trying to use either a Hop-by-Hop or Destination Option for the extended ID, create a new type of Fragmentation Extension Header for this purpose. This could be a sixteen byte EH that could contain up to a 96 bit identifier. For IPv4, I'm not sure given the current state of IP Options support in routers that it's feasible to add a new IP option for this. As an alternative I'd suggest to use the Fragment Header defined in RFC8200 in IPv4. This is discussed in section 2.1.2 of draft-herbert-ipv4-eh. Tom > > Fred > > > -Original Message- > > From: Templin (US), Fred L > > Sent: Friday, September 01, 2023 8:11 AM > > To: 'Tom Herbert' ; Templin (US), > > Fred L > > Cc: int-area@ietf.org; i...@ietf.org > > Subject: Re: [IPv6] [Int-area] FW: I-D Action: > > draft-templin-intarea-ipid-ext-04.txt > > > > Tom, see below: > > > > > Hi Fred, > > > > > > I don't see how the Hop-by-Hop Option can work. In IPv6, fragmentation > > > is always end to end so a Hop-by-Hop Option really isn't appropriate. > > > It should be a Destination Option, but then we'd have to have DestOps > > > before the Frag header but after any Routing Header which would > > > diverge from the recommended EH ordering in section 4.1 of RFC8200. > > > Also, it seems the high order bits of the option type can't be 00 > > > (presumably the option must be processed in order to correctly perform > > > reassembly), if this is done in a Hop-by-Hop Options then an > > > intermediate node may drop the packet even though it doesn't care > > > about fragmentation. > > > > This started out as a destination option *after* the Fragment header but > > *before* > > the Routing header according to the order stipulated in RFC8200. But, then I > > realized that I wanted to enable network fragmentation for IPv6 and for that > > I needed a hop-by-hop option to tell intermediate IPv6 hops that recognize > > the option that fragmentation is permitted. This document updates RFC8200. > > > > Fred > > > > > Tom > > > > > > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > > > > > There is also an HTMLized version available at: > > > > https://datatracker.ietf.org/doc/html/draft-templin-intarea-ipid-ext-04 > > > > > > > > A diff from the previous version is available at: > > > > https://author-tools.ietf.org/iddiff?url2=draft-templin-intarea-ipid-ext-04 > > > > > > > > Internet-Drafts are also available by rsync at: > > > > rsync.ietf.org::internet-drafts > > > > > > > > > > > > ___ > > > > I-D-Announce mailing list > > > > i-d-annou...@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > ___ > > > > Int-area mailing list > > > > Int-area@ietf.org > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > > > > IETF IPv6 working group mailing list > > > i...@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] FW: I-D Action: draft-templin-intarea-ipid-ext-04.txt
On Thu, Aug 31, 2023 at 2:53 PM Templin (US), Fred L wrote: > > -Original Message- > From: I-D-Announce On Behalf Of > internet-dra...@ietf.org > Sent: Thursday, August 31, 2023 2:52 PM > To: i-d-annou...@ietf.org > Subject: I-D Action: draft-templin-intarea-ipid-ext-04.txt > > Internet-Draft draft-templin-intarea-ipid-ext-04.txt is now available. > >Title: Identification Extension Options for the Internet Protocol >Author: Fred L. Templin >Name:draft-templin-intarea-ipid-ext-04.txt >Pages: 14 >Dates: 2023-08-31 > > Abstract: > >The Internet Protocol, version 4 (IPv4) header includes a 16-bit >Identification field in all packets, but this length is too small to >ensure reassembly integrity even at moderate data rates in modern >networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit >Identification field included when a Fragment Header is present may >be smaller than desired for some intended uses. This specification >addresses these limitations by defining both an IPv4 header option >and an IPv6 Hop-by-Hop Option for Identification Extension. Hi Fred, I don't see how the Hop-by-Hop Option can work. In IPv6, fragmentation is always end to end so a Hop-by-Hop Option really isn't appropriate. It should be a Destination Option, but then we'd have to have DestOps before the Frag header but after any Routing Header which would diverge from the recommended EH ordering in section 4.1 of RFC8200. Also, it seems the high order bits of the option type can't be 00 (presumably the option must be processed in order to correctly perform reassembly), if this is done in a Hop-by-Hop Options then an intermediate node may drop the packet even though it doesn't care about fragmentation. Tom > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-templin-intarea-ipid-ext-04 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-templin-intarea-ipid-ext-04 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > > ___ > 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
Re: [Int-area] How long wasWhat is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Behcet Sarikaya Sent: 06 April 2023 16:48 On Thu, Apr 6, 2023 at 5:17 AM tom petch mailto:ie...@btconnect.com>> wrote: From: Robert Moskowitz mailto:rgm-i...@htt-consult.com>> Sent: 05 April 2023 18:58 The origin draft only was discussing SCHC as an IP Protocol Number. At IETF115, the attendees agreed that the draft needs to be expanded to also SCHC as an Ethertype and as a UDP Port Number. Thus the old draft name no longer reflects the new content. A very common state of affairs in the IETF. If the name changed for every semantic change then some I-D would go through a large number of names before making it to RFC which would make it hard for anyone to find out what has happened. I recall an AD losing track of what had been proposed because they did not realise that there had been a name change. The I-D title matters, that is there for the long haul. The I-D file name is a temporary identifier that should follow the requirements for an identifier, a key one of which is stability and a key one which is not is for the name to be updated if some part of the semantics change. And another key one is being subject to maximum of 55 characters Mmm I wonder. If the line length is 72 characters and the footing contains 'Internet-draft' and 'December 2922' then I do not think that there is room for 55 characters. I note that RFC7991 says 'If it is long (~40 characters), the "abbrev" attribute can be used to specify an abbreviated variant.' which suggests a lower limit yo me. Tom Petch I am happy to see protocol number as encompassing an Ethertype protocol number, a media type protocol number, an interface protocol number and so on so see no need to change. Wholeheartedly agree. We should not have to change the I-D file name. Behcet Tom Petch p.s. I could tell you about a scientific (in)discipline where a small group feed their egos by changing identifiers every few years thereby rendering the literature, where a name could appear a million times, hard to use for those of us who have been around for a while and ever more difficult to access for students in future (which is how to feed an ego) but I will leave that for another day. There is a mechanism when you submit a draft to link it to a prior draft so the draft history is properly maintained (it does not support linking to multiple prior drafts or splitting an old draft into multiple, for that you have to ask for human help). So the new draft name will reflect the new draft content. I just don't have enough time to get content into the new draft prior to Passover Holiday start. I hope to get it done during the middle days, say Sunday. Stay tuned. Pascal Thubert is helping me with the new content. Particularly the specific content needed to liason with IEEE 802 on the Ethertype. Bob On 4/5/23 11:49, tom petch wrote: > From: Int-area mailto:int-area-boun...@ietf.org>> > on behalf of Robert Moskowitz > mailto:rgm-i...@htt-consult.com>> > Sent: 05 April 2023 12:22 > > 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. > > So what to name the new draft? > > > If you are producing a new version of > draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it > draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other > logical choice. > > Tom Petch > > > > draft-ietf-intarea-schc-protocol-numbers > > ?? > > Alternatives? > > Thanks and now back to my writing as I really want to get an update out > today before Holidays... > > Bob > > ___ > Int-area mailing list > Int-area@ietf.org<mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org<mailto: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
Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Robert Moskowitz Sent: 05 April 2023 18:58 The origin draft only was discussing SCHC as an IP Protocol Number. At IETF115, the attendees agreed that the draft needs to be expanded to also SCHC as an Ethertype and as a UDP Port Number. Thus the old draft name no longer reflects the new content. A very common state of affairs in the IETF. If the name changed for every semantic change then some I-D would go through a large number of names before making it to RFC which would make it hard for anyone to find out what has happened. I recall an AD losing track of what had been proposed because they did not realise that there had been a name change. The I-D title matters, that is there for the long haul. The I-D file name is a temporary identifier that should follow the requirements for an identifier, a key one of which is stability and a key one which is not is for the name to be updated if some part of the semantics change. I am happy to see protocol number as encompassing an Ethertype protocol number, a media type protocol number, an interface protocol number and so on so see no need to change. Tom Petch p.s. I could tell you about a scientific (in)discipline where a small group feed their egos by changing identifiers every few years thereby rendering the literature, where a name could appear a million times, hard to use for those of us who have been around for a while and ever more difficult to access for students in future (which is how to feed an ego) but I will leave that for another day. There is a mechanism when you submit a draft to link it to a prior draft so the draft history is properly maintained (it does not support linking to multiple prior drafts or splitting an old draft into multiple, for that you have to ask for human help). So the new draft name will reflect the new draft content. I just don't have enough time to get content into the new draft prior to Passover Holiday start. I hope to get it done during the middle days, say Sunday. Stay tuned. Pascal Thubert is helping me with the new content. Particularly the specific content needed to liason with IEEE 802 on the Ethertype. Bob On 4/5/23 11:49, tom petch wrote: > From: Int-area on behalf of Robert Moskowitz > > Sent: 05 April 2023 12:22 > > 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. > > So what to name the new draft? > > > If you are producing a new version of > draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it > draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other > logical choice. > > Tom Petch > > > > draft-ietf-intarea-schc-protocol-numbers > > ?? > > Alternatives? > > Thanks and now back to my writing as I really want to get an update out > today before Holidays... > > Bob > > ___ > 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
Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 05 April 2023 12:22 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. So what to name the new draft? If you are producing a new version of draft-ietf-intarea-schc-ip-protocol-number-00 then I would call it draft-ietf-intarea-schc-ip-protocol-number-01. I do not see any other logical choice. Tom Petch draft-ietf-intarea-schc-protocol-numbers ?? Alternatives? Thanks and now back to my writing as I really want to get an update out today before Holidays... Bob ___ 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
Re: [Int-area] [EXTERNAL] Re: About draft-templin-intarea-parcels
On Thu, Nov 10, 2022 at 8:34 AM Templin (US), Fred L
wrote:
>
> Tom, IP parcels have a very significant difference from the GSO/GRO and
> others you mentioned
> in that IP parcels allow a *single* packet to contain *multiple* upper layer
> protocol segments;
> in all of the other schemes you cited, it is always a single ULP segment per
> packet. This alone
> demonstrates that IP parcels at the very least provides a significant savings
> in terms of reduced
> packet headers, since only a single copy of the {TCP,UDP}/IP headers appears
> and not multiple.
>
> The maximum IP parcel size is also not constrained by the underlying network
> path MTU the
> same way that the maximum GSO/GRO packet size is. So, even if the path MTU is
> only 1500
> IP parcels up to 64KB and even larger can be sent over an OMNI interface
> configured over
> the path. If you did that with GSO, then the packets would arrive at the
> destination
> fragmented and as you know in linux GRO cannot apply UDP/IP reassembly to
> packets
> that have already undergone fragmentation at the sub-IP layer. Yes, you can
> linearize
> the packets but the second you do that any GRO performance gains are lost.
>
> You mentioned data centers going to 9KB, and while that is good it is still
> way smaller
> than what we should be aiming for. IP parcels will encourage links with much
> larger
> MTUs - 64KB is just a starting point, and going much larger into multiple MBs
> can
> be a near-term goal. Yes, IP parcels can take full advantage of 9KB MTUs
> right away
> and still be better than the other schemes because larger MTUs at the sub-IP
> layer
> result in less IPv6 fragmentation and associated savings in sub-IP layer
> encapsulation
> overhead.
>
> IP parcels can be thought of as a gateway to larger MTUs in the Internet
> without
> having to compromise integrity and/or without having to retransmit lots of big
> blocks of data if only just one or a couple of bits were damaged in transit.
> The
> IP parcels philosophy is to accept as much good data as possible while asking
> for retransmission only of errored data that cannot be locally repaired. This
> will be good for a vast array of bulk-transfer Internetworking applications,
> not
> only within the local data center but also across the wide area using OMNI.
>
> I could go on, but I won't for now. I have done the work, and I have shown the
> work. The community now needs to apply a check-mark to acknowledge.
Fred,
Again, the data you've presented should be the value of segmentation,
not the unique value of IP parcels which, AFAICT, are another form of
segmentation. If you want to make a convincing argument that IP
Parcels has merit, I believe you'll need to provide explicit data that
shows IP parcels are superior to the existing segmentation techniques
that are implemented and in deployment. Furthermore, since IP Parcels
is a protocol change and not just an implementation change, you should
expect that the bar is going to be high in both IETF as well when this
is presented to an OS like LInux-- e.g. a minor performance
improvement or saving a few bytes of overhead probably isn't enough.
In other words, you'll really need to do your homework on what people
have over the years done to address the performance problems IP
Parcels endeavours to solve if the community is going to accept IP
Parcels :-).
Tom
>
> Fred
>
> > -Original Message-
> > From: Tom Herbert
> > Sent: Wednesday, November 09, 2022 9:22 AM
> > To: Templin (US), Fred L
> > Cc: Richard Li ; int-area@ietf.org
> > Subject: [EXTERNAL] Re: [Int-area] About draft-templin-intarea-parcels
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Wed, Nov 9, 2022 at 7:47 AM Templin (US), Fred L
> > wrote:
> > >
> > > Richard, thank you for your message. The intarea community must
> > > understand that
> > >
> > > the live IP Parcels presentation given today was only a “roadmap” to a
> > > proper
> > >
> > > presentation which could not be given due to time constraints. The charts
> > > shown
> > >
> > > during the live presentation were skipped over quickly, but they provide
> > > full
> > >
> > > detail and are permanently available here:
> > >
> > >
> > >
> > >
> > > https://datatracker.ietf.org/meeting/115/materials/slides-115-intarea-ip-parcels
> > >
> > >
> > >
> > > Running code is also now permanently available here:
> > >
> > >
> > >
> > > https://github.com/fltemplin/ip-parcels
> > >
>
Re: [Int-area] About draft-templin-intarea-parcels
On Wed, Nov 9, 2022 at 7:47 AM Templin (US), Fred L wrote: > > Richard, thank you for your message. The intarea community must understand > that > > the live IP Parcels presentation given today was only a “roadmap” to a proper > > presentation which could not be given due to time constraints. The charts > shown > > during the live presentation were skipped over quickly, but they provide full > > detail and are permanently available here: > > > > > https://datatracker.ietf.org/meeting/115/materials/slides-115-intarea-ip-parcels > > > > Running code is also now permanently available here: > > > > https://github.com/fltemplin/ip-parcels > > > > and provides clear evidence that IP parcels provide an appreciable performance > > gain which cannot be ignored any longer. > > > > IP parcels are good for the Internet, and the presentation charts and running > code > > provide clear evidence. It is time to adopt IP parcels. Fred, Thanks for the data and implementation, but I'm still not convinced that IP parcels should be adopted. Your data seems to show that when the networking stack processes large segments performance increases (fewer packets to process in the data path is a win). We've known this for a long time and that's why stacks commonly implement various segmentation techniques like GSO/TSO, GRO/LRO, UFO, USO, and more recently BigTCP. Also, within the data center, 9K MTUs are becoming common place which is even better than segmentation with 1500 byte MTU. The major difference between these techniques and IP parcels is that the segmentation techniques don't require any new protocol or changes to an existing protocol, whereas IP parcels requires protocol changes. So in order to justify IP parcels adoption, not just in IETF but also upstreaming into Linux, I think you'll want to show that it has significant benefits over the existing segmentation techniques to justify the complexities and cost of a new protocol. Tom > > > > Fred > > > > From: Int-area On Behalf Of Richard Li > Sent: Wednesday, November 09, 2022 6:12 AM > To: int-area@ietf.org > Subject: [Int-area] About draft-templin-intarea-parcels > > > > Hi Chairs and All, > > > > At today’s intarea meeting, the chair asked the participants if anybody has > an interest in this draft or not. If nobody is interested, this draft will be > closed, and if anyone is interested, he/she is asked to voice it on the > mailing list. > > > > As a follow up, I am expressing my interest in this draft, and would like to > see this draft open and let it go on. A few months ago, I asked its authors > several questions, and the authors answered and clarified them. I do see good > values for some use cases, especially for those in broadband access and jumbo > frames being used on the links. It seems to me that this draft points to a > useful direction, some rooms are remaining for expansion though. > > > > Thanks, > > > > Richard > > > > ___ > 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
Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 08 September 2022 14:03 On 9/8/22 08:31, Pascal Thubert (pthubert) wrote: > Hello Joel: > > SCHC could be used to compress IP option headers and the residue be stored in > a SCHC option, which a next header points at uncompressed transport (e.g., > encrypted, uncompressible). > Additionally, finding the SCHC context may require metadata that could also > be found in a SCHC option. Over one hop in LPWAN that is all implicit but > over IP it might not be. > > SCHC is layered depending on which endpoint talks to which. E.g., you > compress a tunnel with inner that is already SCHC-compressed, you do > security, etc... > So you could have SCHC options one after the other. We have not defined the > option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs. > > But since we're at it, let's do both in one RFC. > Note that we'll also need a value for IPv6-Compression-Protocol Types, see > https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations. > I cannot find this IANA registry. Can someone please provide the URL. Perhaps https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29 IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field Assignments Group on the IANA website as set up by RFC1332. Tom Petch And this is why I have been instructed, and have adhered to, including IANA URLs as informative references in my drafts. Like in draft-moskowitz-intarea-schc-ip-protocol-number! Bob ___ 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
Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number
From: Int-area on behalf of Robert Moskowitz Sent: 07 September 2022 03:43 As was discussed at the INTAREA meeting at IETF 114, I request that a call for WG adoption of this draft. I have made draft name change and edits per Bob Hinden. I am sorry you have made this change. The draft name only has meaning for the life of the draft; it needs to be unique, it needs to guide readers as to its content, it does not have to be semantically and syntactically perfect. The document title, on the other hand, lives for ever and so its value matters - change the draft name just makes it harder for everyone to track what has and is happening. Tom Petch As I said earlier, there is a lot of work which will cascade in other areas once this is one its way. thanks Bob Forwarded Message Subject:New Version Notification for draft-moskowitz-intarea-schc-ip-protocol-number-00.txt Date: Tue, 06 Sep 2022 19:40:41 -0700 From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: Stuart W. Card <mailto:stu.c...@axenterprize.com>, Adam Wiethuechter <mailto:adam.wiethuech...@axenterprize.com>, Robert Moskowitz <mailto:r...@labs.htt-consult.com>, Stuart Card <mailto:stu.c...@axenterprize.com> A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-intarea-schc-ip-protocol-number Revision: 00 Title: Internet Protocol Number for SCHC Document date: 2022-09-06 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/ Html: https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number Abstract: This document requests an Internet Protocol Number assignment for SCHC so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Mon, Aug 1, 2022 at 9:51 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Juan Carlos and intarea, there is actually much more to be said about this > from a “big-picture” > > standpoint that has not been said yet. In particular, the AERO/OMNI and IP > Parcels architecture > > uniquely enable fast and efficient large object transports in conjunction > with small-message > > interactive communications requiring low latency. It does this by allowing > large MTU links > > (9KB or larger) in edge network data centers while requiring small MTU > links (9KB or smaller) > > in the core transit network. In that way, end systems can send large > objects in IP Parcels that > > take advantage of the larger edge network link MTUs, but become fragmented > when they > > reach an OMNI link ingress node. The fragmentation allows the IP parcel to > transit the core > > network where there are small MTU links, but without interfering with > interactive small message > > communications also transiting the core due to fragmentation interleaving. > Then, at the far > > end the final destination which may also be located in an edge network > having large MTU > > links can efficiently receive the larger IP Parcels. > > > > This has been known for many decades, but perhaps not widely discussed. > Back in 1988 > > when the DECnet architects were bringing FDDI into the architecture, then > even had a name > > for it and called it the “dumbbell configuration” (FDDI in edge networks > and Ethernet core): > > > > > > So, in this dumbbell model, peer end systems located in the rightmost and > leftmost FDDI rings > > could send IP Parcels up to 4500 bytes and the Ethernet link ingress and > egress nodes would > > fragment and reassemble. The core would therefore see only 1500 byte and > lesser with fair > > sharing interleaving between both bulk transfer and interactive > communications. Replace the > > Ethernet link in the above diagram with a network of networks and > configure an OMNI > > interface over it, and the same effect can be had using AERO/OMNI and IP > Parcels. > Hi Fred, It's not really the same thing. Presumably, at the ingress each 4500 byte packet would be fragmented and could be serially sent over a PTP Ethernet link. This makes reassembly at the egress side fairly trivial since one could assume that all the fragments are received in proper order with no fragments for other flows mixed in. So the egress side only needs a 4500 byte reassembly buffer. However, you replace the Ethernet in the picture with an IP network, then these simplifying properties no longer apply. The egress side may receive fragments out of order, and there may simultaneously may be multiple flows in reassembly. So the required memory for reassembly is greater than 4500 bytes, possibly much greater than that. Also, since this is not a PTP link, packets for a flow may take different paths such that reassembly never completes and hence timers are required to punt on reassembly. > > This would make for a better and more efficient internetworking service > for all supporting > > a diversity of services ranging from delay-sensitive interactive > communications to short > > transactions, to high data rate binary large object transfers with the > best properties applied > > according to traffic type. It is good for the Internet, therefore > AERO/OMNI and IP Parcels > > are good and should be adopted. > As I and others have pointed out, performing reassembly in the network is costly to routers (i.e. cost in memory at least) and difficult to get right otherwise (e.g. many edge conditions, trade offs between a non work-conserving opportunistic optimization and tail case latency). If you remove in-network reassembly from the proposal, there is still potential for "intelligent" fragmentation in the network where losing a fragment doesn't mean losing the whole packet, but it's not clear to me that the benefits for that outweigh the costs. Tom > > > Fred > > > > *From:* Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Templin > (US), Fred L > *Sent:* Friday, July 29, 2022 6:44 AM > *To:* Juan Carlos Zuniga (juzuniga) ; > int-area@ietf.org > *Subject:* Re: [Int-area] Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > FYI, a new draft version is posted with the following updates: > > > > 1) Senders encodes the number of segments included in the Jumbo Payload > header so receivers > > can accurately determine packaging sizes. > > > > 2) Excuses OAL intermediate nodes from having to perform parcel > sub-dividing or re-combining. > > > > Fred > >
Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 3:21 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Hi Tom, > > > > No, this is not a transparent proxy; I should know – I “invented” them > (see US Patent 5,781,550). > > > > No, these middlebox/proxy devices only kick into gear if a packet is > explicitly addressed to > > themselves; but, that is at the adaptation layer, and not necessarily at > the IP layer. > Fred, Your terminology is confusing to me. When a source host sends a packet with an IP parcel, what is the IP destination address that the source host put into the packet sent on the network? Is it the destination host, or the address of some intermediate node that will perform reassembly and then forward the reassembled packet to the destination via some sort of routing header or encapsulation? Tom > > Fred > > > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Tuesday, July 12, 2022 12:42 PM > *To:* Templin (US), Fred L > *Cc:* Joel Halpern ; int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > > > On Tue, Jul 12, 2022 at 9:59 AM Templin (US), Fred L < > fred.l.temp...@boeing.com> wrote: > > Joel, it also bears mention that today’s link MTUs cap out at about 9KB > because that > > is the maximum size that is well-supported by link-layer CRC-32 checks – > links with > > larger MTUs have been considered in the past (e.g., the HiPPI you > mentioned earlier) > > but one of the reasons they do not predominate today is due to the > diminished link > > layer integrity check considerations. IP parcels change the game because > they may > > include multiple upper layer integrity checks per packet instead of a > single integrity > > check. This means that parcel-capable links with MTUs as large as 64KB (or > even > > larger still) become possible, which opens the possibility for new > innovation. > > > > About middleboxes reassembling parcels, it might help if you try not to > think of them > > as routers but instead think of them as “proxys” that are performing a > function in the > > network on behalf of a host. That sort of thing happens all the time with > proxys today; > > indeed, even this email I am sending right now will be forwarded by a > proxy. > > > > Fred, > > > > At best this would be considered a transparent proxy. The host is not > sending packets to the proxy, it's that the proxy is intercepting them. > IMO, transparent proxies have been the bane of the Internet. They are > invasive in protocol layers that the network is not supposed to be > concerned with, and host developers spend much more time trying to work > around the constraints and problems with these devices than rejoicing > their existence. > > > > Tom > > > > > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 9:43 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > There are no "parcel-capable links" You are trying to invent them. You > are allowed to invent them. > > But in the absence of a physical link that can actually handle parcels > natively, I do not see any benefit in handling parcels (if needed at all) > anywhere except the hosts. > > At this point the chairs know my opinion. I will leave it to them to > conclude this adoption call and make the rough consensus decision. > > Yours, > > Joel > > On 7/12/2022 12:38 PM, Templin (US), Fred L wrote: > > Joel, > > > > The path for an IP parcel traverses parcel-capable links. Some of those > links might > > be physical links (most likely links nearest the source and links nearest > the destination) > > while others might be virtual (most likely links in between). Only > forwarding nodes on > > those kinds of virtual links would deal with parcel packaging and > repackaging, and > > there would be very few of those. Routers that connect physical > parcel-capable links > > would either forward the parcel if it is not too big or drop it and return > a PTB otherwise. > > This is very much intarea territory. > > > > Fred > > > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 9:20 AM > *To:* Templin (US), Fre
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 9:23 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Tom, I think the fact that ULP segment size need not closely conform to > the path MTU > > in order to get optimum performance (i.e., even if fragmentation is > needed) challenges > > conventional wisdom and needs to be repeated early and often. I think the > fact that > > upper layers including multiple segments per system call can increase > performance also > > bears repeating. To be truthful, I have not yet sent an actual IP parcel > over the wire but > > that would be a logical next step. Some linux kernel hacking will be > necessary, but very > > much in the realm of possibility. > Fred, Without running code, it's really hard to make the argument that IP parcels improve host performance. > > > You suggested earlier that a parcel could include a full checksum for the > entire parcel > > along with individual checksums for the separate segments and yes that > works. Is > > your thinking that the “master” checksum would then be verified in > hardware while > > the “per-segment” checksums are verified by upper layers? > No, just the master checksum. Having the upper layers verify the checksums means that it would be done in the host CPU which makes it a non-starter because of performance. > The problem with having > > a master checksum for the full parcel is that the entire parcel would be > discarded if > > there is even just a single bit error in just one of the segments. In > other words, many > > good segments could be thrown away instead of just the one bad segment. > That > > would make the retransmission unit significantly larger than the loss unit > which is > > something we are trying to avoid. > Right, but AFAIK a failure to verify an integrity check in pretty much all protocol means the packet is corrupt so drop it. In this new model, parts of a packet would be accepted and parts might be dropped-- I think that's going to be a hard sell in itself. However, this problem only occurs if an intermediate performs reassembly, so if only the end host can reassemble then there's no issue. Segments with a good packet checksum are accepted, those with bad ones are dropped and checksums are properly offloaded. Tom > > Fred > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Tuesday, July 12, 2022 8:53 AM > *To:* Templin (US), Fred L > *Cc:* Joel Halpern ; int-area@ietf.org > *Subject:* Re: [Int-area] Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > > > On Tue, Jul 12, 2022 at 8:23 AM Templin (US), Fred L < > fred.l.temp...@boeing.com> wrote: > > Joel, I can show you an orders-of-magnitude performance speed-up when I > send > > large blocks of data using larger segment sizes that invoke fragmentation > and > > reassembly. I can also show a significant speed-up when system calls pass > > multiple larger segments in a single system call instead of one at a time. > This > > is on real systems with real data, and not in simulations. > > > > Fred, > > > > You are making an argument that larger segment sizes is more efficient-- > yes, we know that. The argument that you really should be making is that > "IP parcels" is necessary and sufficient to get those benefits and why the > on-wire-protocol change is justified for the benefits. For instance, when > you say "real systems with real data" are these system running IP parcels > then, or is this an extrapolation using existing techniques? If it's the > latter case then this really isn't very helpful in justifying IP parcels. > > > > Tom > > > > > > About links with larger MTUs, I am specifically NOT saying that we need to > wait > > until we have links with MTU>64K. What I am saying is that parcels would > pave > > the way toward evolution of links with larger MTUs than what we have in the > > current practice allowing a path forward for future innovation. But, > parcels are > > still good even for the smallish MTUs in widescale deployment today. > > > > Fred > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 7:44 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* [EXTERNAL] Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > Fred, I understood full well that you only envision a small number of > reassembly devices. After all, on any given path only one device will > likely reassemble. Still, that device will be spending a l
Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 9:59 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Joel, it also bears mention that today’s link MTUs cap out at about 9KB > because that > > is the maximum size that is well-supported by link-layer CRC-32 checks – > links with > > larger MTUs have been considered in the past (e.g., the HiPPI you > mentioned earlier) > > but one of the reasons they do not predominate today is due to the > diminished link > > layer integrity check considerations. IP parcels change the game because > they may > > include multiple upper layer integrity checks per packet instead of a > single integrity > > check. This means that parcel-capable links with MTUs as large as 64KB (or > even > > larger still) become possible, which opens the possibility for new > innovation. > > > > About middleboxes reassembling parcels, it might help if you try not to > think of them > > as routers but instead think of them as “proxys” that are performing a > function in the > > network on behalf of a host. That sort of thing happens all the time with > proxys today; > > indeed, even this email I am sending right now will be forwarded by a > proxy. > Fred, At best this would be considered a transparent proxy. The host is not sending packets to the proxy, it's that the proxy is intercepting them. IMO, transparent proxies have been the bane of the Internet. They are invasive in protocol layers that the network is not supposed to be concerned with, and host developers spend much more time trying to work around the constraints and problems with these devices than rejoicing their existence. Tom > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 9:43 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > > There are no "parcel-capable links" You are trying to invent them. You > are allowed to invent them. > > But in the absence of a physical link that can actually handle parcels > natively, I do not see any benefit in handling parcels (if needed at all) > anywhere except the hosts. > > At this point the chairs know my opinion. I will leave it to them to > conclude this adoption call and make the rough consensus decision. > > Yours, > > Joel > > On 7/12/2022 12:38 PM, Templin (US), Fred L wrote: > > Joel, > > > > The path for an IP parcel traverses parcel-capable links. Some of those > links might > > be physical links (most likely links nearest the source and links nearest > the destination) > > while others might be virtual (most likely links in between). Only > forwarding nodes on > > those kinds of virtual links would deal with parcel packaging and > repackaging, and > > there would be very few of those. Routers that connect physical > parcel-capable links > > would either forward the parcel if it is not too big or drop it and return > a PTB otherwise. > > This is very much intarea territory. > > > > Fred > > > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 9:20 AM > *To:* Templin (US), Fred L > > *Cc:* int-area@ietf.org > *Subject:* [EXTERNAL] Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > > If you document it purely as a host-to-host tunnel / shim, then it is not > even clear you need an RFC. intarea does not own all tunnels or overlays. > > But that is not what you currently have documented. You ahve documented a > mechanism wherein some routers are expected to break up parcels, and some > routers are hoped to reassemble parcels. That is what I object to. > > Yours, > > Joel > > On 7/12/2022 12:02 PM, Templin (US), Fred L wrote: > > Joel, the “shim” you are referring to is IPv6 encapsulation per RFC2473. > It forms an > > adaptation layer below IP as the network layer and above IP as the data > link layer. > > IP-in-IPv6-in-IP in other words. That seems like intarea. > > > > Fred > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com > ] > *Sent:* Tuesday, July 12, 2022 8:52 AM > *To:* Templin (US), Fred L > > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > If there are no links that can handle parcels bigger than 64K, then as a > step one deploy it o
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 8:23 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Joel, I can show you an orders-of-magnitude performance speed-up when I > send > > large blocks of data using larger segment sizes that invoke fragmentation > and > > reassembly. I can also show a significant speed-up when system calls pass > > multiple larger segments in a single system call instead of one at a time. > This > > is on real systems with real data, and not in simulations. > Fred, You are making an argument that larger segment sizes is more efficient-- yes, we know that. The argument that you really should be making is that "IP parcels" is necessary and sufficient to get those benefits and why the on-wire-protocol change is justified for the benefits. For instance, when you say "real systems with real data" are these system running IP parcels then, or is this an extrapolation using existing techniques? If it's the latter case then this really isn't very helpful in justifying IP parcels. Tom > > About links with larger MTUs, I am specifically NOT saying that we need to > wait > > until we have links with MTU>64K. What I am saying is that parcels would > pave > > the way toward evolution of links with larger MTUs than what we have in the > > current practice allowing a path forward for future innovation. But, > parcels are > > still good even for the smallish MTUs in widescale deployment today. > > > > Fred > > > > *From:* Joel Halpern [mailto:jmh.dir...@joelhalpern.com] > *Sent:* Tuesday, July 12, 2022 7:44 AM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* [EXTERNAL] Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > EXT email: be mindful of links/attachments. > > > > > Fred, I understood full well that you only envision a small number of > reassembly devices. After all, on any given path only one device will > likely reassemble. Still, that device will be spending a lot of resources > in a very expensive part of the path (fast path forwarding) to provide a > small benefit to some hosts. > > Fundamentally you are asking the archtiecture to spend those resources for > use case that you have not explained. "I have proof" i snot relevant. > Without knowing the scenarios and the assumptions, it does not help us to > judge. It is worse than the case in the early days of the MANET working > group where the competing proposal repeatedly said "my simulation shows ..." > > Fundamentally, it is not the network's job to reassemble packets for a > host. If you want NICs to do that, as Tom has said, that's fine. It is a > private matter between the host and the NIC. But you are asking for > functionality in the network. > > I note also that you are assuming that hosts have links that support > actual MTUs larger than 64K. I know of no link that has those properties > in current use. (I am vaguely familiar with HIPPI and FiberChannel. > Neither appears to be relevant.) > > Yours, > > Joel > > On 7/12/2022 10:02 AM, Templin (US), Fred L wrote: > > Joel, you are misunderstanding what nodes would be involved in reassembly; > this would > > not be at every single IP layer router in the path. It would only be at > possibly 0, 1 or 2 > > adaptation layer middleboxes in the path from source to destination. And, > then most > > likely only at a near-end middlebox very near the destination that happens > to know the > > destination would prefer to receive larger parcels. > > > > About segment size, I have proof that using segment sizes significantly > larger than the > > path MTU can often produce dramatic performance increases even when > fragmentation > > is intentionally invoked. I also have proof that packaging multiple > segments in the same > > system call can drive performance even higher an without reducing the > segment size. > > IP parcels takes it the logical next step of allowing multiple segments to > travel together > > in the same packet, which may or may not be subject to fragmentation and > reassembly. > > But, let’s not get so hung up on the middlebox question that we forget the > benefits > > for end-to-end. > > > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com ] > *Sent:* Monday, July 11, 2022 4:02 PM > *To:* Templin (US), Fred L > > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > No, intermediate reassembly is not an optimization. > > First, it is a bad idea. It is very painful for routers to perfo
Re: [Int-area] [EXTERNAL] Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 7:31 AM Robinson, Herbie < herbie.robin...@stratus.com> wrote: > 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 > data in > > >succession but still in a single pass. You spoke before of NICs adapting > to support > > >TCP jumbograms – if they can do that, why not a very straightforward > application > > >of Internet checksum? I haven’t looked at this in a long while, but isn’t > this also > > >similar to what UDP-lite did? > > > > The various hardware adapters that I am familiar with (most of Intel’s > high end line) use a fixed sized ring buffer with a fixed sized slot for > each packet received. They are already restricting the use of all features > at the same time because they don’t have enough bits in the per packet > slot. They certainly have no way to deal with reporting success or failure > of an unbounded number of checksum computations in a fixed sized slot. > Herbie, Generating multiple checksum is required for TSO and some devices implement a generic mechanism that might be extended to work with IP parcels. On the RX side, efficiently handling multiple checksums in a single packet that cover large non-overlapping portions of the packet is difficult. This can be solved if the IP parcels header has a checksum covering the whole packet so that the receiving host doesn't have to verify the checksum of each segment. But, you'd still want the checksum in each segment in that case. Tom ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Tue, Jul 12, 2022 at 7:03 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Joel, you are misunderstanding what nodes would be involved in reassembly; > this would > > not be at every single IP layer router in the path. It would only be at > possibly 0, 1 or 2 > > adaptation layer middleboxes in the path from source to destination. > Fred, The problem isn't getting this to work on every single router, it's the requirements imposed on a router even for a single use case. Reassembly is non-work conserving so that sets a memory requirement on the routers to buffer packets in reassembly. How much additional memory are routers going to need for this? Also because it's work conserving, there needs to be policies and mechanisms on how long to wait in reassembly? And as Joel alluded to, reassembly is introducing delay in the network, so how does that interact with congestion control algorithms? For instance, if a node holds a packet of flow for longer than RTT, then we'll see the source retransmitting packets not because they're lost but because the network decided to arbitrarily delay them. So there are a myriad of considerations for implementing reassembly in the network, and even with the constraints you've suggested, it is not trivial. And, then most > > likely only at a near-end middlebox very near the destination that happens > to know the > > destination would prefer to receive larger parcels. > Hosts already have all capabilities of IP reassembly and TCP reassembly for many years. This is what host stacks do, and they can do it well. Moving this functionality into the network doesn't solve any problems the host is currently facing, but would create new ones. > > > About segment size, I have proof that using segment sizes significantly > larger than the > > path MTU can often produce dramatic performance increases even when > fragmentation > > is intentionally invoked. I also have proof that packaging multiple > segments in the same > > system call can drive performance even higher an without reducing the > segment size. > Yes, but we already get those effects using GRO/GSO and now BiGTCP allows >64K operations. I don't see how IP parcels can improve upon that. > IP parcels takes it the logical next step of allowing multiple segments to > travel together > > in the same packet, which may or may not be subject to fragmentation and > reassembly. > > But, let’s not get so hung up on the middlebox question that we forget the > benefits > > for end-to-end. > The one material benefit I see is where the source network has a larger MTU than the destination network. So packets can start big and be fragmented when they enter the smaller network. This has an advantage over IP fragmentation in that if a fragment is lost the other fragments are still useful to the transport layer. As mentioned above, reassembly in the network isn't feasible, but if some tunneling is used one might be able to match the functionality so that packets going from a smaller MTU network into a larger one might be coalesced to take advantage of the larger MTU. Maybe there's some use cases in satellite communications for this? Tom > > Fred > > > > *From:* Joel Halpern [mailto:j...@joelhalpern.com] > *Sent:* Monday, July 11, 2022 4:02 PM > *To:* Templin (US), Fred L > *Cc:* int-area@ietf.org > *Subject:* Re: [Int-area] Re: Call for WG adoption of > draft-templin-intarea-parcels-10 > > > > No, intermediate reassembly is not an optimization. > > First, it is a bad idea. It is very painful for routers to perform > reassembly. They have to burn expensive resources managing such > aempted reassesmbly. It has major cost even if the router decides to > give up and forward the pieces. > > And second, unless one makes some unstated assumptions in the absence of > such reassembly the sending host will be throttled to the receiving host > rate. So the benefit of the entire system is markedly reduced. > > Net: we should not adopt this draft. > > Yours, > > Joel > > On 7/11/2022 6:41 PM, Templin (US), Fred L wrote: > > Tom, > > > > > Why would someone put six segments in a parcel if they already have a > 9K link MTU? > > > Why not just send one segment in 9K? > > > > This is the mindset that we need to overcome. We have had it drilled into > our heads > > that MSS must be the same as the path MTU, but it does not need to be that > way. > > If the MSS is smaller than the path MTU, but we can send multiple segments > in a > > single parcel that more closely approaches the size of the path MTU then > > amortization savings are possible. > > > > >The algorithm isn't the problem, it's supporting new protocols and &
Re: [Int-area] [EXTERNAL] Re: Call for WG adoption of draft-templin-intarea-parcels-10
On Mon, Jul 11, 2022 at 2:20 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Tom, some rejoinders: > > > > >Yes, I agree if the packet is fragmented by the network then this is a > nice feature. > > >However, today we already have this from a host perspective property by > just > > >sending "small" packets. > > > > It can be readily shown that some applications get much greater > performance by > > sending larger packets that trigger fragmentation/reassembly than by > sending > > smaller packets that do not. Multiple order of magnitude performance > increases > > are indeed possible. > > > > >I'm not sure the savings qualify as significant. 9K MTUs are becoming > common in data centers > > >and the standard TCP/IPv6 header is 80 bytes so that's already less than > 1% overhead. > > > > I think 9K is only a starting point, and IP parcels pave the way to much > larger link MTUs, > > possibly even in excess of 64KB. And, doing the math, even for just a 9K > link sending a > > single parcel that contains 6x 1440 octet segments would save 5 * 60 == > 300 octets in > Why would someone put six segments in a parcel if they already have a 9K link MTU? Why not just send one segment in 9K? > comparison with sending 6x 1500 octet packets with 60 octets of IP/TCP > headers per > > packet. For links with larger MTUs, the savings for sending parcels with > lots of segments > > (up to 64) becomes even greater. > > > >As I already mentioned, this is addressed by the BiGTCP work ( > https://lwn.net/Articles/884104). > > >Sending or receiving multi-megabytes TCP segments in one system call is > now feasible. Also, it's > > >inevitable that NIC vendors will apply this also to be able to offload > TCP jumbo grams. Given this > > >is just software that doesn't require hardware change or on-the-wire > protocols to change, it's > > >immediately deployable with just a softwar change which is a huge benefit > to datacenter operators. > > > > As I have said, IP parcels has the same advantage within the host > system-call (user-space > > to kernel-space) context. But, IP parcels goes a step further to provide > efficient packaging > > over-the-wire, whereas the approach you are referring to opens the box > inside the > > kernel and sends individual packets instead of aggregates. > > > >All modern NIC HW can deal with offloading a single checksum per packet, > it's going to be > > >a major effort for them to offload multiple checksum like IP parcels > needs. Without checksum > > >offload, this would be a non-starter for a lot of deployments. > > > > Check the latest spec (now at -12 and likely to stay that way until > IETF114. Any H/W checksum > > that can run over the first segment of a packet should be possible to make > run over the N-1 > > additional segments of the same packet (parcel) by applying the very > familiar Internet > > checksum algorithm. > The algorithm isn't the problem, it's supporting new protocols and multiple checksums in a packet in hardware. > > > >I'm not convinced of that. For instance, I'm skeptical that intermediate > devices trying to reassemble > > >packets that aren't addressed to themselves could ever be robust or > efficient (i.e. complexity, non-work > > >conserving resource requirements, security issues with reassembly, > multi-path that causes latency > > >increase, potential DoS vector, etc.). Can you comment on this? > > > > Perhaps what is confusing this matter is that the intermediate devices > referred to > > here most certainly do not refer to all routers in the path. Instead, what > is intended > > here is an OMNI intermediate device, of which there may be something on > the order > > of 0, 1, or 2 of them on the path between the OMNI source and destination > even > > though there may be many 10’s or even 100’s of ordinary IP routers on the > path. > > And, again, this is not a strict reassembly case – instead, it is an > opportunistic > > “combine if convenient; else forward” swift decision. > Either you're trivializing reassembly or maybe you're thinking of some new method that somehow avoids all the pitfalls and problems we've had with reassembly over the years! Consider that many NIC vendors have tried, and largely failed, to get any sort of device reassembly widely deployed (e.g. IP reassembly, TCP segmentation reassembly, etc.). The reason they failed is because they can't give the host stack transparency and control over the reassembly process. In its nature reassembly ca
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Mon, Jul 11, 2022 at 12:22 PM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Richard and others, thank you for these comments and for the ensuing
> discussion that
>
> took place over the time I was away on vacation. Strange how the timing
> hit when I
>
> was away from the office and off the grid - I was on a camping trip in
> Canada not far
>
> from where Steve Deering lives although I did not visit him.
>
>
>
> In any event, I was able to push out a new draft version ahead of the
> deadline that
>
> may address some (but likely not all) of your concerns:
>
>
>
> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
>
>
>
> The major change is that the draft now talks about interactions with upper
> layer
>
> protocols including TCP and UDP, whereas the previous draft versions were
> silent
>
> regarding upper layer protocol framing.
>
>
>
> To others who have commented, I beg to differ and maintain that IP parcels
> do
>
> represent a significant improvement over the current state of affairs and
> over
>
> just regular IP jumbograms. In particular:
>
Hi Fred, some comments in line.
>
>
> 1) IP parcels make it so that the loss unit is a single segment instead of
> the entire
>
> packet/parcel, and loss of a segment often results in retransmission of
> just that
>
> segment instead of the entire packet/parcel.
>
Yes, I agree if the packet is fragmented by the network then this is a nice
feature. However, today we already have this from a host perspective
property by just sending "small" packets.
>
>
> 2) IP parcels are more efficient than sending a single segment per IP
> packet, since
>
> the parcel includes a single IP header plus single full {TCP,UDP} header
> for possibly
>
> many segments. This can result in significant savings in terms of bits
> over the wire
>
> for omitting unnecessary header bytes.
>
I'm not sure the savings qualify as significant. 9K MTUs are becoming
common in data centers and the standard TCP/IPv6 header is 80 bytes so
that's already less than 1% overhead.
> Consider the postal service analogy; when
>
> many items can be sent together in a single package/parcel there is a
> large savings
>
> in shippeing and handling costs than when each individual item is shipped
> separately.
>
As I already mentioned, this is addressed by the BiGTCP work (
https://lwn.net/Articles/884104). Sending or receiving multi-megabytes TCP
segments in one system call is now feasible. Also, it's inevitable that NIC
vendors will apply this also to be able to offload TCP jumbo grams. Given
this is just software that doesn't require hardware change or on-the-wire
protocols to change, it's immediately deployable with just a softwar change
which is a huge benefit to datacenter operators.
>
>
> 3) IP parcels improve large packet integrity by including a separate
> checksum for
>
> each segment instead of a single checksum for the entire packet.
>
All modern NIC HW can deal with offloading a single checksum per packet,
it's going to be a major effort for them to offload multiple checksum like
IP parcels needs. Without checksum offload, this would be a non-starter for
a lot of deployments.
This means that
>
> large parcels (up to a few MB) can be sent in one piece over links with
> sufficiently
>
> large MTU without requiring the link itself to provide strong integrity
> checks over
>
> the entire length of the parcel. This means that link MTUs significantly
> larger than
>
> 9KB are now safely possible.
>
>
>
> 4) IP parcels offer all of the efficiency advantages to upper layers as
> are offered
>
> by GSO/GRO, etc. but also provide benefits 1) through 3) above that are not
>
> offered by GSO/GRO.
>
Most of this is doable in GSO/GRO.
>
>
> 5) Plus, the idea is just plain neat. Better packaging is good. More
> efficient
>
> handling is good. Reduced header overhead is good. SAFE larger MTUs are
>
> good. The idea itself is good.
>
I'm not convinced of that. For instance, I'm skeptical that intermediate
devices trying to reassemble packets that aren't addressed to themselves
could ever be robust or efficient (i.e. complexity, non-work conserving
resource requirements, security issues with reassembly, multi-path that
causes latency increase, potential DoS vector, etc.). Can you comment on
this?
Tom
>
> Fred
>
>
>
> *From:* Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Richard
> Li
> *Sent:* Friday, July 01, 2022 3:11 PM
> *To:* Juan Carlos Zuniga (juzuniga)
> *Cc:* int-area@ietf.org
> *Subject:* Re: [Int-area] Call for WG adoption of
> draft-templin-intarea-parcels-10
>
&g
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Sun, Jul 3, 2022, 2:56 PM Gyan Mishra wrote: > > Hi Tom > > Thanks for the info on Big TCP and jumbo grams use case testing. From > that link It does sound like increased performance numbers going to jumbo > grams with the example 185,000 byte payload yielded 50% increase in > throughout. > > Doing the math compared to 9216 byte packet which is used today commonly > on servers and comparing to use case of 185,000 MTU. > > 185,000/9216 = 20 packets > > IPv6 + TCP + Ethernet headers overhead = 78 bytes > (L2 MTU worst case - L3 MTU would be 60) > > 78 bytes x 20 = 1565 bytes saved being transmitted over the wire > > 185,000 bytes over 10G link .148 ms > > 9216+ 78 x 20 packets = 185,880 bytes over 10G link - .1487 ms > > From my calculations please check my math but the performance gains is > negligible almost nill with jumbo grams > > I think if you compare 1500 to jumbo grams their is significant gains in > performance, however to be accurate you have to compare to what is used > today in production DC servers which is 9216. > > Please correct me if I am wrong in my calculations but I don’t see any > performance gains going from 9216 used on DC server today to using Jumbo > grams. > Hi, Gyan, Generally, I agree there are diminishing returns as MTU increases if you are just considering the packet processing overhead. However, there are potentially other benefits to a larger MTU. For instance, Google moved to 9K MTUs because that allows them to send two 4K pages in a packet that can easily be page flipped to user space addresses thereby achieving a very efficient form of zero copy. Using jumbograms could conceivably allow even larger even larger pages to be conveyed over the network (e.g. huge pages in LInux are 2M). Since this is a host side technique, it's not necessary for the network to support larger MTUs as the NIC can perform receive segmentation offload to give the host larger packets. RFC2675 is a win here because we can use a standard format to represent these jumbo packets that might be created locally on receive (as opposed to using some npn-standard custom OS API). Tom > Thanks > > Gyan > > On Sun, Jul 3, 2022 at 2:52 PM Tom Herbert wrote: > >> >> >> On Sat, Jul 2, 2022, 9:26 PM Gyan Mishra wrote: >> >>> >>> I reviewed the draft and don’t support WG adoption. >>> >>> Main reason as stated by others is the minimal gain from super jumbo >>> greater then 9000 bytes is supported today of which most router / switch >>> vendors for example Cisco supports maximum 9216 MTU and Juniper supports >>> 16000 MTU. Most all hosts Windows, MAC and Linux support up to 9216 MTU. >>> >>> Servers for 5G MEC Multi Access Edge Compute on the wireless RAN Radio >>> network X-Haul are now closer to the user’s 100G connected servers for >>> network slice services being instantiated at ultra low latency microseconds >>> as well as MSDC (Massively Scalable Data Centers) 100G connected servers >>> and ultra low latency all using super Jumbo set to 9000+ MTU. >>> >>> Keeping in mind that MPLS, IPSEC, NVO overlays must be taken into >>> account, the super jumbo server MTU must be less then the network underlay >>> or overlay MTU so let’s say set to a maximum maximum of 9116 for Cisco for >>> now being the lowest common denominator in a network with Cisco and Juniper >>> routers. >>> >>> At this time Transport networks with OTNGN DWDM packet or TDM over >>> IP/MPLS a single wavelength can be 400G and now soon to be 800G standard >>> per wavelength. >>> >>> At the current network speeds on the core and transport side given the >>> higher bandwidths we are still at super jumbo which > 9000 and no vendor is >>> close to 64k - 65535 which is the maximum super jumbo size. >>> >>> Jumbo grams RFC 2675 as discussed in the draft is > 64k to 4.2B. >>> >>> We are well off from a network technology point of view coming anywhere >>> close to use of Jumbo grams RFC 2675. >>> >>> Until we get close to the maximum MTU of Super Jumbo and we still feel >>> we need larger buffers for better performance would this draft be even >>> remotely a possibility. >>> >>> Also the big issue here is if you do the math you do get tremendous >>> gains in throughout and performance from 1500 byte to jumbo to then super >>> jumbo up to 9216. The performance gains are not there to even go to the >>> maximum of super jumbo 64k which has not happened and more then likely will >>> never happen. >>> >
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
On Sat, Jul 2, 2022, 9:26 PM Gyan Mishra wrote: > > I reviewed the draft and don’t support WG adoption. > > Main reason as stated by others is the minimal gain from super jumbo > greater then 9000 bytes is supported today of which most router / switch > vendors for example Cisco supports maximum 9216 MTU and Juniper supports > 16000 MTU. Most all hosts Windows, MAC and Linux support up to 9216 MTU. > > Servers for 5G MEC Multi Access Edge Compute on the wireless RAN Radio > network X-Haul are now closer to the user’s 100G connected servers for > network slice services being instantiated at ultra low latency microseconds > as well as MSDC (Massively Scalable Data Centers) 100G connected servers > and ultra low latency all using super Jumbo set to 9000+ MTU. > > Keeping in mind that MPLS, IPSEC, NVO overlays must be taken into account, > the super jumbo server MTU must be less then the network underlay or > overlay MTU so let’s say set to a maximum maximum of 9116 for Cisco for > now being the lowest common denominator in a network with Cisco and Juniper > routers. > > At this time Transport networks with OTNGN DWDM packet or TDM over IP/MPLS > a single wavelength can be 400G and now soon to be 800G standard per > wavelength. > > At the current network speeds on the core and transport side given the > higher bandwidths we are still at super jumbo which > 9000 and no vendor is > close to 64k - 65535 which is the maximum super jumbo size. > > Jumbo grams RFC 2675 as discussed in the draft is > 64k to 4.2B. > > We are well off from a network technology point of view coming anywhere > close to use of Jumbo grams RFC 2675. > > Until we get close to the maximum MTU of Super Jumbo and we still feel we > need larger buffers for better performance would this draft be even > remotely a possibility. > > Also the big issue here is if you do the math you do get tremendous gains > in throughout and performance from 1500 byte to jumbo to then super jumbo > up to 9216. The performance gains are not there to even go to the maximum > of super jumbo 64k which has not happened and more then likely will never > happen. > > However the cost of extra buffers on server NIC and router hardware proves > that the performance gains are nominal and it’s not worth the investment by > router and server vendors to ever support more then what is supported today > which is 9216 on servers and what Cisco supports today. > > So bottom line is RFC 2675 would never come to fruition and should really > be deprecated or made obsolete. > Gyan, Please take a look at the reference I provided to the work to make GRO/GSO jumbo grams. Routers are not the only devices that can make productive use of RFC2674, hosts can use it as shown in the example. So IMO, there's no need to deprecate the protocol as it is useful. Tom > I believe this was discussed on 6MAN. > > Kind Regards > > Gyan > > On Sat, Jul 2, 2022 at 11:12 AM Bob Hinden wrote: > >> Hi, >> >> I agree with the other comments that this shouldn’t be adopted at this >> point. >> >> Another point is that what I understand this is proposing would appear to >> have non-trivial effect on current transport protocols, as it will add >> delay to create the “parcels”. I don’t see this issue discussed in the >> draft, other than pointing to some other perhaps similar work. >> >> Bob >> >> >> > On Jul 1, 2022, at 5:17 PM, Tommy Pauly > 40apple@dmarc.ietf.org> wrote: >> > >> > I agree with the points being raised by Tom and Joel. I don’t think >> this is something intarea should adopt at this point. If there’s going to >> be further discussion on this, I’d want to see more explanation of who >> would intend to support and deploy this solution to the problem. >> > >> > If this is a matter of sending fewer packets over a particular link of >> the network, the use of a proxy or tunnel between hosts may equally well >> solve the problem without needing to make changes at this layer. >> > >> > Thanks, >> > Tommy >> > >> >> On Jul 1, 2022, at 5:06 PM, Tom Herbert wrote: >> >> >> >> At this point, I don't see IP parcels as being a significant benefit >> to host performance which, as I understand it, is the primary motivation. >> While it's an interesting idea, I don't support adoption. >> >> >> >> A recent patch to the Linux kernel allows for GSO/GRO segments greater >> than 64K, using RFC2675 Jumbograms to reassemble so those limitations which >> were discussed on the list have been addressed in implementation. There is >> a ni
Re: [Int-area] Call for WG adoption of draft-templin-intarea-parcels-10
At this point, I don't see IP parcels as being a significant benefit to host performance which, as I understand it, is the primary motivation. While it's an interesting idea, I don't support adoption. A recent patch to the Linux kernel allows for GSO/GRO segments greater than 64K, using RFC2675 Jumbograms to reassemble so those limitations which were discussed on the list have been addressed in implementation. There is a nice writeup in https://lwn.net/Articles/884104/. As Joel mentions moving any sort of reassembly into network devices is complex and problematic. For instance, if a middebox is trying to perform reassembly of packets for a flow not addressed to it, it's implicitly requiring that all packets of the flow that go through the device perform reassembly which is contrary to the end-to-end model. Also, if reassembly requires buffering of messages then that creates a memory requirement on middleboxes; hosts are in a better position to do reassembly since they are only providing the service for themselves as opposed to some number of devices behind a middlebox. Tom On Wed, Jun 22, 2022 at 12:25 PM Juan Carlos Zuniga (juzuniga) wrote: > Dear IntArea WG, > > > > We are starting a 2-week call for adoption of the IP-Parcels draft: > > https://www.ietf.org/archive/id/draft-templin-intarea-parcels-10.html > > > > The document has been discussed for some time and it has received multiple > comments. > > > > If you have an opinion on whether this document should be adopted by the > IntArea WG please indicate it on the list by the end of Wednesday July 6th > . > > > > Thanks, > > > > Juan-Carlos & Wassim > > (IntArea WG chairs) > > > ___ > 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
Re: [Int-area] YANG was Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic
From: Int-area on behalf of Michael Sweet
Sent: 07 April 2022 15:11
Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure
domains to historic
Michael
I am well familiar with the work of IPP in the IETF. You mention MIBs which I
know of. Is there anything similar in YANG?
Tom Petch
Toerless,
> On Apr 7, 2022, at 5:38 AM, Toerless Eckert wrote:
> ...
> 2.) RFC1528 from Experimental to Historic
>
> I am not aware of a better, interoperable standard solution for remote
> printing (or should
> i say Internet FAX ?). Instead it feels to me as if every printer vendor has
> started
> its own proprietary remote-printing cloud-service. I hope i am wrong
> (pointers please),
> but if not, then i fear this decade old experiment is still the best we have ?
I don't know if this was meant as serious? But FWIW the IETF published the
Internet Printing Protocol (STD 92) more than 2 decades ago, and it is used by
nearly every network printer ("billions of printers") and most "cloud" printing
services (including Microsoft's Azure-based Universal Print Service). Any
printer with "AirPrint", "IPP Everywhere", "Mopria", or "Wi-Fi Direct" on the
box supports IPP.
The Printer Working Group (who is the current steward of IPP and the variable
SNMP printing MIBs) has also defined numerous IPP extensions, including
standards for cloud printing and Internet fax using a streamable subset of PDF.
So, assuming somebody doesn't just email you a file you can print it quite
easily using a single, standard protocol.
[But of course telephone-based fax still hasn't died - boggles the mind...]
Michael Sweet
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IP Parcels improves performance for end systems
On Thu, Mar 24, 2022, 3:11 PM Joel M. Halpern wrote: > I do remember token ring. (I was working from 1983 for folks who > delivered 50 megabits starting in 1976, and built some of the best FDDI > around at the time.) > > I am not claiming that increasing the MTU from 1500 to 9K did nothing. > I am claiming that diminishing returns has distinctly set in. > If the Data Center folks (who tend these days to have the highest > demand) really want a 64K link, they would have one. Joel, Indeed. Google, at least, is looking into it at least insofar as getting bigger packets for GRO/GSO. See https://netdevconf.info/0x15/session.html?BIG-TCP Tom They don't. They > prefer to use Ethernet. > The improvement via increasing the MTU further runs into many obstacles, > including such issues as error detection code coverage), application > desired communication size, retransmission costs, and on and on. > Yes, they can all be overcome. But the returns get smaller and smaller. > > So absent real evidence that there is a problem needing the network > stack and protocol to change, I just don't see this (IP Parcels) as > providing enough benefit to justify the work. > > > Yours, > Joel > > On 3/24/2022 3:05 PM, Templin (US), Fred L wrote: > > Hi Joel, > > > >> -Original Message- > >> From: Joel M. Halpern [mailto:j...@joelhalpern.com] > >> Sent: Thursday, March 24, 2022 11:41 AM > >> To: Templin (US), Fred L > >> Cc: int-area > >> Subject: Re: [Int-area] IP Parcels improves performance for end systems > >> > >> This exchange seems to assume facts not in evidence. > > > > It is a fact that back in the 1980's the architects took simple token > ring, > > changed the over-the-wire coding to 4B/5B, replaced the copper with > > fiber and then boosted the MTU by a factor of 3 and called it FDDI. They > > were able to claim what at the time was an astounding 100Mbps (i.e., in > > comparison to the 10Mbps Ethernet of the day), but the performance > > gain was largely due to the increase in the MTU. They told me: "Fred, > > go figure out the path MTU problem", and they said: "go talk to Jeff > > Mogul out in Palo Alto who knows something about it". But, then, the > > Path MTU discovery group took a left turn at Albuquerque and left the > > Internet as a tiny MTU wasteland. We have the opportunity to fix all > > of that now - so, let's get it right for once. > > > > Fred > > > > > >> > >> And the whole premise is spending resources in other parts of the > >> network for a marginal diminishing return in the hosts. > >> > >> It simply does not add up. > >> > >> Yours, > >> Joel > >> > >> On 3/24/2022 2:19 PM, Templin (US), Fred L wrote: > >>>> The category 1) links are not yet in existence, but once parcels > start to > >>>> enter the mainstream innovation will drive the creation of new kinds > of > >>>> data links (1TB Ethernet?) that will be rolled out as new hardware. > >>> > >>> I want to put a gold star next to the above. AFAICT, pushing the MTU > and > >>> implementing IP parcels can get us to 1TB Ethernet practically > overnight. > >>> Back in the 1980's, FDDI proved that pushing to larger MTUs could boost > >>> throughput without changing the speed of light, so why wouldn't the > same > >>> concept work for Ethernet in the modern era? > >>> > >>> Fred > >>> > >>>> -Original Message- > >>>> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of > Templin (US), Fred L > >>>> Sent: Thursday, March 24, 2022 9:45 AM > >>>> To: Tom Herbert > >>>> Cc: int-area ; Eggert, Lars ; > l...@eggert.org > >>>> Subject: Re: [Int-area] IP Parcels improves performance for end > systems > >>>> > >>>> Hi Tom - responses below: > >>>> > >>>>> -Original Message- > >>>>> From: Tom Herbert [mailto:t...@herbertland.com] > >>>>> Sent: Thursday, March 24, 2022 9:09 AM > >>>>> To: Templin (US), Fred L > >>>>> Cc: Eggert, Lars ; int-area ; > l...@eggert.org > >>>>> Subject: Re: [Int-area] IP Parcels improves performance for end > systems > >>>>> > >>>>> On Thu, Mar 24, 2022 at 7:27 AM Templin (US), Fred L > >>>>> wrote: > >>>>>> > >>>>
Re: [Int-area] [EXTERNAL] Re: IP Parcels improves performance for end systems
On Thu, Mar 24, 2022 at 7:27 AM Templin (US), Fred L wrote: > > Tom - see below: > > > -Original Message----- > > From: Tom Herbert [mailto:t...@herbertland.com] > > Sent: Thursday, March 24, 2022 6:22 AM > > To: Templin (US), Fred L > > Cc: Eggert, Lars ; int-area ; > > l...@eggert.org > > Subject: Re: [Int-area] IP Parcels improves performance for end systems > > > > On Wed, Mar 23, 2022 at 10:47 AM Templin (US), Fred L > > wrote: > > > > > > Tom, looks like you have switched over to HTML which can be a real > > > conversation-killer. > > > > > > But, to some points you raised that require a response: > > > > > > >You can't turn it off UDP checksums for IPv6 (except for narrow case of > > > >encapsulation). > > > > > > > > > > > > That sounds like a good reason to continue to use IPv4 – at least as far > > > as end system > > > > > > addressing is concerned – right? > > > > > > Not at all. All NICs today provide checksum offload and so it's > > basically zero cost to perform the UDP checksum. The fact that we > > don't have to do extra checks on the UDPv6 checksum field to see if > > it's zero actually is a performance improvement over UDPv4. (btw, I > > will present implementation of the Internet checksum at TSVGWG Friday, > > this will include discussion of checksum offloads). > > Actually, my assertion wasn't good to begin with because for IPv6 even if UDP > checksums are turned off the OMNI encapsulation layer includes a checksum > that ensures the integrity of the IPv6 header. UDP checksums off for IPv6 when > OMNI encapsulation is used is perfectly fine. > I assume you are referring to RFC6935 and RFC6936 that allow the UDPv6 to be zero for tunneling with a very constrained set of conditions. > > > >If it's a standard per packet Internet checksum then a lot of HW could > > > >do it. If it's something like CRC32 then probably not. > > > > > > > > > > > > The integrity check is covered in RFC5327, and I honestly haven’t had a > > > chance to > > > > > > look at that myself yet. > > > > > > > > > > > > >LTP is a nice experiment, but I'm more interested as to the interaction > > > >between IP parcels and TCP or QUIC. > > > > > > > > > > > > Please be aware that while LTP may seem obscure at the moment that may be > > > changing now > > > > > > that the core DTN standards have been published. As DTN use becomes more > > > widespread I > > > > > > think we can see LTP also come into wider adoption. > > > > > > My assumption is that IP parcels is intended to be a general solution > > of all protocols. Maybe in the next draft you could discuss the > > details of TCP in IP parcels including how to offload the TCP > > checksum. > > I could certainly add that. For TCP, each of the concatenated segments would > include its own TCP header with checksum field included. Any hardware that > knows the structure of an IP Parcel can then simply do the TCP checksum > offload function for each segment. To be honest, the odds of ever getting support in NIC hardware for IP parcels are extremely slim. Hardware vendors are driven by economics, so the only way they would do that would be to demonstrate widespread deployment of the protocol. But even then, with all the legacy hardware in deployment it will take many years before there's any appreciable traction. IMO, the better approach is to figure out how to leverage the existing hardware features for use with IP parcels. > > > > >There was quite a bit of work and discussion on this in Linux. I believe > > > >the deviation from the standard was motivated by some > > > > > > >deployed devices required the IPID be set on receive, and setting IPID > > > >with DF equals to 1 is thought to be innocuous. You may > > > > > > >want to look at Alex Duyck's papers on UDP GSO, he wrote a lot of code > > > >in this area. > > > > > > > > > > > > RFC6864 has quite a bit to say about coding IP ID with DF=1 – mostly in > > > the negative. > > > > > > But, what I have seen in the linux code seems to indicate that there is > > > not even any > > > > > > coordination between the GSO source and the GRO destination – instead, > > > GRO simply > > > > > > starts gluing together packets that appear to have consecutiv
Re: [Int-area] IP Parcels improves performance for end systems
On Wed, Mar 23, 2022 at 10:47 AM Templin (US), Fred L wrote: > > Tom, looks like you have switched over to HTML which can be a real > conversation-killer. > > But, to some points you raised that require a response: > > >You can't turn it off UDP checksums for IPv6 (except for narrow case of > >encapsulation). > > > > That sounds like a good reason to continue to use IPv4 – at least as far as > end system > > addressing is concerned – right? Not at all. All NICs today provide checksum offload and so it's basically zero cost to perform the UDP checksum. The fact that we don't have to do extra checks on the UDPv6 checksum field to see if it's zero actually is a performance improvement over UDPv4. (btw, I will present implementation of the Internet checksum at TSVGWG Friday, this will include discussion of checksum offloads). > > > > >If it's a standard per packet Internet checksum then a lot of HW could do > >it. If it's something like CRC32 then probably not. > > > > The integrity check is covered in RFC5327, and I honestly haven’t had a > chance to > > look at that myself yet. > > > > >LTP is a nice experiment, but I'm more interested as to the interaction > >between IP parcels and TCP or QUIC. > > > > Please be aware that while LTP may seem obscure at the moment that may be > changing now > > that the core DTN standards have been published. As DTN use becomes more > widespread I > > think we can see LTP also come into wider adoption. My assumption is that IP parcels is intended to be a general solution of all protocols. Maybe in the next draft you could discuss the details of TCP in IP parcels including how to offload the TCP checksum. > > > >There was quite a bit of work and discussion on this in Linux. I believe the > >deviation from the standard was motivated by some > > >deployed devices required the IPID be set on receive, and setting IPID with > >DF equals to 1 is thought to be innocuous. You may > > >want to look at Alex Duyck's papers on UDP GSO, he wrote a lot of code in > >this area. > > > > RFC6864 has quite a bit to say about coding IP ID with DF=1 – mostly in the > negative. > > But, what I have seen in the linux code seems to indicate that there is not > even any > > coordination between the GSO source and the GRO destination – instead, GRO > simply > > starts gluing together packets that appear to have consecutive IP IDs without > ever first > > checking that they were sent by a peer that was earnestly doing GSO. These > aspects > > would make it very difficult to work GSO/GRO into an IETF standard, plus it > doesn’t > > work for IPv6 at all where there is no IP ID included by default. IP Parcels > addresses > > all of these points, and can be made into a standard. Huh? GRO/GSO works perfectly fine with IPV6. Tom > > > Fred > > > > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Wednesday, March 23, 2022 9:37 AM > To: Templin (US), Fred L > Cc: Eggert, Lars ; int-area ; > l...@eggert.org > Subject: Re: [EXTERNAL] Re: [Int-area] IP Parcels improves performance for > end systems > > > > EXT email: be mindful of links/attachments. > > > > > > > On Wed, Mar 23, 2022, 9:54 AM Templin (US), Fred L > wrote: > > Hi Tom, > > > -Original Message- > > From: Tom Herbert [mailto:t...@herbertland.com] > > Sent: Wednesday, March 23, 2022 6:19 AM > > To: Templin (US), Fred L > > Cc: Eggert, Lars ; int-area@ietf.org; l...@eggert.org > > Subject: Re: [Int-area] IP Parcels improves performance for end systems > > > > On Tue, Mar 22, 2022 at 10:38 AM Templin (US), Fred L > > wrote: > > > > > > Tom, see below: > > > > > > > -Original Message- > > > > From: Tom Herbert [mailto:t...@herbertland.com] > > > > Sent: Tuesday, March 22, 2022 10:00 AM > > > > To: Templin (US), Fred L > > > > Cc: Eggert, Lars ; int-area@ietf.org > > > > Subject: Re: [Int-area] IP Parcels improves performance for end systems > > > > > > > > On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L > > > > wrote: > > > > > > > > > > Lars, I did a poor job of answering your question. One of the most > > > > > important aspects of > > > > > > > > > > IP Parcels in relation to TSO and GSO/GRO is that transports get to > > > > > use a full 4MB buffer > > > > > > > > > > instead of the 64KB limit in current practices. This is possibl
Re: [Int-area] [EXTERNAL] Re: IP Parcels improves performance for end systems
On Wed, Mar 23, 2022, 9:54 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Hi Tom, > > > -Original Message- > > From: Tom Herbert [mailto:t...@herbertland.com] > > Sent: Wednesday, March 23, 2022 6:19 AM > > To: Templin (US), Fred L > > Cc: Eggert, Lars ; int-area@ietf.org; l...@eggert.org > > Subject: Re: [Int-area] IP Parcels improves performance for end systems > > > > On Tue, Mar 22, 2022 at 10:38 AM Templin (US), Fred L > > wrote: > > > > > > Tom, see below: > > > > > > > -Original Message- > > > > From: Tom Herbert [mailto:t...@herbertland.com] > > > > Sent: Tuesday, March 22, 2022 10:00 AM > > > > To: Templin (US), Fred L > > > > Cc: Eggert, Lars ; int-area@ietf.org > > > > Subject: Re: [Int-area] IP Parcels improves performance for end > systems > > > > > > > > On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L > > > > wrote: > > > > > > > > > > Lars, I did a poor job of answering your question. One of the most > important aspects of > > > > > > > > > > IP Parcels in relation to TSO and GSO/GRO is that transports get > to use a full 4MB buffer > > > > > > > > > > instead of the 64KB limit in current practices. This is possible > due to the IP Parcel jumbo > > > > > > > > > > payload option encapsulation which provides a 32-bit length field > instead of just a 16-bit. > > > > > > > > > > By allowing the transport to present the IP layer with a buffer of > up to 4MB, it reduces > > > > > > > > > > the overhead, minimizes system calls and interrupts, etc. > > > > > > > > > > > > > > > > > > > > So, yes, IP Parcels is very much about improving the performance > for end systems in > > > > > > > > > > comparison with current practice (GSO/GRO and TSO). > > > > > > > > Hi Fred, > > > > > > > > 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 that IP parcels requires new protocol that would > > > > need to be implemented on both endpoints and possibly in some > routers. > > > > > > It is not entirely true that the protocol needs to be implemented on > both > > > endpoints . Sources that send IP Parcels send them into a > Parcel-capable path > > > which ends at either the final destination or a router for which the > next hop is > > > not Parcel-capable. If the Parcel-capable path extends all the way to > the final > > > destination, then the Parcel is delivered to the destination which > knows how > > > to deal with it. If the Parcel-capable path ends at a router somewhere > in the > > > middle, the router opens the Parcel and sends each enclosed segment as > an > > > independent IP packet. The final destination is then free to apply GRO > to the > > > incoming IP packets even if it does not understand Parcels. > > > > > > IP Parcels is about efficient shipping and handling just like the > major online > > > retailer service model I described during the talk. The goal is to > deliver the > > > fewest and largest possible parcels to the final destination rather > than > > > delivering lots of small IP packets. It is good for the network and > good for > > > the end systems both. If this were not true, then Amazon would send the > > > consumer 50 small boxes with 1 item each instead of 1 larger box with > all > > > 50 items inside. And, we all know what they would choose to do. > > > > > > > Do you have data that shows the benefits of IP Parcels in light of > > > > these requirements? > > > > > > I have data that shows that GSO/GRO is good for packaging sizes up to > 64KB > > > even if the enclosed segments will require IP fragmentation upon > transmission. > > > The data implies that even larger packaging sizes (up to a maximum of > 4MB) > > > would be better still. > > > > > > > Fred, > > > > You seem to be only looking at the problem from a per packet cost > > point of view. There is also per
Re: [Int-area] IP Parcels improves performance for end systems
On Tue, Mar 22, 2022 at 10:38 AM Templin (US), Fred L wrote: > > Tom, see below: > > > -Original Message----- > > From: Tom Herbert [mailto:t...@herbertland.com] > > Sent: Tuesday, March 22, 2022 10:00 AM > > To: Templin (US), Fred L > > Cc: Eggert, Lars ; int-area@ietf.org > > Subject: Re: [Int-area] IP Parcels improves performance for end systems > > > > On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L > > wrote: > > > > > > Lars, I did a poor job of answering your question. One of the most > > > important aspects of > > > > > > IP Parcels in relation to TSO and GSO/GRO is that transports get to use a > > > full 4MB buffer > > > > > > instead of the 64KB limit in current practices. This is possible due to > > > the IP Parcel jumbo > > > > > > payload option encapsulation which provides a 32-bit length field instead > > > of just a 16-bit. > > > > > > By allowing the transport to present the IP layer with a buffer of up to > > > 4MB, it reduces > > > > > > the overhead, minimizes system calls and interrupts, etc. > > > > > > > > > > > > So, yes, IP Parcels is very much about improving the performance for end > > > systems in > > > > > > comparison with current practice (GSO/GRO and TSO). > > > > Hi Fred, > > > > 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 that IP parcels requires new protocol that would > > need to be implemented on both endpoints and possibly in some routers. > > It is not entirely true that the protocol needs to be implemented on both > endpoints . Sources that send IP Parcels send them into a Parcel-capable path > which ends at either the final destination or a router for which the next hop > is > not Parcel-capable. If the Parcel-capable path extends all the way to the > final > destination, then the Parcel is delivered to the destination which knows how > to deal with it. If the Parcel-capable path ends at a router somewhere in the > middle, the router opens the Parcel and sends each enclosed segment as an > independent IP packet. The final destination is then free to apply GRO to the > incoming IP packets even if it does not understand Parcels. > > IP Parcels is about efficient shipping and handling just like the major online > retailer service model I described during the talk. The goal is to deliver the > fewest and largest possible parcels to the final destination rather than > delivering lots of small IP packets. It is good for the network and good for > the end systems both. If this were not true, then Amazon would send the > consumer 50 small boxes with 1 item each instead of 1 larger box with all > 50 items inside. And, we all know what they would choose to do. > > > Do you have data that shows the benefits of IP Parcels in light of > > these requirements? > > I have data that shows that GSO/GRO is good for packaging sizes up to 64KB > even if the enclosed segments will require IP fragmentation upon transmission. > The data implies that even larger packaging sizes (up to a maximum of 4MB) > would be better still. > Fred, You seem to be only looking at the problem from a per packet cost point of view. There is also per byte cost, particularly in the computation of the TCP/UDP checksum. The cost is hidden in modern implementations by checksum offload, and for segmentation offload we have methods to preserve the utility of checksum offload. IP parcels will have to also leverage checksum offload, because if the checksum is not offloaded then the cost of computing the payload checksum in CPU would dwarf any benefits we'd get by using segments larger than 64K. Tom > Fred > > > Thanks, > > Tom > > > > > > > > > > > > > > Thanks - Fred > > > > > > ___ > > > 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
Re: [Int-area] [EXTERNAL] Re: IP Parcels improves performance for end systems
On Tue, Mar 22, 2022 at 10:40 AM Robinson, Herbie wrote: > > > 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 that IP parcels requires new protocol that would > > need to be implemented on both endpoints and possibly in some routers. > > Do you have data that shows the benefits of IP Parcels in light of > > these requirements? > > The various segmentation offload optimizations done by NICs have a number of > drawbacks that the parcel scheme does not have: > > 1. They are still limited to 65K bytes. That's true, however we do start to get diminishing returns above 64K (this is why I asked for real data, the existing offloads have already solved the bulk of the problem AFAICT). The primary problem with these optimizations is that they are opportunistic. e.g. we can only send >64K on a TCP connection if that's available CWND. In the worst case, e.g. TCP is in slow start, then we may only bei sending a few segments so such optimizations don't help and can actually hurt if those deploying these optimization under provision for the worst case that the optimizations can't be used. > 2. The number of streams that can be optimized are significantly limited by > memory in the NIC and usually by the size of the receive queue. In other > words, it words some of the time, but not all of the time. I don't see how IP parcels are any different in this regard, it would similarly be reassembling segments into larger segments which requires memory if the NIC is doing it. There might be an argument that this is standard means to perform intelligent fragmentation, but again that needs to be measured against the complexity and feasibility of deploying a new on the wire protocol. > 3. The NIC is responsible for checksum computation and validation. If one > is operating in a fault tolerant environment, one wants the checksum > computation/checking done in the fault tolerant domain (i.e., the host, not > the NIC). We still need checksum offload with IP parcels. For instance, if a parcel contains 10 TCP segments we'd need the device to compute and set 10 checksums. I'm not sure how this could work in IP parcels other than using similar techniques for TSO. Tom > > > > ___ > 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
Re: [Int-area] IP Parcels improves performance for end systems
On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L wrote: > > Lars, I did a poor job of answering your question. One of the most important > aspects of > > IP Parcels in relation to TSO and GSO/GRO is that transports get to use a > full 4MB buffer > > instead of the 64KB limit in current practices. This is possible due to the > IP Parcel jumbo > > payload option encapsulation which provides a 32-bit length field instead of > just a 16-bit. > > By allowing the transport to present the IP layer with a buffer of up to 4MB, > it reduces > > the overhead, minimizes system calls and interrupts, etc. > > > > So, yes, IP Parcels is very much about improving the performance for end > systems in > > comparison with current practice (GSO/GRO and TSO). Hi Fred, 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 that IP parcels requires new protocol that would need to be implemented on both endpoints and possibly in some routers. Do you have data that shows the benefits of IP Parcels in light of these requirements? Thanks, Tom > > > > Thanks - Fred > > ___ > 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
Re: [Int-area] IP parcels
On Thu, Jan 27, 2022 at 3:43 PM to...@strayalpha.com wrote: > > 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 SYN > >> (draft-ietf-tcpm-tcp-edo). > > > > GRO and GSO are software implementations and in most deployments > > Ubiquitously deployed Linux kernel software at one point had a bug that > failed to lock the inode structure during modification. Uniquity didn’t make > that magically correct. > > >> 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 they are > >> (e.g., coalescing packets with different unknown options), and when they > >> don’t, I want to be clear that it is they that are the problem. > >> > > Joe, > > > > GRO and GSO are software implementations in kernel networking stacks > > and in most cases these are open source projects of Linux or FreeBSD. > > If they have flaws or there's areas for improvement, then by all means > > submit patches to the respective project-- that, after all, is the > > whole premise of an open source project. > > That’s not how open source works. > > The onus is on those who currently maintain the code to ensure it complies > with current protocols. I noted that I and others have experience that it > doesn’t. > > It is not the responsibility of the user community to fix their bugs or > ensure that their approach remains viable. > Actually it is. We have users fixing bugs all the time on Linux. There's no entry fee or membership, and anyone is free to submit patches. It is similar to IETF where anyone can submit I-Ds. Of course in both cases, acceptance often comes down to how much effort and perseverance the submitter is willing to put into it. Tom > > The hardware cognates, TSO > > and LRO, do tend to be more closed and for this reason they haven't > > gotten much traction-- TSO has seen a some amount of deployment, but > > LRO hasn't because of the problems of putting fairly complex > > algorithms in hardware. That problem is addressed once we have > > sufficiently programmable hardware so the stack can program things > > like GSO and GRO in hardware as easily in hardware and of course this > > should be done in ubiquitous open source that works across all > > hardware vendors. > > None of that has anything to do with the issue I raised. > > Both hardware and software implementations of these optimizations MUST > strictly comply with protocol specs. When they encounter options they don’t > know, it’s not their prerogative to do anything beyond “disable” for that > stream. That’s not our experience, though. > > Joe > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IP parcels
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 SYN > (draft-ietf-tcpm-tcp-edo). GRO and GSO are software implementations and in most deployments > > 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 they are > (e.g., coalescing packets with different unknown options), and when they > don’t, I want to be clear that it is they that are the problem. > Joe, GRO and GSO are software implementations in kernel networking stacks and in most cases these are open source projects of Linux or FreeBSD. If they have flaws or there's areas for improvement, then by all means submit patches to the respective project-- that, after all, is the whole premise of an open source project. The hardware cognates, TSO and LRO, do tend to be more closed and for this reason they haven't gotten much traction-- TSO has seen a some amount of deployment, but LRO hasn't because of the problems of putting fairly complex algorithms in hardware. That problem is addressed once we have sufficiently programmable hardware so the stack can program things like GSO and GRO in hardware as easily in hardware and of course this should be done in ubiquitous open source that works across all hardware vendors. Tom > I agree that the common Unix socket interface has performance flaws, but > perhaps it’s that interface that needs to evolve. > > Joe > > — > Joe Touch, temporal epistemologist > www.strayalpha.com > > On Jan 27, 2022, at 1:29 PM, Behcet Sarikaya wrote: > > Hi Folks, > > Thanks Christian for explaining how GSO/GRO are used by Quic implementations. > So the use is not mandated in Quic RFCs but rather used in implementations. > > > ___ > 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
Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
On Tue, Jan 25, 2022 at 11:30 AM Geoff Huston wrote: > > > > > On 26 Jan 2022, at 5:17 am, Tom Herbert wrote: > > > > On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston wrote: > >> > >> > >> > >>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen > >>> wrote: > >>> > >>> All, > >>> > >>> Thanks for the great discussion, following our side meeting at IETF 112, > >>> so far. > >>> > >>> I wanted to turn the discussion to a key question which not only arose in > >>> the side meeting already but also in the discussions since, namely “what > >>> is an address anyway?”. > >>> > >> > >> In this world of NATs it seems that we treat addresses as no more than > >> temporary ephemeral session tokens and we've passed all the heavy lifting > >> of service identification over to the name system. These days you and I > >> could be accessing the same service yet we could b e using entirely > >> different addresses to do so. Or I could be accessing the same service at > >> different times, and again be using different addresses each time. I find > >> it somewhat ironic that we see increasing moves to pull in IP addresses as > >> part of the set of personal information in some regulatory regimes, yet > >> what the larger network sees of end clients is a temporary NAT binding to > >> a public address that may be shared by hundreds if not thousands of others. > >> > >> And IPv6’s use of privacy addressing achieves a similar outcome in a > >> different way. And QUIC’s use of the session token inside the encrypted > >> envelope even makes the binding of an address to a single session fluid, > >> as the same QUIC session can be address agile on the client side. > >> > >> So perhaps an address these days is just an ephemeral transport token and > >> really has little more in the way of semantic intent. > > > > Geoff, > > > > That might be true for QUIC, but not for TCP. Each TCP endpoint > > requires stable addresses for the lifetime of the connection since the > > addresses are part of the four-tuple identifying the connection. > > Tom, > > I think you may have missed my initial characterisation of IP addresses in > your response: "we treat addresses as no more than temporary ephemeral > _session_ tokens” i.e. the NAT model relies on session level stability of the > NAT association. > > My comment about QUIC is that the QUIC protocol does not even require that > session-level stability of address association, and QUIC sessions essentially > require stability of association only on a time basis approaching the RTT > interval. > Yes, but TCP doesn't have those properties so we are bound by that at the least common denominator on the Internet until TCP is obsoleted. > If you wish to construe various judgemental observations (Like "NAT is evil”, > “NBATs break stuff”, etc,) feel free, but they are your constructions, not > mine. The issue for me is not judgments of “good” or “bad”, but simply to > explore, without overtones of judgement, exactly what an IP address > represents in today’s Internet. > I'm not sure how I was making a judgment, NAT devices do factually and transparently break transport layer connections when NAT state is evicted, packets are rerouted, or network devices crash. Any discussion about what addresses are in the current Internet has to include this consideration. My point is that there are host requirements relating to addresses that the network must be aware of if it is applying more semantics than just for routing (this probably degenerates to the age-old problem that IP addresses convey both identity and location). Tom > Geoff > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston wrote: > > > > > On 25 Jan 2022, at 6:19 pm, Dirk Trossen > > wrote: > > > > All, > > > > Thanks for the great discussion, following our side meeting at IETF 112, so > > far. > > > > I wanted to turn the discussion to a key question which not only arose in > > the side meeting already but also in the discussions since, namely “what is > > an address anyway?”. > > > > In this world of NATs it seems that we treat addresses as no more than > temporary ephemeral session tokens and we've passed all the heavy lifting of > service identification over to the name system. These days you and I could be > accessing the same service yet we could b e using entirely different > addresses to do so. Or I could be accessing the same service at different > times, and again be using different addresses each time. I find it somewhat > ironic that we see increasing moves to pull in IP addresses as part of the > set of personal information in some regulatory regimes, yet what the larger > network sees of end clients is a temporary NAT binding to a public address > that may be shared by hundreds if not thousands of others. > > And IPv6’s use of privacy addressing achieves a similar outcome in a > different way. And QUIC’s use of the session token inside the encrypted > envelope even makes the binding of an address to a single session fluid, as > the same QUIC session can be address agile on the client side. > > So perhaps an address these days is just an ephemeral transport token and > really has little more in the way of semantic intent. Geoff, That might be true for QUIC, but not for TCP. Each TCP endpoint requires stable addresses for the lifetime of the connection since the addresses are part of the four-tuple identifying the connection. While the addresses at each end point of a connection may differ, they must be consistent for the lifetime of the connection at both endpoints. That's where NAT breaks things, if NAT state is evicted or lost TCP connections routed through NAT are no longer viable, hence that's why it's correct to say that NAT breaks the end to end model. TCP properties also makes it difficult to change the addresses of TCP connections on the fly for privacy, but giving each connection it's own unique IP address is potentially feasible since there are no necessary protocol requirements for consistent addressing between different connections. Tom > > Geoff > > > ___ > 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
Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC
On Tue, Jan 11, 2022 at 2:02 AM Jiayihao wrote: > Hello Tom, > > > > Thanks for sharing draft-herbert-ipv6-prefix-address-privacy, and I am > concerning the following points after I go through the draft and related > references. > > > > - Both IPv6 Temporary Address (TA6 for short) and NAT only enhance privacy > against third parties except the Law Enforcement party (a party with super > power). > > > > If so, let’s focus on the privacy for those third parties: > > > > - If a prefix is assigned to a certain entity (like a house, or a certain > laboratory), privacy is still hard to reach because such entity can be > correlated to just a few users, and such mapping can be easily figured out > in reality. > > > > In general, if X(X>=1) endpoints are assigned with Y(Y>=1) shared prefixes > in TA6 scenarios, I feel the only ways that the privacy can be enhanced are > that: > > 1. X >> Y, so the case is pretty similar to NAT > > 2. Y >> X, so the case is like any endpoint have infinite prefixes, so I > just assume that each endpoint can use different prefix for each flow > connect. (However in reality we would really worry about prefix consumption > attack, just looks like another kind of DDoS) > > > Hi Yihao, Thanks for the question. We need to consider the vastness of the IPv6 address space, and it's not prefixes that are assigned to end hosts, but rather blocks of individual addresses that are pseudo randomly assigned out of a provider's address prefix. Suppose that some provider only has a 64 bit prefix for assigning these addresses, and let's say they need to serve 1B users and each user has a generous 1M temporary addresses at any given time. The number of addresses in the prefix is 1.8*10^19 addresses and the number of addresses used at any time is 10^15 or just 0.006% of the provider's address space. If we compare this to NATv4, temporary IPv6 addresses have much better scaling. Even in the base case scenario where a provider had an 8 bit IPv4 prefix so they could assign 2^24 addresses to NAT and combine it with 16 bits of port numbers that is only 40 bits of source address space. If the mappings include destination address and port then that could provide a few more bits but still well short of the usable address space in the example above. For prefix assignment, like the practice of some mobile providers to give each end device its own 64 bit prefix seems wasteful to me and would lead to prefix exhaustion as you mentioned. I suppose one of the ostensible reasons to do this is for privacy, each end device could create its own unique addresses from their prefix. But as already discussed, if all these addresses share the same network prefix that correlates to the user's device then there's really no privacy benefit. Any cases else cannot improve good privacy. > > HOWEVER, the suffix/IID in TA6 is out of business NO MATTER it is case 1 > or case 2! > > > > For this, I am pretty pessimistic that TA6 seems never provide practical > privacy enhancement compared to IPv4, nor provide any proof in the > referenced drafts. > > > > --- > > > > Besides, as you mention ID/locator split, I am doubt that it just don’t > works because although ID provide explicit identity, locators are still and > always provide IMPLICIT identity just like what IPv4 did. IMO ID/locator > split cannot remove the Implicit nature that locator would always be a > shadow of identity. > I would confine the ID/locator split to only internal provider use. Externally, the only specific information that should be exposed in an IP address is the provider's network prefix that routes a packet to the provider's network. The externally visible address should not reveal any of the internal structure of the provider's network and definitely no information that could be used to deduce sensitive privacy information about the user like location or human identity. When a packet enters the provider's network it needs to be mapped to the real location of the address. This already happens today in mobile networks and virtual networks where the real location of the host is not set in the address. Once the real location is determined, the packet is tunneled using an encapsulation to the location and at the tunnel endpoint it's decapsulated and the originally sent packet is delivered to the user. ID/locator split in IPv6 addresses is just an alternative for doing this compared to using a more expensive encapsulation like GRE or VXLAN and similarly would not be exposed to the Internet. Tom > > Best Regards, > > Yihao > > > > *From:* Tom Herbert > *Sent:* 2022年1月7日 23:38 > *To:* Jiayihao > *Cc:* Abraham Y. Chen ; int-area@ietf.org > *Subject:* Re: [Int-area] Where/How is the features innovation, > happening? Re
Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC
On Thu, Jan 6, 2022 at 11:48 PM Jiayihao wrote: > Hi Tom, > > > > I love your argument on RFC7721 and agree on that quantitative analysis is > needed to prove that periodically source address shift is more secure, and > if so, the timing to shift the address should be calculated. > > > > Apparently a simple answer to that is OTP as you detailed. However, the > sad thing is that if every Endpoint (most refer to requestor/client in > IPv6) shift its source address per each connection, is it **seriously > affordable** for the network (provider) that these endpoints attached to? > Hi Yihao, It's unclear to me whether it's affordable without a specific proposal on how to do it. In order to do this it would require a service provider to manage and track a very large block of independent hosts addresses, however given how other databases have been able to scale to very large datasets, I tend to believe there is a feasible solution. I wrote a draft outlining problem and general solutions in https://www.ietf.org/archive/id/draft-herbert-ipv6-prefix-address-privacy-00.txt > If not, is that the argument you prefer CGNAT than IPv6 Temporary > address(RFC7721) for IP layer privacy consideration? > Objectively, it seems that CGNAT, under the right conditions, does provide better privacy for users in IP addressing. The strength of CGNAT in terms of privacy has also been anecdotally demonstrated by law enforcement's concerns about it. It pains me to say that because the whole point of a 128 bit address space in IPv6 was to eliminate the NAT abomination :-) Tom > > > Happy new year! > > Thanks, > > Yihao > > > > *From:* Tom Herbert > *Sent:* 2021年12月31日 2:30 > *To:* Abraham Y. Chen > *Cc:* Jiayihao ; int-area@ietf.org > *Subject:* Re: [Int-area] Where/How is the features innovation, > happening? Re: 202112271737.AYC > > > > > > > > On Mon, Dec 27, 2021 at 7:00 PM Abraham Y. Chen wrote: > > Hi, YiHao: > > > > 0)Hope you had a Merry Christmas as well! > > > > 1)Re: Ur. Pts 1) & 2):Allow me to modify and expand your > definitions of the abbreviations, ICP & ISP, a bit to streamline our > discussion, then focusing on related meanings of the two keyword prefixes, > "C" and "A" in the middle of them: > > > > A.ICP (Internet Content Provider):This is the same as you are > using. > > > > B.IAP (Internet Access Provider):This will represent the ISP > that you are referring to. > > > > C.ISP (Internet Service Provider):This will be used as the > general expression that covers both ICP and IAP above. > > > > With these, I agree in general with your analysis. > > > > 2)From the above, there is a simpler (layman's instead of engineer's) > way to look at this riddle. Let's consider the old fashioned postal > service. A letter itself is the "Content". The envelop has the "Address". > The postal service cares only what is on the envelop. In fact, it is > commonly practiced without explicitly identified that one letter may have > multiple layers of envelops that each is opened by the "Addressee" who then > forward the next "Addressee" according to the "Address" on the inside > envelop, accordingly. To a larger scale, postal services put envelops > destined to the same city in one bag. Then, bags destined to the same > country in one container, etc. This process is refined to multiple levels > depending on the volume of the mail and the facility (routes) available for > delivery. Then, the containers are opened progressively along the > destination route. No wonder that the US Postal Service claimed (during the > early days of the Internet) that the mail system was the fist "packet > switching" system. > > > > 3)So, in this analogy, the "Address" on each and every envelop has to > be in the clear (not coded or encrypted in any sense) for the mail handlers > to work with. It is only the most inner "Content", the letter itself, can > have Confidential information (or encrypted if the sender wishes). Under > this scenario, the LE (Law Enforcement) is allowed only to track suspected > mail by the "Addresses". And, any specific surveillance is only authorized > by court, case by case. While no one can prevent LE bypassing this > procedure, cases built by violating this requirement would be the ground > for being thrown out of the court. > > > > 4)However, in the Internet environment, largely, if not most, > Addresses are dynamic. There is no way to specify an IP Address for > surveillance of a suspect. This gives the LE th
Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC
is that than changing the address once a day? It's intuitive that it should be better security, but is it _really_ better? And if it is better, are the benefits worth the aggravation of changing the address. This is quite similar to some companies that have a policy that everyone needs to change their passwords periodically. Studies have shown that there is little quantitative value in doing this and in fact the net effect is likely less security and increased user aggravation-- even so, companies will continue to do this because it's easier to stick with the inertia of intuition. The fix for the password problem is one time passwords (OTP) and IMO that hints at the fix for the address security problems described in RFC7712, essentially we need single use source addresses per each connection. The security effects of single use addresses are quantifiable, i.e. given sample packets from independent two flows generated by the same user, without additional information it isn't possible for a third party to correlate that they are sourced by the same user. Tom > > > Happy New Year! > > > Abe (2021-12-27 21:59) > > > > > > On 2021-12-23 22:26, Jiayihao wrote: > > Hello Abe, > > > > Users are unwilling to be watched by any parties(ISP, and ICP also) > excepts users themselves. Actually I would like to divide the arguments > into 2 case: network layers and below (not completely but mostly controlled > by ISP); transport layers and above (not completely but mostly controlled > by ICP). > > > > 1) For transport layers and above, Encryption Everywhere (like TLS) is a > good tool to provide user privacy. However, it is only a tool against ISPs, > while ICPs survive and keep gaining revenue (even by selling data like the > negative news of Facebook, or Meta, whatever you call it). As discussed, it > is not networks faults because IP provides peer-to-peer already. You may > blame CGNAT in ISP increasingly contributes to a C/S mode in replacing P2P, > like in China where IPv4 addresses are scare and CGNAT is almost > everywhere. However, I don’t find the situation any better in U.S. where > most of IPv4 address are located. It is a business choice to overwrite the > mode to be peer-ICP-peer(C/S mode) at application layer, other than utilize > the P2P mode that natively provided by IP. > > > > In this case, there are trust points and they are ICPs. > > > > 2) For network layers and below, ISP and IP still provide a pure P2P > network, and Encryption in TLS do not blind ISP in IP layer since IP header > is still in plaintext and almost controlled by ISP. That is to say, in an > access network scenario, the access network provide can see every trace of > every user at network layer level (although exclude the encrypted payload). > To against this, one can use Proxy(i.e., VPN, Tor) to bypass the trace > analysis just like the CGNAT does. The only difference is that detour > points (Proxies) belong to a third party, not ISP. > > > > In this case, there are trust points and they are third party proxies. > > > > The bottom line is that trust points are everywhere explicitly or > implicitly, and privacy can be leaked from every (trust) point that you > trust (or have business with). No matter what network system you have, no > matter it is PSTN or ATM, these trust points are just the weak points for > your privacy, and the only things users can beg is that **ALL** trust > points are 1) well behave/don’t be evil; 2)system is advanced enough that > can’t be hacked by any others; 3) protected by law. > > > > I would say pretty challenging and also expecting to reach that. > > Network itself just cannot be bypassed in reaching that. > > > > Merry Christmas, > > Yihao > > > > > > *From:* Abraham Y. Chen > *Sent:* 2021年12月23日 10:01 > *To:* Jiayihao > *Cc:* t...@herbertland.com; int-area@ietf.org > *Subject:* Re: [Int-area] Where/How is the features innovation, > happening? Re: 202112221726.AYC > *Importance:* High > > > > Hi, YiHao: > > 0)I am glad that you distilled the complex and elusive privacy / > security tradeoff issues to a very unique and concise perspective. > > 1)Yes, the IPv4 CG-NAT and IPv6 Temporary address may seem to provide > some privacy protection. However, with the availability of the computing > power, these (and others such as VPN) approaches may be just ostrich > mentality. On the other hand, they provide the perfect excuse for the > government (at least US) to justify for "mass surveillance". For example, > the following is a recent news report which practically defeats all current > "privacy protection" attempts. > > > https://www.usatoday.com/story/ne
Re: [Int-area] IP parcels
On Tue, Dec 21, 2021 at 1:17 PM Templin (US), Fred L wrote: > > Tom, thanks for these questions. A simple picture might help understanding: > > A <- net #1 -> X <- Internet -> Y <- net #2 - > B > Fred, Thanks. The picture is helpful. Presumably, in this picture the typical scenario would be that the MTU of net #1 and net #2 are greater than the MTU on the Internet, and could in fact be much greater. So a large MTU packet to B and over its local network it gets the benefits of a larger MTU. And then such packets could be fragmented at X to send over the Internet. Y reassembles the packet to enjoy the benefits of a larger MTU on network #2. If my understanding is correct, X is basically fragmenting packets whose length exceeds the MTU of the Internet. That seems to have the same functionality as IP fragmentation, but I suppose the point of IP parcels is that the packet may be larger than 64K or it allows intermediate nodes to do fragmentation with IPv6. But what is happening at Y is interesting to me. Y is trying to opportunistically reassemble packets in the network. As I mentioned the problem with doing that is that Y may or may not see all the packets of a parcel, or an attacker could purposely send one-off fragments to try to exhaust memory, or there might just be too many user flows going through the device that are candidates for reassembly-- for any of these cases it seems pretty easy to move to a state that substantially reduces the benefits of in-network reassembly. And if a device does get into this mode where it's only able to reassemble some small fraction of the traffic, then it seems like the effect would be to introduce delay on parcel fragments that never actually get reassembled (which would seem to violate the principle that if an opportunistic optimization becomes in effective, the effects should be no worse than had the optimization no existed at all). Do you have any data on the cost/benefits of reassembling at Y? Tom > Here, when A sends a parcel to B, it travels first over net #1 to a "first hop > middlebox" X. If the path MTU from A to X is smaller than the size of the > parcel, then A has to split the parcel into subparcels no larger than 64KB > and transmit each of the sub-parcels to X using IP fragmentation if necessary. > If the path MTU from A to X is at least as large as the parcel, then A can > send > the whole parcel to X, i.e., even if the path MTU and parcel size exceed 64KB. > > Once X gets the subparcels, X should perform "sticky reassembly" by > concatenating > subparcels of the same parcel opportunistically; but it does not need to > strictly > reassemble the full parcel because the sub-parcels can go forward > independently > if necessary. X then needs to somehow convey the parcel (or sub-parcels) over > the > Internet to Y and the same considerations as above apply. Then, the same thing > happens for Y conveying finally on to B. > > So, in terms of fragmentation and reassembly at the IP layer, all that is > required > is that all of A, X, Y and B are capable of reassembling up to 64KB since > that is the > largest size IP packet that can be reassembled. If any or all of the hops > support a > larger packet size (jumbo) then great and the parcel can be forwarded in one > piece. > > But, at the parcel layer it is somewhat different. Breaking a parcel into > sub-parcels > means that a single parcel can be broken down to a maximum of 64 sub-parcels. > Each of these sub-parcels should be marked with a common short Parcel ID plus > a monotonically incrementing 32-bit packet Identifier so the next hop can know > that they were all originally part of the same parcel. Then, the next hop > applies > "opportunistic reassembly" as you called it and tries to paste the parcel > back together. > If the whole parcel gets reassembled to its original form, then that is > great; otherwise, > it can continue forward as sub parcels to the next hop. > > And it continues in this fashion from source to destination. If the "sticky" > parcel > reassembly works well then the whole original parcel might be delivered to the > final destination in one piece. But, in the worst case, the final destination > might > get up to 64 singleton parcels - and then, it can do "sticky reassembly" on > these > since it is the final destination! > > In fact, the whole reason for doing "sticky reassembly" at middleboxes it to > make > the largest possible parcels to send to next hops where the path MTU is > greater > than 64K. We don't have many paths like that yet, but parcels might provide > motivation for trending in that direction. > > I was originally thinking I would capture all this in the OMNI spec instead &
Re: [Int-area] IP parcels
On Tue, Dec 21, 2021 at 6:24 AM Templin (US), Fred L wrote: > > Tom, reading your message makes me think you have not read my drafts. The > > answers to the perceived issues you are raising are all there. I do not see > anything > > new in what you are saying to make me believe otherwise. > > Fred, I did read your draft. I might be misunderstanding it. Here are points I don't think I understand, f these are in the draft plead reference the precise section: - A clear explanation why GSO/GRO are not sufficient to solve the problem. The draft highlights these to show the advantages of sending/receiving large data units, but it's not clear to me why a change to the protocol is required to get the same or somehow better effect. As a side note, it should be pointed out that GSO/GRO and similar mechanisms are opportunistic optimizations. For instance, the TCP congestion window and receive window have to be large enough for GSO to be effective for sending on a connection. As an anecdote, there was an incident early on at YouTube where they extensively used GSO for serving video which under normal circumstances is a great savings in CPU utilization. But one day there was a hiccup on the Internet that caused all the connections to go to slow start. So now instead of sending 64K at a time the servers were sending two segments at a time for all the connections (this was before the work to raise initcwnd); so now instead of servers running at 50% CPU, they needed 150% CPU and so were dropping a lot of packets, and recovering took quite a bit of time making unhappy customers (moral of this story: always provision your servers to handle the worst case scenario where opportunistic optimizations become ineffective!) - What is the exact algorithm for reassembly of parcels? Searching the document for reassemble only comes up with "when the OAL source or final destination receives the fragments or whole parcels, it reassembles if necessary" - What are the ramifications of middleboxes performing reassembly on behalf of a host. The document says "then rejoined into one or more parcels at a last-hop middlebox to be forwarded to the final destination". I'm not sure what a "last-hop middlebox" means in a normative context, but this does appear to be an intermediate network node which would seem to be susceptible to the issues of stateful intermediate network nodes that I previously raised. - Is in order delivery of segments within a parcel maintained. The draft states "While not desirable, reordering of segments within parcels and individual segment loss are possible. But, 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". Why is it so critical to keep the number of parcels delivered to the final destination to be kept at minimum? As I mentioned, hosts are already used to dealing with reassembly, it seems like the best method is still to send packets at path MTU which is what TCP is doing with PMTUD. - How are IP parcels substantially different from fragmentation? Is the idea that individual segments in an IP parcel can be lost without losing the whole parcel? Is the idea that parcels can make up a >64K super packet? What if a segment in a parcel is greater than an MTU in the path, is an intermediate node breaking up a parcel expected to fragment the segment, or send a PTB? Tom > > Thanks - Fred > > > > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Monday, December 20, 2021 4:14 PM > To: Templin (US), Fred L > Cc: to...@strayalpha.com; int-area@ietf.org > Subject: Re: IP parcels > > > > > > On Mon, Dec 20, 2021 at 3:11 PM Templin (US), Fred L > wrote: > > Tom, in modern reassembly it is not going to wait for the MSL for all > fragments > > to arrive anymore; either they all get there after a very small inter-fragment > > delay, or you send an immediate FRAGREP and possibly also a PTB soft error > > then quickly declare the reassembly dead if that doesn’t help. And, you make > > sure to inspect IDs of received fragments before admitting them into the > > reassembly cache so you don’t end up caching garbage that will just have to > > be discarded later. > > > > Fred, > > > > It doesn't matter in the sense that reassembly is a non-working conserving > mechanism. In order to perform reassembly packet fragments need to be held > which means memory will be consumed and since memory is a finite resource it > needs to be managed. Managing memory means that some policy is needed when > to time out a reassembly or which fragment train to discard under memory > pressure. A network that implements some arbitrary policy can cause problems > o
Re: [Int-area] Where/How is the features innovation happening?
From: Int-area on behalf of Alexandre Petrescu Sent: 20 December 2021 20:28 Le 18/12/2021 à 23:47, Brian E Carpenter a écrit : > On 19-Dec-21 11:34, Dino Farinacci wrote: >>> From a user perspective, the choice is clear: privacy and security are >>> top requirements. We know that payload encryption goes a long way, and >>> hopefully encryption of the transport layer headers will become >>> dominant so that intermediate nodes will stop meddling and ossifying >>> the transport layer. But not everything can be encrypted, the IP >>> addresses for instance, so providing real security and privacy at the >>> plaintext network layer should be on the list of features to support >>> user requirements. >> >> Definitely agree Tom. >> >> But what if we sent a packet where the source address was encrypted? >> Then you could have global unique addresses (if you wanted them). Of >> course key exchange and rekeying parameters would have to be setup >> prior to sending a single packet. > > It's called SNA (Sourceless Network Architecture): > https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf Wasnt SNA an IBM acronym for an architecture? Silly Names and Acronyms as I recall; YMMV Tom Petch Alex > > Brian > >> Maybe its just simpler to randomize addresses. >> >> Dino >> > > ___ > 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] IP parcels
On Mon, Dec 20, 2021 at 3:11 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Tom, in modern reassembly it is not going to wait for the MSL for all > fragments > > to arrive anymore; either they all get there after a very small > inter-fragment > > delay, or you send an immediate FRAGREP and possibly also a PTB soft error > > then quickly declare the reassembly dead if that doesn’t help. And, you > make > > sure to inspect IDs of received fragments before admitting them into the > > reassembly cache so you don’t end up caching garbage that will just have to > > be discarded later. > Fred, It doesn't matter in the sense that reassembly is a non-working conserving mechanism. In order to perform reassembly packet fragments need to be held which means memory will be consumed and since memory is a finite resource it needs to be managed. Managing memory means that some policy is needed when to time out a reassembly or which fragment train to discard under memory pressure. A network that implements some arbitrary policy can cause problems on unsuspecting hosts. For instance, there's mechanisms for hosts to try to guess what the timeout is in a NAT box and send a keepalive packet before an idle NAT state is evicted. So this is just a guess that may or may not be right, and in fact there might not even be a NAT in the path in which case the host is just wasting energy sending keepalives. Also, the second we introduce a new exhaustible resource in the path that becomes yet another denial of service vector (consider the case that an attacker spoofs a whole bunch of IP parcels). Unless the network can coordinate very specifically with the host about what it's doing on behalf of the host stack, I think it's much better for the network to just focus or forward packets without delay and let the host handle the details of receive processing, reassembly, security, etc. Tom > > Fred > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Monday, December 20, 2021 1:06 PM > *To:* Templin (US), Fred L > *Cc:* to...@strayalpha.com; int-area@ietf.org > *Subject:* Re: IP parcels > > > > > > On Mon, Dec 20, 2021 at 12:03 PM Templin (US), Fred L < > fred.l.temp...@boeing.com> wrote: > > Tom, sorry I will try to use my words more carefully; I am using GSO/GRO > also for > > a UDP-based transport protocol – not QUIC but something similar. I like > GSO/GRO > > very much; I am glad the service is available and I want to see it > continue. But, my > > understanding of the services is that they leverage the IP ID field in > whole IPv4 > > packets that are not eligible for fragmentation and those are limitations > I am > > seeking to improve on. > > > > I want to enable a facility similar to GSO/GRO that works for both IPv4 > and IPv6 > > packets and allows for lower layers to fragment if necessary. And, I want > to use > > a well-behaved 32-bit IPv6 ID instead of the 16-bit IPv4 one where the use > is not > > well defined when DF=1. > > > > There has been a lot of work in this area. For instance, you might want to > take a look at https://www.youtube.com/watch?v=ccUeG1dAhbw > > > > About reassembly, that would only happen on the end systems themselves or > on > > a very capable device that is very close to the end systems; I would not > want for > > a high-speed core router to have to reassemble. > > > > Even so, an intermediate device close to the end system still has to > provide service to more than one host. Reassembly requires memory to store > fragments. A host would need enough memory to service all of its own flows, > but an intermediate node would need number of hosts it serves times that > amount of memory to perform reassembly. This is a fundamental scaling > problem of stateful services in the network, inevitably the network nodes > cannot scale to the number of users or flows that require service. In the > best case scenario, when resources are not available the network won't > attempt the stateful operation and will just forward the packet unimpeded > (which is fine because host will never rely on this class of optimization). > In the worse case scenario, the network will take a detrimental action such > as forcibly breaking a connection (e.g. this is what can happen when a NAT > evicts a TCP connection because it has run out of memory). IMO, maintaining > state in the network is a bad, albeit unfortunately prevalent, idea. > > > > Tom > > > > > > Again, GSO/GRO is nice work and much respect is due to those who made it > possible. > > > > Fred > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Monday, December 20
Re: [Int-area] IP parcels
On Mon, Dec 20, 2021 at 12:03 PM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Tom, sorry I will try to use my words more carefully; I am using GSO/GRO > also for > > a UDP-based transport protocol – not QUIC but something similar. I like > GSO/GRO > > very much; I am glad the service is available and I want to see it > continue. But, my > > understanding of the services is that they leverage the IP ID field in > whole IPv4 > > packets that are not eligible for fragmentation and those are limitations > I am > > seeking to improve on. > > > > I want to enable a facility similar to GSO/GRO that works for both IPv4 > and IPv6 > > packets and allows for lower layers to fragment if necessary. And, I want > to use > > a well-behaved 32-bit IPv6 ID instead of the 16-bit IPv4 one where the use > is not > > well defined when DF=1. > There has been a lot of work in this area. For instance, you might want to take a look at https://www.youtube.com/watch?v=ccUeG1dAhbw > > > About reassembly, that would only happen on the end systems themselves or > on > > a very capable device that is very close to the end systems; I would not > want for > > a high-speed core router to have to reassemble. > Even so, an intermediate device close to the end system still has to provide service to more than one host. Reassembly requires memory to store fragments. A host would need enough memory to service all of its own flows, but an intermediate node would need number of hosts it serves times that amount of memory to perform reassembly. This is a fundamental scaling problem of stateful services in the network, inevitably the network nodes cannot scale to the number of users or flows that require service. In the best case scenario, when resources are not available the network won't attempt the stateful operation and will just forward the packet unimpeded (which is fine because host will never rely on this class of optimization). In the worse case scenario, the network will take a detrimental action such as forcibly breaking a connection (e.g. this is what can happen when a NAT evicts a TCP connection because it has run out of memory). IMO, maintaining state in the network is a bad, albeit unfortunately prevalent, idea. Tom > > Again, GSO/GRO is nice work and much respect is due to those who made it > possible. > > > > Fred > > > > *From:* Tom Herbert [mailto:t...@herbertland.com] > *Sent:* Monday, December 20, 2021 9:20 AM > *To:* Templin (US), Fred L > *Cc:* to...@strayalpha.com; int-area@ietf.org > *Subject:* Re: [Int-area] [EXTERNAL] Re: 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. > > > > 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:* to...@strayalpha.com [mailto:to...@strayalpha.com] > *Sent:* Sunday, December 19, 2021 11:53 AM > *To:* Templin (US), Fred L > *Cc:* i
Re: [Int-area] Where/How is the features innovation happening?
On Mon, Dec 20, 2021 at 1:27 AM Jiayihao wrote: > > Hello Tom, > > > > The privacy countermeasure for IPv4/IPv6 is interestingly different. > > IPv4 usually utilize CGNAT, i.e., M(hosts)-to-N(IPs), where M >> N so that > the host could remain anonymous > > IPv6 usually utilize Temporary address, i.e., 1(host)-to-M(IPs[at least > suffix level]), where M >> 1 so that the host could remain anonymous. > > > > HOWEVER, I don’t feel any approach reaches privacy perfectly, because access > network have a global perspective on M-to-N or 1-to-M mapping. > > For this, it is hard to be convinced that IPv4/6 itself can reach a perfect > privacy. > Jiayihao, Yes, the access network might out of necessity maintain the mappings that could correlate users to IP addresses. I would expect that the provider has a contractual agreement with users on how that information is protected. The concern is the rest of the Internet for which users aren't in contract with. For that perfect privacy in flow addressing is achieved if given any two packets for two different flows, no third party passively snooping the Internet would be able to correlate whether they are sourced by the same user. Perfect privacy for addressing in general then would be that a third party couldn't correlate that any two packets were sourced by the same user regardless if they are in the same flow. As I mentioned, under the right conditions, CGNAT is sufficient to meet the perfect privacy in flow addressing. Temporary addresses can't do it if they are used for more than one connection. This is also why I believe RFC8981 is flawed. It describes the mechanisms for getting temporary addresses nicely, but offers no specific guidance as to how long the quantum for the temporary address should be used for any quantifiable level of privacy for the user. Tom > > > Thanks, > > Yihao Jia > > > > --- > > > > I believe CGNAT is better than IPv6 in terms of privacy in addressing. > > In fact one might argue that IPv4 provides better privacy and security > > than IPv6 in this regard. Temporary addresses are not single use which > > means the attacker can correlate addresses from a user between > > unrelated flows during the quantum the temporary address is used. When > > a user changes their address, the attacker can continue monitoring if > > it is signaled that the address changed. Here is a fairly simple > > exploit I derived to do that (from > > draft-herbert-ipv6-prefix-address-privacy-00). > > > > The exploit is: > > o An attacker creates an "always connected" app that provides some > > seemingly benign service and users download the app. > > o The app includes some sort of persistent identity. For instance, > > this could be an account login. > > o The backend server for the app logs the identity and IP address > > of a user each time they connect > > o When an address change happens, existing connections on the user > > device are disconnected. The app will receive a notification and > > immediately attempt to reconnect using the new source address. > > o The backend server will see the new connection and log the new > > IP address as being associated with the specific user. Thus, > > the server has > > a real-time record of users and the IP address they are using. > > o The attacker intercepts packets at some point in the Internet. > > The addresses in the captured packets can be time correlated > > with the server database to deduce identities of parties in > > communications that are unrelated to the app. > > > > The only way I see to mitigate this sort of surveillance is single use > > addresses. That is effectively what CGNAT can provide. > > > > Tom ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Where/How is the features innovation happening?
On Fri, Dec 17, 2021 at 7:16 PM Dino Farinacci wrote: > > > If we care about the peer-to-peer property, varying addresses require a > > rendezvous process based on a non-varying identifier. It's then the latter > > that becomes the handle for surveillance and forensics. The real impact of > > CGNAT is to push that factoid into surveillance models; it gives IPv4 the > > same privacy assist that temporary addresses give IPv6. > > Hosts talk to hosts, I don't care if they are in a data center or two > clients. You don't have to distinguish and certainly shouldn't design an > address algorithm to distinguish. > > As for surveliience and privacy, you can't have both. So pick one. > Dino, >From a user perspective, the choice is clear: privacy and security are top requirements. We know that payload encryption goes a long way, and hopefully encryption of the transport layer headers will become dominant so that intermediate nodes will stop meddling and ossifying the transport layer. But not everything can be encrypted, the IP addresses for instance, so providing real security and privacy at the plaintext network layer should be on the list of features to support user requirements. Tom > And Luigi, you shouldn't trust the devices that are close to you. Even if you > manage them you can't trust the vendors that make them. > > Dino > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Where/How is the features innovation happening?
On Fri, Dec 17, 2021 at 2:22 PM Brian E Carpenter wrote: > > On 18-Dec-21 10:58, Tom Herbert wrote: > > On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com > > wrote: > >> > >> Globally unique != static. > >> > >> They can be randomized and varied over time, e.g., as are Ethernet MAC > addresses, exactly for the reasons you note. > > > > I would agree with that if the time to randomize is basically so small > > that a client can use a unique and un-correlatable address for each > > connection. Given the data collection abilities and compute resources > > available to those that want to engage in surveillance, any time for > > randomizing addresses, be it a day, an hour, or a few minutes, that is > > greater than this minimum only provides a false sense of security with > > respect to trying to prevent third parties from making correlations > > about the sender's identity between different flows on the Internet. > > Interestingly, CGNAT with enough users behind it can provide these > > properties (attested by the fact the law enforcement has complained > > about it). > > If we care about the peer-to-peer property, varying addresses require a > rendezvous process based on a non-varying identifier. It's then the latter > that becomes the handle for surveillance and forensics. The real impact of > CGNAT is to push that factoid into surveillance models; it gives IPv4 the > same privacy assist that temporary addresses give IPv6. Brian, I believe CGNAT is better than IPv6 in terms of privacy in addressing. In fact one might argue that IPv4 provides better privacy and security than IPv6 in this regard. Temporary addresses are not single use which means the attacker can correlate addresses from a user between unrelated flows during the quantum the temporary address is used. When a user changes their address, the attacker can continue monitoring if it is signaled that the address changed. Here is a fairly simple exploit I derived to do that (from draft-herbert-ipv6-prefix-address-privacy-00). The exploit is: o An attacker creates an "always connected" app that provides some seemingly benign service and users download the app. o The app includes some sort of persistent identity. For instance, this could be an account login. o The backend server for the app logs the identity and IP address of a user each time they connect o When an address change happens, existing connections on the user device are disconnected. The app will receive a notification and immediately attempt to reconnect using the new source address. o The backend server will see the new connection and log the new IP address as being associated with the specific user. Thus, the server has a real-time record of users and the IP address they are using. o The attacker intercepts packets at some point in the Internet. The addresses in the captured packets can be time correlated with the server database to deduce identities of parties in communications that are unrelated to the app. The only way I see to mitigate this sort of surveillance is single use addresses. That is effectively what CGNAT can provide. Tom > > So perhaps what we need is a surveillance-proof rendezvous mechanism. > > Brian > > > > > Tom > > > >> > >> 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 Huston wrote: > >> ... > >> > >> So, to repurpose some graffiti from the 1970’s, we need globally unique > >> addresses like fish need bicycles! :-) > >> > >> > >> They have residual value for surveillance and possibly other forensic > >> uses, which may of course be actively harmful to the user. > >> > >> But on the other hand, while what you say about economics is undoubtedly > >> true, don't we want to keep the peer-to-peer option open *as a matter of > >> principle*? After all, we still have that option for phone calls, even > though it's now a minority usage pattern for mobile devices. > >> > >> Brian > >> > >> ___ > >> 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 > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
