Re: Protocol and port fields in selectors

[Joe Touch <touch@ISI.EDU>]

sakari.poussa@nokia.com wrote:
...
>>It seems dangerous to let the transport protocol field 
>>completely float 
>>but to pin down the port number. There is no universal allocation of 
>>ports except relative to a transport protocol; there is no guarantee 
>>that new transport protocols (DCP, SCTP, etc.) will allocate 
>>ports with 
>>the same meaning.
> 
> In 3G/IMS SIP case, the mobile phone binds to the same local port
> for TCP and UDP. For the remote ports, the SIP uses 5060 for
> both TCP and UDP. So in this case, the local&remote ports 
> are the same for both protocols, and that's why there is
> temptation to use wildcard for the protocol field. 
> 
> So it would work for this application, and may not be literally
> according to the spec., but why do you think it is dangerous?

What happens if/when those ports are used by a new transport protocol, 
e.g, for an application of which you are not aware?

>>At best, though, it seems like this cuts the database down by a factor 
>>of 2; is there that much utility to such an optimization?
> 
> That is actually the whole idea; to reduce the number of SAs. Since
> we are talking about several hundred thousands of SAs, cutting the size
> in half reduces the memory requirements (a lot) and improves performance.

That's purely an implementation detail. It seems sufficient in this case 
to implement it as an extra bit that says "TCP and UDP", rather than to 
leave it as a completely open wildcard.

Joe