RE: A Transport Protocol Without ACK (resend)

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

Matt,

You are imagining the end of the Ethernet cable is connected to a mythical
beast that actually contains the sum of all storage.  In reality, there will
be many cables heading out of this hydra each acting as a buffer to yet
another buffer.  The end of the Ethernet cable is not the end for the
packet.  Should one such cable be allowed to consume all buffer space?  It
would not be a good design to assume IP flow control will maintain buffer
depth to these sub-nodes.  Stopping flow is truly the end should it be that
a cable was unplugged.  This design will also ensure everything runs at the
slowest cable rate.

Doug

> -----Original Message-----
> From: Matt Wakeley [mailto:matt_wakeley@agilent.com]
> Sent: Monday, October 02, 2000 6:07 PM
> To: Douglas Otis; IPS Reflector
> Subject: Re: A Transport Protocol Without ACK (resend)
>
>
> Doug,
>
> What good does it to do bring up "buffer to buffer" flow control when the
> ethernet does not have such a thing?
>
> If all commands on an iscsi session were sent on their own TCP connection
> separate from data, then if the SCSI fifo becomes full, it will
> stop reading out
> of TCP, which will close the window on the sender, which will
> stop commands.
> That's end-to-end.
>
> -Matt
>
> Douglas Otis wrote:
>
> > Matt,
> >
> > You would not want an End-to-End scheme.  You would want a scheme that
> > prevents any node or sub-node from over-flowing.  That is
> accomplished by
> > Buffer-to-Buffer control.  The present scheme now in place is
> with a rough
> > approximation of command space with any excess data discarded
> as required.
> > This makes for a lossy channel and one that does not allow control at a
> > specific sub-node that may be at its limits.  Restrain the depth of the
> > sub-node with specific control.  Just 8M-byte of FIFO will represent 100
> > millisecond of delay at FC speeds.  A token credit scheme
> ensures no node
> > ever gets to a point of dropping frames in addition to allowing
> maintenance
> > of the FIFO depth.  Should a sub-node fail, only that node
> stops functioning
> > rather than everything being hung until resolution.  A sizable
> short-coming
> > among many others in aggregating everything into this common scheme.
> >
> > Doug
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > > Matt Wakeley
> > > Sent: Monday, October 02, 2000 10:44 AM
> > > To: ips@ece.cmu.edu
> > > Subject: Re: A Transport Protocol Without ACK (resend)
> > >
> > >
> > > Douglas Otis wrote:
> > >
> > > > I agree, XON/XOFF would not work.  A credit token scheme
> > > similar to FC Class
> > > > 3 would.
> > >
> > > FC class 3 does not have an end to end "credit token scheme".  It
> > > (class 3 bb
> > > credit) is simply a credit mechanism between a node and it's
> neighbor node
> > > (the
> > > switch port) on whether the node can receive a frame.  This
> means that the
> > > fabric has buffering inside it, and will hold onto a frame if the
> > > destination
> > > node does not have room for it.  Thus, if the receiving node
> > > temporarily runs
> > > out of buffers, it will withold credit from the switch port.  The
> > > sending node
> > > doesn't know that the receiving node has run out of buffers,
> so the fabric
> > > buffers fill up with undeliverable frames.
> > >
> > > -Matt
> > >
>