> 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. aoe for example, has a maximum outstanding (set by the target). with good client-side congestion control, tracking a window is not helpful. the client (sender) knows best. aoe has no sequence number; just a tag. the target (receiver) just echoes tags and is allowed no interpretation. they work like fids. i don't think this qualifies as a sliding window. yet the tcp congestion algorithm works well with this setup. multiple gbe links can be saturated and yet congestion is still handled. 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 - erik
