Hi Pasi, See inline... Tom P. > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx] > Sent: Thursday, February 18, 2010 6:15 PM > To: Phelan, Tom > Cc: DCCP working group > Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt > > 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? > [Tom P.] The purpose of short sequence numbers in DCCP-STD is to reduce header length. Supporting short sequence numbers in DCCP-UDP doesn't reduce the header size. The purpose of long sequence numbers in DCCP-STD is to reduce the probability of a blind attacker correctly guessing the sequence numbers in use. So in my view short sequence numbers are more of a bug than a feature, and not supporting them in DCCP-UDP is the better solution. > 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. > [Tom P.] I could be convinced to remove support for partial checksums, but I'd like to see more discussion. My original version of DCCP-UDP didn't support partial checksums and this was added as a result of comments on the original version. > 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) > [Tom P.] Yes, I can see the need for more discussion of this. > 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? > [Tom P.] I'll try to think of a better term for this. > 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. > [Tom P.] OK > - Pasi
