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

From: [email-masked]
Date: Mon, 13 Aug 2001 09:36:26 -0400

> If you were to blink, you may miss this clever "enhancement" of TCP.

Nonsense.  Packet filters are at least 20 years old, and
the concept of linking resource allocation and usage to
individual connections is the better part of a decade old -
among the places it originated was the xkernel project
at the University of Arizona.  That'd be one loooong blink.

> TCP is to become a transport that does not reside on IP but
> works above an Application Layer Director that attaches to
> a socket in the same manner as a
> Packet Filter if one were to interpret your comments.

Sorry, wrong.  Please try to understand the technology
being discussed before criticizing it.  Packet filters sit
below IP, so TCP still sits on top of IP as it always has.
If my comments on dealing with resegmentation are followed,
TCP also gets out of the business of using framing headers.

> This ALD shares dynamic memory allocation vectors indexed by
> application structures which are passed within the sends or by
> means of some out of band link.  Allison assures all is okay
> provided TCP still shows completion based on the sequence of
> delivery.  This assumes the application provides advanced
> reads noting the associated index done in a non-blocking manner.

The memory pointers are passed in receives, not sends, and multiple
threads are an alternative to non-blocking calls.  Out of band
interfaces are not required.  Both Unix and Windows have supported
the necessary receive side APIs for years, and of course these
APIs only support sequential delivery.

> This would also imply such index does not get reused without the 
> application reissuing it.
> If there is a hold-off of acknowledgement due to non-sequential
> delivery, then repeated index usage may also result in an index overlay if
> the index can not be reissued.  How should that be handled? 

Assuming that "index" means "pointer to the receive buffer", it can
only be safely reused after completion or cancellation of the receive
operation that it was originally used for.  This sort of buffer
management is generally the responsibility of the application (user
of the socket interface) -- an application that initiates two receives
at the same time into the same buffer has a bug, and deserves the
garbage that can result.  This is one of a number of things that
programmers using concurrency (threads and/or asynchronous operations)
have to be aware of.

> As you suggested, this indexing can go violently wrong should an
inadvertent
> segmentation land on data sharing the key value.  There is no information
as
> how this error is to be avoided or how it is to recover as noted.

Wait for all the data to show up, and if some of it was inadvertently
put in the wrong place, copy it to the right place.  This can all be
done below the API (without changing it), provided that the API remains
a sequential delivery API.

> It would appear you have greater confidence in the ips wg solving
> these problems, provided they are allowed to wield the knife.

I'm getting tired of you slandering the ips WG because not everyone
there agrees with your view of the world.

--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 09:07:48 -0700

David,

I am aware of Packet Filters, but the technology being discussed to work
with this
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-00.txt
is not a Packet Filter.  At least not one that I have seen.  The problem
being solved is that the placement of data will not be sequential from the
perspective of the application.  It is nice to see that now even IP is out
of the picture as this technique places the application below IP and above
TCP.  Sorry, it was not clear from the draft as how the information was
passed.  I assumed it would likely work in the same manner as an ALG rather
than modifying the socket interface, but then again, those knives are sharp.
I assume you are referring to some Packet Filter API.  It sounds as if you
have found the freedom to do anything with this pixie dust called Packet
Filter.  To suggest that you have greater confidence in the ips group was
not a slander was it?

Doug