On Oct 3, 2023, at 4:58 PM, Tom Herbert <t...@herbertland.com> wrote: >> 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.
Ah, sure. I agree that's a hard requirement. >> 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' :-) That'll do. >> 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 :-) Yeah, I worked for years with two of Cisco's firewall products that did exactly that, and one project that supported each firewall only seeing half the flow. Their existing active/standby synchronization was extensible to handle multiple paths. But it's not the usual configuration and we only bothered with it for VoIP flows because was deemed insufficient market for TCP. Finding customers that understand networking to that level was certainly difficult. -d
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
