On Mar 21, 2024, at 8:48 PM, Tom Herbert <[email protected]> wrote: > > > > On Thu, Mar 21, 2024, 8:28 PM [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> wrote: >> <Joe> >>> >>>> 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. 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. Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
