On Apr 7, 2010, at 7:26 AM, Phelan, Tom wrote:
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.
Ok, this is fair reasoning. But still, as a matter of design
principle, I think it is a little unusual that when receiving a packet
for a protocol, the receiver would need to consider what was the
previous header in order to parse the current protocol header. Ideally
one might want to use the same DCCP implementation regardless of
whether the packets go inside IP or UDP. But I'd be interested to hear
what others think.
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.
There is a possibility that changing the semantics of UDP length field
breaks UDP packet handling in some implementations.
A comment was made in the last meeting (if I remember right), that
this issue was discussed earlier with UDP-Lite, and then IETF decided
to go with different protocol number. So why would the decision be
different now?
- Pasi
