On Fri, 30 Apr 2010 01:01:59 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > If the sender->receiver pipe can hold N bytes and the sender
> > is streaming (that is, keeping the pipe full), the sender
> > *will* be ahead of the receiver by N bytes. So a *streaming*
> > protcol has to allow it to be N bytes ahead.
>
> i don't think this is the normal definition.
>
> > Even if you have one ack per message, in a sliding window of
> > N messages (or bytes), the sender is allowed to get ahead of
> > the receiver by upto N more messages (or bytes). Here I am
> > not concerned about in-order delivery (though typically
> > people assume this when they talk about sliding windows).
>
> a sliding window is just a particular implementation  what's
> required is many messages in flight.

I was using sliding window as a shorthand for "allowing the
sender to be N bytes or messages ahead without regard to
sequencing" but yes, the definition I used  is not the
generally accepted defn so I will use yours!

> i don't see any reason why 9p couldn't use some of the same
> congestion control ideas.  the trick would be to feed back packet loss
> detection and retransmission info to the point where file io gets
> turned into rpcs—the mount driver

Agreed -- sort of what I meant by "I hope 9p evolves".
Though I'd probably stick this in a layer below 9p. It can
backpressure a 9p client if it tries to send too much (either
by blocking or returning with equiv of EWOULDBLOCK).