Subject: RE: more on NFS over TCP and priorities

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 10 Dec 2002 10:56:34 -0800

Probably so, but remember we are talking about some extreme
conditions.  If the goal for V4 is to work well on really crummy
networks, and while that may not be what the documents say,
I think that's what they mean, then we wind up with issues 
like the one Brent raised abut a network where the time
to send READ response is such that the issuer of LOOKUP 
may feel aggrieved when his response gets stuck behind it.
>From there, we naturally got into a discussion of a number
of related QOS issues.

Of course the best way to avoid contention on slow narrow
links is to avoid sending messages in the first place,
which reminds me that I sort of promised to get out a
document that lays out possible delegation extensions
that might be delivered in a minor version so I'll try to
get going on that.

-----Original Message-----
From: Talpey, Thomas [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 1:27 PM
To: [email-masked]
Subject: re: more on NFS over TCP and priorities

Isn't this all just a QOS discussion? I'd think there is plenty
to leverage without resorting to packet shaping in NFSv4?

Tom.

At 11:05 AM 12/10/2002, [email-masked] wrote:
>> Though a scheme that prioritizes packets according to their
>> size seems eminently fair.  That's essentially what you have
>> with multiple connections: even though the bandwidth is shared
>> and finite, shorter packets can slip by the longer ones, simply
>> because long packets take longer to transmit.
>
>Agreed. But there is a difference between "can slip by" and "always goes
>first". If you have two TCP streams and don't give an absolute
>priority to one over the other, I think it should be ok. (The classic
>priority queue strategy says the higher priority job/packet/... always
>goes
>first, and I thought that's what was being considered originally.)
>
>Have fun with it, rick