Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement violates TCP.)

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Vern Paxson wrote:
> 
> > I don't even think that an implementation would need to use SCTP streams
> > to get this effect. Since each DATA chunk has a bit marker on it to
> > specify if it is the Begining of a message. The streams only make it
> > easier to multiplex non-related commands without head of line blocking,
> > a valuable option to iSCSI I might add but not needed for framing....
> 
> But I'm arguing that marking just the beginning of messages isn't really
> what you want, because then when you receive the middle of a message without
> having first seen its beginning, you don't know what to do with it.  If,
> on the other hand, you use a separate SCTP stream for each ISCSI message,
> then the stream # plus the stream sequence number would let the receiver
> know exactly where to demux an out-of-order segment ... right?
> 
Ok, I got you.. this would be even better... Since no matter if a
iSCSI header was present or not, you could know where the message
belonged... no NIC memory every needed.... Great idea...


The proposal that was being put forward with the Urgent mark was
along the lines of:

If I miss a segment with a header
Store that segment in NIC memory
When I read the next segment marked with a header
Store that message where it belongs...

I was thinking this could be done with the BE bits.. but even
at that the messages could not be processed out-of-order... i.e.
when you get the above you must wait...

Your idea makes it ALWAYS:

Store the message in user memory where it
belongs, no matter what. No NIC memory would
ever be needed ...


Much superior...

R
-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)