RE: Urgent as Framing Hint

["Douglas Otis" <dotis@sanlight.net>]

> Dear Mr. Otis,
>
> You are a category by yourself - as the members of the IPS know since long
> and the subscribers of end2end will learn soon.
>
> For the sake of the list it would be worthwhile if you could complain with
> 2 simple rules:
>
> - read carefully a note before you answer
> - write only about things you understand
>
> Both you and all the list members will gain - you some free time and the
> list a lot of bandwidth.
>
> As for this note per-se - as it was pointed several times in the pas data
> placement is all about
> placing data in the buffer while data delivery is when the socket call
> returns (or end is posted if async. I/O is supported).
>
> Julo

Dear Mr. Satran:

I have read your note and I must admit I do not understand it.  You are
aware of the indicated need for "TCP Framing" to handle the event when a
segment is lost as clearly indicated within the iSCSI proposal.  Your
cryptic comment provides little light on this subject.  Could you take a
moment to explain how you intend to use this "TCP framing" with a simple
outline otherwise I will waste bandwidth guessing.

I fully understand the 'excuse' that this is the same as Zero Copy TCP but
as several people have indicted, TCP does not need framing for Zero Copy.  I
can only surmise from the minimal details provided and by the comments of
Marjorie Krueger that the intent is to run iSCSI specific code upon receipt
of each TCP segment at the designated port to steer data to SCSI related
buffers.  This is to remove the secondary copy process normally done by the
iSCSI application.

I understand the reasons.  I also understand there are many details not
being shared with the group such as an answer to the question that I asked.
How would you indicate upon "delivery" which segments have been properly
parsed and had the data redirected?  Explain how your double-speak makes a
modification of TCP not a modification of TCP.  Surely you are not
suggesting that the only important aspect of TCP is when the socket call
returns?

Your free time and bandwidth loving friend,
Doug


> "Douglas Otis" <dotis@sanlight.net> on 01/12/2000 19:07:54
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, "Werner Almesberger"
>       <Werner.Almesberger@epfl.ch>
> cc:   end2end-interest@ISI.EDU
> Subject:  RE: Urgent as Framing Hint
>
>
>
>
> Julo,
>
> > I broad lines I see what you mean but:
> >
> >
> > -packet don't have to be accepted (in the sense of delivered to the
> > application) out of order
> > so no socket option is required
>
> The iSCSI application and not TCP is handling interpretation of the iSCSI
> stream.  You have already delivered this information to the iSCSI
> application even if only for data dissemination.  It would be
> beneficial to
> share such an outline of your envisioned scheme so that it can be
> reviewed.
> It would appear you wish to embed a parsing routine attached to
> iSCSI ports
> within the TCP stack to act as a data redirector.  I do not wish to be
> picking nits, but in your view, how would you indicate upon "delivery"
> which
> segments have been properly parsed and had the data redirected?
>
> Doug
>
> > -recvmsg has already an option that will stop it at message boundary
> > -window announced is "real" as you have not yet delivered data to
> > application - only placed it
> >
> > Julo
> >
> > Werner Almesberger <Werner.Almesberger@epfl.ch> on 01/12/2000 13:49:55
> >
> > Please respond to Werner Almesberger <Werner.Almesberger@epfl.ch>
> >
> > To:   Douglas Otis <dotis@sanlight.net>
> > cc:   end2end-interest@ISI.EDU
> > Subject:  Re: Urgent as Framing Hint
> >
> > Douglas Otis wrote:
> > > by SCTP.  TCP never made such provisions and to
> retro-actively add this
> > > feature will create substantial impact on existing implementations and
> > > applications.
> >
> > Hmm, 10' API design:
> >   - add socket option or recvmsg flag to enable out-of-order reception
> >   - pass current position in stream in ancillary data of recvmsg
> >   - changes to receiver TCP stack: "add received segment to buffer" code
> >     probably needs to be modified to take into account segments
> >     delivered out of sequence; window announcement needs to take into
> >     account that buffer size may not equal sequence space covered by
> >     buffer; maybe some other dependencies on amount of data in buffer
> >   - changes to sender TCP stack: none that I could think of
> >   - changes in protocol: idem
> >   - changes in existing applications: idem
> >   - effect on congestion control: idem
> >   - effect on flow control: sender may have to wait for window to
> >     advance, although receive buffer is almost empty
> >
> > Note that this is not ideal for applications where late data is useless.
> > That case is more complex, because ignoring lost segments at
> the receiver
> > would have an effect on congestion control.
> >
> > - Werner
> >
> > --
> >
> >
> _________________________________________________________________________
> >  / Werner Almesberger, ICA, EPFL, CH
> > Werner.Almesberger@epfl.ch /
> >
> /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
> >
> >
> >
> >
>
>
>
>
>