Hi Tom,
Here are some personal (no hats on) comments on the draft:
Have the benefits vs. disadvantages of defining a different DCCP
header for UDP encapsulation been discussed earlier? The current
method saves some redundant header space, but may add to
implementation complexity in the DCCP side. I can't say if this is a
significant concern, but I wonder if it is a problem that DCCP-UDP
supports different set of features than native DCCP, such as not
supporting the short sequence numbers?
Section 3.3.1: I'm not very fond of the idea of fiddling with the
UDP length field to implement partial checksum logic, and would rather
leave the UDP protocol untouched. I guess my take on the checksum
calculation would be just to do something simple, even if it would
mean that partial checksums were not supported with UDP encapsulation.
Section 3.5: I think the draft needs to say more than this about Path
MTU discovery, starting from reminding about the basic fact that use
of UDP reduces the MTU available to DCCP. Also, I'm not sure how/if
PMTU discovery would work in this case. The ICMP Packet Too Big
would be routed to UDP, and UDP would need to pass this
information over to DCCP somehow (which could be a problem if UDP is
in the OS and DCCP is in the user space)
And couple of nits:
Section 3 says "The basic approach here is to insert a UDP ([RFC0768])
"shim" layer between the IP header and a DCCP packet" -- Is this
really a "shim" layer? It adds a full protocol header between IP and
DCCP, as visible on the wire?
How about changing the name of DCCP-NAT to DCCP-UDP? This is not
explicitly a NAT
interaction mechanism, even though NATs are the major motivation.
- Pasi
