RE: Urgent as Framing Hint

[julian_satran@il.ibm.com]

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

"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_____________________/
>
>
>
>