Subject: [Tsvwg] ULP Framing and IETF process

From: [email-masked]
Date: Sun, 12 Aug 2001 19:10:10 -0400

Doug appears to be confused about a couple of things ...

> Following this week, on the reflector alone, this draft will
> receive last call.  This appears to be a fast track that does
> not need consensus.

As Allison has now made clear, the authors are expected to produce
a revised version that is expected to go to WG Last Call.  Lack of
WG rough consensus generally derails any draft in WG Last Call,
however lack of WG rough consensus usually takes more than one
objector.

> This framing document has been the dream of the ips workgroup
> from the pre-BOF and now appears able to slip into a standards
> track RFC well ahead of iSCSI, the intended application.

Doug's generalization from the positions of a few individuals to
the position of the entire ips WG is incorrect.  In London, the ips
WG was not able to reach consensus on what the iSCSI requirements for
use of "ULP Framing for TCP" should be, and so calling TCP ULP Framing 
"the dream of the ips workgroup" is just plain wrong - in particular,
the requirements of the last paragraph of Section 2 of the ULP
framing draft were one of the things on which the ips WG did not
reach consensus.

I wish Doug were more careful about this sort of over-generalization,
as this is not the first time he's gotten something about the ips
WG wrong on this list, and I really don't enjoy dealing with the
resulting fallout.

Thanks,
--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 02:53:38 -0700

David,

If you were to blink, you may miss this clever "enhancement" of TCP.  You,
Allison, and much of the ips wg have concluded TCP has a serious problem
and, to the benefit of the world, a solution is be offered.  Within a
relatively quiet atmosphere, a substantial "enhancement" to TCP is about to
take place.  With little information, the world is to follow Microsoft's
lead in a design based on their modification of their TCP stack.  Without
information, one can only guess the details of this new concept in TCP.  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.

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.  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?  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.  You have
also requested an improved method of just providing Protocol Data Unit
alignment within the TCP segment without any framing mark.

It would appear you have greater confidence in the ips wg solving these
problems, provided they are allowed to wield the knife.  Each group would be
required to invent the ALD-PDU interaction.  They have their carving knives
out but have not decided on leg, breast or thigh.  Sorry if I have
generalized the concept that the TCP turkey is about to be served up.
Allison did not indicate a need for a revision but rather it has been done
and you should have read it.

Doug