Subject: various questions about Generic QoS Socket Interface

From: Craig Partridge <[email-masked]>
Date: Mon, 15 Aug 94 10:04:21 -0700

Hi folks:

Thanks for all the notes and comments so far on the socket interface for
QoS.  I've been hoarding up the various questions and now that e-mail is
tapering off, I think I can hazard trying to reply to some of them, in
one note.

First, Bob Durst asked how QoS gets handled by sockets at the server side
(i.e., listen/accept path).

    My working plan is that the receiver checks that the QoS is OK by
    doing a getsockopt after accepting the connection.  The logic is that
    in some cases the receiver won't care about QoS, so we shouldn't force
    a new call into the series.  (For instance, a sending FTP may request a
    QoS but the receiving FTP need never know about the QoS to work properly).
    If the receiver doesn't like the QoS, it closes the connection.

    An open question for me is whether we could allow the listening socket
    to establish a minimum (or max) QoS, against which the kernel could
    do a sanity check on the connection request before creating the new
    socket to accept.  I think this depends heavily on how complex the QoS
    structure is, and I don't think the problem is worth fussing over very much.

    A touchier question is how to handle cases where one wants to examine the
    QoS before actually establishing the connection.  The problem in BSD is
    that an application needs a socket handle (i.e. a file descriptor) to be
    able to reject a connection -- which means one has to do an accept first.
    My recollection is that 4.4BSD hacks the semantics of accept to permit
    examining the socket before the kernel sends back an OK (for TP4), though
    I can't find details of the change in the BSD code.  If possible, I'd
    use this hack.  If not, there are other ways to skin this cat (like a
    blocking getsockopt() option to read the QoS of the socket on the front of
    the listen queue).

Second, the note from Geoff at Lancaster raised several issues some of which
I've revised here to present as questions:

1. is the QoS idea geared to stream data?

    Not intentionally.  My thought had been that for connectionless data,
    the call to sendto() would implicitly force the creation of a QoS to
    the destination of the sendto() call.

2. can this work for pipelines of processes?

    I would hope so.  It seems to me that establishing a QoS on a socket
    over a loopback interface makes perfect sense.

3. can the socket API support direction connections to kernel managed
devices like video cards?

    I think this is a matter of memory management.  Certainly if an application
    can map the video card memory into its memory space, then an application
    can do a send() or receive() from or to the video memory and cause direct
    transfer of memory without going through kernel buffers.  I like this
    approach because it leaves the application in the control path to deal
    with oddities like control instructions from the user.

Third, Gopal at Wash University suggested using QoS structures based on
application classes (isochoronous, etc).

    I confess that personally I really dislike this approach.  It tends to
    create a multiplicity of QoS structures based on (what I consider to be
    arbitrary) taxonomies of applications.  Part of my dislike comes from
    the fact that token-bucket schemes (what ATM and FR use) can express
    the range of applications from isochronous to bursty using a single
    QoS structure.  So I'd prefer a generic structure if we can do it.
    (The major impediment I see is if some new real-time protocol comes up
    with a QoS system which is richer than token bucket and thus we cannot
    easily map from our generic token bucket into the richer QoS space).

Overall, comments were generally positive so I'm going to try to take some
time to put the ideas into a more detailed paper that can be circulated around.

Craig