Subject: RE: [Tsvwg] ULP Framing and IETF process

From: [email-masked]
Date: Mon, 13 Aug 2001 16:25:10 -0400

> I am aware of Packet Filters, but the technology being
> discussed to work with this draft-ietf-tsvwg-tcp-ulp-frame-00.txt
> is not a Packet Filter.  At least not one that I have seen.

No doubt -- all the Packet Filter references I'm aware of
refer to software, and this one would have to be implemented
in hardware/firmware.  Packet Filters are already capable of
copying packets -- add a notion of "lazy evaluation" of the copy
(i.e., the bits don't get pulled from the hardware until the
Filter has indicated where to copy them to) and one gets this
sort of direct data placement.  Nothing fundamental has been
invented from a functional/ abstract layering standpoint, but
there's a fair amount of engineering involved to get it to run
fast.

> The problem being solved is that the placement of data will
> not be sequential from the perspective of the application.

Sorry, wrong.  An application using a sockets API or something
similar had already better not depend on exactly when and in
what order the bytes go into memory, as there are a number of
reasons why that might not be sequential (e.g., stupid DMA
tricks).  The only thing that's acceptable is to assume that
all the data is there when the API call (e.g. recv) returns.
As long as the API is sequential delivery, the application
perspective is unchanged.

> I assume you are referring to some Packet Filter API.

Nope, what I meant by existing receive-side APIs were
multithreaded sockets APIs on Unix, and Windows.  The
Windows Sockets 2 API can also provide application buffers
to the protocol stack in advance of data arriving.  I
don't see a need to do packet filter API work in IETF.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 13 Aug 2001 16:20:08 -0700

David,

Thank you for the clarification.  Although most packet filters implement a
rather static set of  procedures and do not extensively parse then
separately place data within the packet, this Packet Filter, of which I
think should be called an Application Layer Director to better characterize
its function, brings a tremendous amount of the application into this layer
below IP.  So much so, that with this dynamic interaction between received
data application specific parsing and placement, transport function
modification, and PDU tracking within the send buffer, this changes TCP
dramatically and obliterates any concept of layering.  Whether it is done
using a non-blocking technique or with multiple threads, it heralds network
programming beneath IP where data is to be directed to the associated
buffers.  It is hard to get a handle on the nuances as one can only guess as
how this is to be implemented.  I am pleased to hear that Microsoft already
has this ability to pass buffers within their WinSock2 library.  You also
have an added need to identify these buffers with respect to the application
indexes.

The concern I had with the buffer handling that now takes place between the
ALD/TCP/Application was concerned with an RDMA application.  I am aware that
SCSI has more limited uses of buffers and that limitation seemed to be
reflected in your response.  As TCP will be blocking the release of a
buffer, the ability to regain access is then beyond the control of the
application.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-00.txt

Doug