I think you misunderstand.
Gerrit asked if *an existing kernel DCCP* would need to change to work with
UDP encapsulation. That's the question I answered.
DCCP-UDP encapsulation could be implemented at userlevel over a UDP socket
with no kernel changes. Some of its choices, such as the
somewhat-controversial checksum design, enable this: DCCP-UDP packets are
valid UDP packets with no special semantics on the payload; the DCCP stuff can
be extracted without reference to enclosing layers.
Eddie
On 10/16/2010 06:53 PM, Andrew Lentvorski wrote:
On 10/13/10 10:20 PM, gerrit@xxxxxxxxxxxxxx wrote:
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.
I have to agree.
Folks, I see the whole point of UDP encap as allowing DCCP to work when
all you have to work with are UDP packets. There are two situations when
this is true:
1) When NAT's block you
2) When the OS only provides a UDP socket and not a raw socket
Both are at least equally important. The second may be *MORE* important
since it describes environments like Windows, JVM/Dalvik, and iOS in the
hands of the client--and you can't change that.
This is not just about NATs.
If you need a kernel change, your proposal is toast because it will
never work on Windows, Android, and iPhones. And that accounts for ...
what ... 99+% of all net connected devices?
-a
