Re: SIP API spec

[Bob Gilligan <[e-mail]>]

> In your spec, you mention a "SIP_FLOWID" option. When doing our
> implementation, we do indeed feel the need for such an option, but
> also for at least three other options:
> 
> 1- An option to set the "Maximum number of hops" field in the header,
> analoguous to the IP_MULTICAST_TTL option that was defined for multicast IP.
	
The BSD "net-2" release defines a number of new options at the
IPPROTO_IP level, including:

#define IP_TTL          4       /* int; IP time to live */

In our SIP/IPAE prototype implementation, we have this option set the
SIP hopcount (if sending raw SIP), or the IP TTL field (if sending raw
IPv4), or both (if sending IPAE).

Do you think we should have a separate setsockopt() option to set
the SIP hopcount?

> 2- An option to set a "path MTU". That can be useful for datagram
> sockets which have to use the reassembly protocol; it instructs
> "sip_output()" to send a sequence of segments instead of a single
> datagram.

How a UDP application participates in the path MTU discovery is an
interesting question.  In the Solaris 2.1 TCP/IP implementation, IP
does path MTU discovery for UDP sockets transparently to the
application.  IP keeps a per-IP-destination route cache that has a
path MTU associated with it.  If an application sends a message that
is larger than the path MTU, IP will fragment it at the source using
the path MTU as the fragment size.  This is nice since the application
need not worry about the the path MTU, but it still results in the
host sending fragments.

The philosophy in SIP is that all UDP applications should participate
in path MTU discovery, and that hosts should generally not send
fragments.  But for this to work, the application needs to learn about
changes to the MTU of the path, and the application must not send
datagrams larger than the current path MTU.  We would need to make
some non-trivial changes to the API in order give applications this
information.

One way for the application to learn about changes in the path MTU
would be to invent a new signal -- say SIGMSGTOOBIG -- that is
delivered to the application whenever a SIP ICMP "packet too big"
message arrives.  Along with the signal, we could invent a new
getsockopt() option that would return the "next hop MTU" contained in
the most recent SIP ICMP "packet too big" message.

To support those existing unchangeable UDP applications that send
large datagrams, it might make sense to define another setsockopt()
option that asks the SIP layer to include the fragmentation option in
outgoing datagrams.

> 3- An option to set a "source route", using the loose source route protocol.

Good idea.

> 
> Note that the isolation of one specific "SIP_FLOWID" option is contradictory
> with the current architecture where:
> 
>      A single socket option, IP_OPTIONS, is supported at  the  IP
>      level.   This socket option may be used to set IP options to
>      be included in each outgoing datagram.  . . .
> 
> So, we clearly have a design choice here. Either individual socket
> options for Flow-id, TTL, MTU and LSR, in the "multicast" tradition,
> or one global SIP_OPTIONS, like the old IP.

I think that the SIP_FLOWID and IP_TTL setsockop() options are a
little bit different since they set fields in the main header, and not
the "options" part.  But also, Steve Deering's multicast extensions
for BSD and the net-2 additions have set a precedent for having at
least a limited set of setsockopt() options that set specific fields
of the packet.

But what should we do about SIP options that are not yet defined?  Do
we need a generic SIP_OPTIONS setsockopt() option?

> As far as a new name for "gethostbyname" is needed, we had chosen
> "sip_name2addr" in our "bind" code -- which we ought to adapt to the new
> interface specification!

It might make sense to pick a name that doesn't have "sip" in it.
That way, it could be used by other transport protocols without
confusion.  Craig Partridge suggests hostname2addr(), which seems
reasonable to me.