Subject: RE: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt

From: "Culley, Paul" <[email-masked]>
Date: Tue, 24 Sep 2002 19:07:16 -0500

I see nothing about the included text that requires a synchronous hold off of the App until the data is delivered.  In fact, an asynchronous method is specifically suggested "a more sophisticated implementation...".  And there is nowhere in the text a "MUST" that says the application must be blocked.  Unless you can show some more specific text in a standard or RFC than this, I think that a valid implementation allows modifications of the user buffer before the ultimate user is informed that the buffer is fully ordered.

Paul Culley
HP Sr. Fellow
281-514-5543

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, September 24, 2002 4:55 PM
To: Talpey, Thomas
Cc: Culley, Paul; [email-masked]
Subject: Re: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt

Talpey, Thomas wrote:
> At 11:11 AM 9/23/2002, Joe Touch wrote:
> 
>>>Culley, Paul wrote:
>>>But I suspect that there are
>>>well respected TCP implementations that do the same (what happens if
>>>my app peeks into it's receive buffer before Sockets returns it?).
>>
>>The application should be blocked until TCP releases the buffer. That's 
>>what locks are for. To do otherwise would be to violate TCP semantics as 
>>explicitly stated in the RFCs.
> 
> 
> That is implementation, not protocol.

See RFC793, P47 (or 48 - I can't see ^L's), Sec 3.8:
     Receive

         Format:  RECEIVE (local connection name, buffer address, byte
         count) -> byte count, urgent flag, push flag

         This command allocates a receiving buffer associated with the
         specified connection.  If no OPEN precedes this command or the
         calling process is not authorized to use this connection, an
         error is returned.

         In the simplest implementation, control would not return to the
         calling program until either the buffer was filled, or some
         error occurred, but this scheme is highly subject to deadlocks.
         A more sophisticated implementation would permit several
         RECEIVEs to be outstanding at once.  These would be filled as
         segments arrive.  This strategy permits increased throughput at
         the cost of a more elaborate scheme (possibly asynchronous) to
         notify the calling program that a PUSH has been seen or a buffer
         filled.

 > Certainly incoming data is not valid
> until the buffer is released ("delivered") by TCP. Whether the buffer is
> validly within the receiver's address space, or how it is populated, is
> quite another story and one which the protocol by itself cannot dictate.

See above. It is explicitly required by the protocol.

> Would a TCP be non-compliant simply because it might happen to store
> data in a buffer accessible to an application?

Yes. TCP that allows writes to non-locked buffers is non-compliant, 
notably because the semantics is visibly different from the application.

> That would rule out most
> embedded stacks, as well as optimized direct I/O models such as storage
> or shared memory.

I'd be surprised if embedded stacks didn't have lock bits on their 
buffers; even embedded systems have pseudo-OS protection capabilities. 
Direct I/O/shared memory doesn't preclude locks either.

Otherwise, it depends on whether the application can be changed; if the 
system is bundled, then the violations in semantics aren't tickled by 
the application, so the system is OK. If the application can be 
arbitrarily rewritten, then no, it would not be a compliant TCP.

(that doesn't mean anyone has necessarily noticed yet - there are plenty 
of TCPs thought to be compliant that later were found to have 
non-compliant bugs)

Joe

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 24 Sep 2002 18:51:44 -0600

Paul,

I agree.  POSIX Asynrhonous IO is not only an example but probably
what the text was intended to permit.

--brian

On Tue, 24 Sep 2002, Culley, Paul wrote:

> I see nothing about the included text that requires a synchronous hold off
> of the App until the data is delivered.  In fact, an asynchronous method is
> specifically suggested "a more sophisticated implementation...".  And there
> is nowhere in the text a "MUST" that says the application must be blocked.
> Unless you can show some more specific text in a standard or RFC than this,
> I think that a valid implementation allows modifications of the user buffer
> before the ultimate user is informed that the buffer is fully ordered.
> 
> Paul Culley
> HP Sr. Fellow
> 281-514-5543
> 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Sep 2002 21:50:24 -0700

Culley, Paul wrote:
> I see nothing about the included text that requires a synchronous
 > hold off of the App until the data is delivered.  In fact, an
 > asynchronous method is specifically suggested "a more
 > sophisticated implementation...".  And there is nowhere in the
 > text a "MUST" that says the application must be blocked.

1) synchronous != locking

2) it explicitly mentions that
	a) synchronous would block until the buffer was filled
	b) asynchronous would use some other scheme to notify
	the app when a buffer was filled
	
	there are other indications:

RECEIVE: (circa pg 57):
...
       If insufficient incoming segments are queued to satisfy the
       request, queue the request.
...
       When the TCP takes responsibility for delivering data to the user
       that fact must be communicated to the sender via an
       acknowledgment.

That last one seems the clincher on the point, BTW.

3) the MUST/SHOULD/etc conventions postdate this RFC

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 27 Sep 2002 08:20:47 -0400

>	a) synchronous would block until the buffer was filled

-----v

>	the app when a buffer was filled

-----^

Precisely! The buffer is filled by TCP and the application is signalled
when TCP considers the data valid (i.e. right side of window has
passed, RFC793 even suggests PUSH seen).

In the synchronous case, this signal is the unblocking of the caller,
in the asynchronous case, it's some type of event notification.

This is precisely what is being proposed in MPA - I still don't see
why you consider it forbidden by RFC793.

MPA in effect separates the control and data paths. It seems that
perhaps you argue the presence of data is in fact the control? It's
not - the right side of the window (still) performs that function.

Tom.

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Sep 2002 07:57:00 -0700

>>That last one seems the clincher on the point, BTW.

In the first case, it isn't necessarily that TCP is being permitted to 
place data with gaps in the buffer; it may be that the buffer is only 
partially filled. The second part - that says that data delivered to the 
user must be ack'd - is key. TCP doesn't ack data until all data prior 
has been received.

Joe