Re: bibliography

[Aman Singla <aman@cthulhu.engr.sgi.com>]

> @Manual{hippi-st,
>   title =        {Information Technology - Scheduled Transfer Protocol
>                   {(ST)} {T11.1/Project 1245-D}},
>   organization = {NCITS},
>   year =         1998,
>   month =        jan,
>   note =         {rev 1.45},
>   comment =      {Scheduled transfers for HIPPI, as a transport
>                   protocol.  Also claimed to work for FC and ethernet,
>                   but I dpn't think anybody's really using that yet.
>                   Separate control and data connections.  Begins with
>                   a setup negotiation, in which the destination
>                   indicates how much data it's prepared to receive.
>                   Mentions that this could be adjusted downward by
>                   intermediate nodes, but no discussion of how.
>                   Assumes very reliable in-order delivery for
>                   efficiency, though should work on packet loss due to
>                   ACKs (apparently, one ACK per data pkt is required).

No there isn't an assumption of reliable in-order delivery. Packet
loss is handled by timeout on the receiver side (or skip in block
sequence if out of order is not enabled) trigerring the
resend of a CTS => as all timeout schemes, has impact on performance
when there is packet loss.

>                   Targetted to minimize the work on receive.
>                   Transfers consist of blocks which consist of STUs,
>                   which I think correspond to packets.  Must be a
>                   power of two in size.  Some support for striping,
>                   including fan-in and fan-out, but still looks incomplete.
>                   Headers indicate when the upper-layer system should
>                   be interrupted.  Some support for negotiated
>                   out-of-order delivery, but I'm not sure how that
>                   works with the max received index in the ACK packets
>                   (ACK pkts are primarily indicators of buffer
>                   availability for flow control, really CTS).  Says it

CTSs are an indication of buffer availability. Out-of-order delivery
is simply handled by each incoming data block having an address of
where the data is supposed to go, and the protocol doing book-keeping
at the block level. The ACK, if by ACK you mean the RSR, is normally
for the end of the transfer (transfer->blocks->stus) to signify
receipt of all blocks to the sender.
RSRs with max index recd. are also used for Persistent Memory
short message Put and Get sequences (which are different from the
Read/Write sequences for Long Messages/Transfers which are being
discussed here) as the sliding window ack mechanism over unreliable
media.

>                   assumes low latency.  No discussion of how packets
>                   might overlap in transmission; diagrams show a
>                   series of data pkts then a series of CTSes.  Thinks

Basically multiple outstanding CTSs are allowed => CTSs from the
receiver to the sender are in a pipeline with the data flowing from
the sender to the receiver. This thus hides the CTS latency for all
blocks except the first one.

>                   it ld be used to carry TCP/IP traffic, but I view it
>                   more as a transport protocol and would be curious to
>                   see ST over IP.  Despite not being an Internet

That is a true observation. We have ST working over IP over Gigabit
ethernet working on Irix and Linux. We've been releasing the linux
code to the open-source community.

>                   protocol, bows to the IANA for selection of things
>                   like well-known port numbers for services.},
>   location =     { rdv : folder : hippi },
>   read =         {1998/1/30},
>   URL =          {http://www.cic-5.lanl.gov/~det/dST145.pdf}


Thanks,

:a