Re: SIP API spec

Christian Huitema <> Tue, 26 January 1993 17:53 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06194; 26 Jan 93 12:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06190; 26 Jan 93 12:53 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa17801; 26 Jan 93 12:55 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02403; Tue, 26 Jan 93 09:51:38 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06776; Tue, 26 Jan 93 09:52:35 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA03037; Tue, 26 Jan 93 09:51:20 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12371; Tue, 26 Jan 93 09:52:34 PST
Received: from by Sun.COM (4.1/SMI-4.1) id AA02365; Tue, 26 Jan 93 09:51:14 PST
Received: by (5.65c/IDA-1.2.8) id AA09610; Tue, 26 Jan 1993 18:51:19 +0100
Message-Id: <>
To: Craig Partridge <>
Subject: Re: SIP API spec
In-Reply-To: Your message of "Tue, 26 Jan 93 09:01:24 PST." <>
Date: Tue, 26 Jan 93 18:51:18 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <>
Content-Length: 2431

>Why would an application ever want to set the FLOWID?  I've assumed that
>this is something that is done by the kernel.  Also, I assume it is not
>legit to set the flow ID after connect() is called (i.e. to change flowids
>on the fly).  What do setsockopt() and getsockopt() return in these cases?
>EINVAL?  More generally, specifyng error return codes would be a good thing.


I would not like to reopen the "flow-id" debate just now, but the only thing
we could agree upon was to let it "for further study". There are two extreme
positions on this, which I could briefly portrait as "datagram" and "virtual

According to the "virtual circuit" school, a flow-id is more or less
equivalent to an X.25, or ATM, circuit identifier. Whatever ressources are
needed for the "circuit" are "requested" explicitely at "connect" time. In
this school, there is no need for the application to ever manipulate the flow
id -- which can be captured by your assertion that "I've assumed that
this is something that is done by the kernel.  Also, I assume it is not
legit to set the flow ID after connect() is called".

The datagram school, in the grand old internet tradition from which you are
heretically trying to depart (-), believes that linking TCP connections with
network states such as resource reservations or VC identifications is a very
poor idea. In this line, flow-ids are merely network
layer "resource identifiers". More precisely, the tuple "source-address +
flow-id" supposedly identifies uniquely a resource reservation -- although I
would certainly admit that this is not completely defined, and that one would
love to see a reservation protocol, or an expression on how "flows" can be
linked to groups of stations, e.g. "all nasa users", or whatever. Anyhow, if
you believe that, the flow is merely a tag explaining that you once bought
32.5 MBps of capacity on one particular ANS route, and that you intend to
share that capacity between your applications "as you see fit". According to
this, it is entirely legit to use the same flow for many different
connections, or associations, or to change the flow id in the middle of a TCP

As I said, we will probably not solve the question now. Which is why I find
Bob's spec entirely acceptable -- it merely says "here are the bits that
should go in the next packets". A service that most implemenatations will be
able to fulfill!

Christian Huitema