Subject: RE: Fw: [Tsvwg] ULP Framing for TCP

From: "Douglas Otis" <[email-masked]>
Date: Tue, 7 Aug 2001 01:52:46 -0700

All,

From the level of impact this draft wishes to make, I have the feeling there
are many that have yet to understand the level of changes implied.  There
has been little discussion of this topic on the reflector as well as a few
that stood up to object to this concept when first introduced.  Be that as
it may, this draft has received tsvwg status and is being discussed in ips
only.  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.

This draft changes the hardware interface at the adapter, the API at the
socket, and the application that interacts with these changes.  It also
breaks the various security gateway products.  Some side effects happens
when OS vendors expose the raw socket for these changes.  To achieve a frame
aligned PUD, TCP is changed from a byte stream into a PUD stream.  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.

This draft does not lend any standardization into the mix however.  It does
not document how the modes are negotiated, what the interface changes are at
the sockets, the hardware interface, or what can be done to repair the
damage created to those hapless middle boxes.  Compared to emerging
standards that do provides these features, these issues have been covered to
a great extent.  It provides the concept of extending the alignment to
include an improved error handling which is not even covered by this framing
document.

It would appear there is a mixed message.  For a framing protocol, either
change TCP using this draft, or use SCTP.  There is going to be extensive
changes made to support either.  With SCTP however, there is a comprehensive
solution, and with this draft, there is a theory that this will even work
with only a key to indicate a problem at the hardware level.

Doug

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stephen Bailey
> Sent: Wednesday, June 13, 2001 7:18 PM
> To: [email-masked]
> Subject: Re: Fw: [Tsvwg] ULP Framing for TCP
>
>
> Jim[s],
>
> > > So this ensures that the sender won't knowingly emit a segment with a
> > > payload that will falsely match the key value?
> > > What does the sender emit in this case?
> >
> > The sender would revert to "b." in this case.  See below.
>
> It could also send segments that are guaranteed not to fail false
> positive.  A segment whose data length is shorter than the framing
> header can not be mistaken for a properly framed segment.  This is an
> alternative which will keep the data flowing.
>
> Waiting for the ACKs to catch is my kind of solution to the infrequent
> case (simple and brute force :^), but how do you know that the ACKs
> have caught up?  What happens if a packet (or all the packets, if a
> router is eating fragments?) gets lost?  Do you wait for the last ACK
> or 2*MSL, whichever comes first?  In this strategy, when a packet DOES
> get lost, do you then send PDUs up to an including the next one in the
> stream which is larger than the new MSS, and wait for ACK to that
> point?  In the case where you have a long stream of old MSS PDUs, you
> will be sending them one at a time until you reach the end of what you
> sent before you learned of the path MTU change.
>
> I'm not saying this is a bad idea, I just want to make sure I
> understand the behavior.
>
> > > Is receiver framing behavior (out-of-order data placement)
> ever resumed
> > > and what triggers it?
>
> As long as the sender is always `trying' to send segments that begin
> at a framing boundary, framing should be restored.  Specifically, the
> sender must not cross a framed PDU boundary within a segment.  Given
> that framed PDUs are delivered to the framing layer as a unit, there
> will be no upper-layer demand to send less than a framed unit of data
> so framing should be stable across such interruptions.
>
> Steph
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>

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

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 8 Aug 2001 04:45:10 -0700

Follow-on:

In the previous rant, I used PUD instead of PDU.  The first would stand for
Probability of Undetected Channel Errors while the latter would stand for
Protocol Data Unit.  Sorry for any confusion this may have caused.

Doug