Re: UDP encaps for SCTP and SCCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fred,

I can understand in general your point that things should not be done multiple times.
So you argue not to have a UDP and SCTP/DCCP checksum and not to duplicate the port
numbers. I would like to address these suggestions individually:

1. Checksum
   SCTP uses a 32-bit CRC32c which is much stronger than the 16 bit UDP checksum.
   Therefore only using the UDP checksum doesn't make sense.
   In the first version of the SCTP/UDP encapsulation implementation of
   FreeBSD/Mac OS X I just did not use the UDP checksum but relied only on the
   SCTP one. But what do I gain? Most NICs do UDP checksum offloading, so I
   just enabled it. For SCTP/UDP/IPv6 I was required to so anyway.
   For DCCP this is different. They use the same checksum as UDP, but allow
   for partial coverage. So maybe UDP-light might be what they prefer. Not sure.

2. Port numbers
   The basic question is: Why do you want to encapsulate SCTP or DCCP in UDP?
   I see two reasons:
   (a) Being able to communicate through NATs which do not support SCTP or DCCP.
   (b) Being able to implement SCTP or DCCP on hosts which do not allow
       loading kernel modules, replace the kernel or even use raw sockets.
       The iPhone is one example...
   If you want to address (b), you can use UDP port numbers also for DCCP and
   SCTP port numbers. But if you want to address (a) the situation is different
   for SCTP. This is because SCTP support multihoming and each SCTP end-point
   has only a single port number. So the NAT boxes on different paths might
   modify the UDP port numbers in an uncoordinated way, but SCTP still expects
   a unique SCTP port number. Therefore, at least for SCTP and the usage szenario
   (a), requires both port numbers: the UDP ones and the SCTP ones.

Best regards
Michael
On Apr 27, 2010, at 11:55 AM, Fred Baker wrote:

> From my perspective, I would prefer to run a native encapsulation rather than host it in UDP. If one wants a UDP encapsulation, I have no opinion on which of the choices to make, but I would suggest a characteristic you want to have. There is no point having UDP ports *and* SCTP/DCCP ports, and no point in having a UDP checksum *and* an SCTP checksum. I would recommend removing the duplicated functions from the interior protocol and relying on UDP's counterpart, even if it is inferior, as it will be more readily deployed.
> 
> On Apr 27, 2010, at 10:42 AM, Michael Welzl wrote:
> 
>> Hi,
>> 
>> Okay, I herewith speak up: yes I want to see UDP encapsulation for both these protocols
>> (but right now I'm not sure which one).
>> 
>> Both SCTP and DCCP are useful - if there was no consensus on that, ever, these
>> groups would never have been formed, and the protocols would never have
>> been developed.
>> 
>> Now, they are not used much (on the Internet involving NATs); at least
>> DCCP isn't. That's a problem. UDP encapsulation is a way to try to
>> solve this problem - and saying that we shouldn't do this because the
>> protocols aren't used is a bit stupid, isn't it?
>> 
>> To repeat this more clearly and bluntly:
>> 
>> tool X isn't working well => noone uses it.
>> So let's not fix tool X because noone uses it anyway.
>> Hmmm...
>> 
>> Cheers,
>> Michael
>> 
>> 
>> On Apr 27, 2010, at 9:47 AM, Lars Eggert wrote:
>> 
>>> Hi,
>>> 
>>> please keep this discussion focused on which approach we should follow for UDP-encapsulating DCCP and SCTP.
>>> 
>>> I'm happy Lloyd posted his views. I'm hoping other community members will speak up as well. If I were asked to characterize current consensus, I'd probably say "disinterest for either approach." (Which would be fine, but doesn't quite match the earlier feeling I got from the community, i.e., that we do want UDP encaps for these protocols.)
>>> 
>>> Lars
>> 
> 
> http://www.ipinc.net/IPv4.GIF
> 
> 



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux