> This isn't what you're asking, Gerrit, since you are (correctly) > worrying about UNEXPECTED differences that would only crop up in a > prototype, but here is a list of expected changes a kernel DCCP would > require to work with UDP encapsulation. > > - Using a 6-tuple instead of a 4-tuple for flow identification. > - Header checksum processing changes (0 on send, required 0 on receive). > Ok I am out. This is one more specification that alters the behaviour of another specification. There is no point in all this complexity, it does not have any practical advantage over implementing congestion control directly on top of UDP, without the overhead of passing through an extra protocol, extra processing rules, extra tuples. > > On 10/11/10 10:27 PM, Gerrit Renker wrote: >> Hi Tom, >> >> thank you for the clarifications. Without wanting to embark on wording >> details >> and/or thought experiments, let me just restate what the comments aimed >> at. >> >> |> The main point I did not understand is whether the aim is to >> |> * encapsulate DCCP as a user-space protocol or >> |> * encapsulate DCCP as an in-kernel protocol? >> |> >> | [TomP] The main point is neither, or rather the main point is >> orthogonal >> | to these issues. The main point is to allow DCCP to pass through >> | existing NAT devices. >> | >> What I am asking is whether the specification would work also with an >> unmodified kernel that has DCCP already built in. That is, whether the >> draft >> would require changes to the in-kernel protocol in order to make it work >> with >> UDP-encapsulation. Whether the components could be plugged together, >> without >> DCCP necessarily being aware that it is routed somewhere. >> >> I think what would really be highly desirable is some kind of prototype. >> >> For RFC 5596 there was a working prototype, which made discussion much >> easier >> by ruling out impracticable things that would otherwise have complicated >> the >> description. >> >> I would be happy to help with working on a prototype (perhaps a little >> later). It would be great if the specification remained not paperwork, >> but is >> also easy and simple to put into practice. >> >> Gerrit >
