Subject: Re: Anything else not on the issues list?

From: Peter Staubach <[email-masked]>
Date: Wed, 17 Jul 2002 16:22:43 -0600 (MDT)

> 
> Yes, please do this.
> 
> It would make a huge operational improvement if this were
> universally implemented.  I really really care about this
> as a user.
> 

As a user, how do you see these issues affecting you?

As a user myself, I have been unaffected by these issues as far as I
know.  As a developer, they constitute rules which govern my
implementation, but these issues are never visible above either the RPC
or the NFS levels.  They can not be or the implementation is broken.

	Thanx...

		ps

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 17:43:13 -0500

> or the NFS levels.  They can not be or the implementation is broken.

Mike pointed out at least one instance (slow links) where unnecessary
retransmissions can effect perceived and real performance.  It seems
that since the WG has addressed other Internet operation issues
(inclusion of COMPOUND and mandatory security) that this proposal
would also fall into that category.  Applications like telnet do not
retransmit data do they?  Why should the RPC layer (as a user of TCP)
retransmit requests when the connection is still operable.

The other place where this can be helpful is with overloaded servers
and their ability to clear requests.  Why should the server have to do
more work just because it is slow.

-- 
Spencer

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 17 Jul 2002 16:04:27 -0700

> retransmit requests when the connection is still operable.

I don't think the slow link issue has been investigated or quantified.
How do we know that this is a problem - or that this policy will fix it?

> more work just because it is slow.

Not necessarily.  Currently, servers can shed load by dropping requests.
A requirement to transmit NFSERR_DROPPED replies would be more work.

	Brent

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 18:10:38 -0500

> How do we know that this is a problem - or that this policy will fix it?

I will ask it again.  Do applications like telnet retransmit their
data because of a lack of response?  Why should RPC or NFS retransmit
when the link is operational?

> A requirement to transmit NFSERR_DROPPED replies would be more work.

Under Mike's proposal, the server can drop the entire connection if it
is overloaded with work.  The is low overhead. :-) NFS4ERR_RESOURCE is
already available to a server that has exceeded its resource capacity.

-- 
Spencer

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 17 Jul 2002 16:42:21 -0700

> when the link is operational?

You can't know the link state with any certainty until you transmit
something.  The question is: do you transmit some kind of null 
request, or the original request ? 

I believe current practice with most clients is to increase the
timeout significantly when TCP is used - since we assume TCP
will do a better job of handling dropped/lost packets.

If that's insufficient, then it's worth looking
at alternatives, but I don't see the evidence yet.

> already available to a server that has exceeded its resource capacity.

Yes, though rather a radical way to signal a request that's taking
a bit long.  An NFS4ERR_RESOURCE would be much more efficient.

I've always thought the ability of servers to drop requests to be
a simple, straightforward way to deal with transient server problems -
knowing
that the client will just retransmit eventually.  Mike's proposal
just seems to me more complex to implement - and prone to error.

	Brent

---

From: Eric Werme USG <[email-masked]>
Date: Wed, 17 Jul 2002 20:49:53 -0400

Spence wrote:
   Applications like telnet do not
   retransmit data do they?  Why should the RPC layer (as a user of TCP)
   retransmit requests when the connection is still operable.

There are two things in NFS history that were not in telnet history.  (And
telnet has a history - the current protocol was referred to as the "new telnet
protocol" and displaced the "old..." around 1974.)  First, NFS over
UDP does retransmits so there was support for that.  Second, NFS over
TCP has to be able to ride out server crashes, and that means lost
connections, and that means it has to be able to retransmit.  Since NFS
over TCP can retransmit, then it was easy to require it do so to handle
lossy servers.

Perhaps we should encourage the telnet and SSH people to close idle
connections and recreate them when necessary.  :-)  Then we can lean on them
to ride out server crashes.  :-) :-)

I recently fixed an old bug in Tru64 where one of our customers had a grossly
overloaded server.  My implementation creates one connection per mount, and
all the server threads can service any connection.  A client sent a request,
30 seconds later it timed out and retransmitted just as the reply came in
from the server.  Unfortunately, the outgoing socket was full and the client
code blocked waiting for space.  Therefore it didn't take the reply off the
input queue.  Until that happened, no other client thread would be woken
for its reply.  The server stopped processing requests on that connection
and no space became available for the client's retransmit.  So things
deadlocked.

Not having to retransmit would have avoided the situation.  One of my changes
was to use non-blocking I/O on retransmits, the effect being that the client
would simply not restransmit if the outgoing connection was full.  That
was kind of cute.

Instead of allowing the server to silently discard NFS over TCP
requests, I suspect one could readily design something where the
server could close the connection (or mark it for closure later)
without requiring new resources right away.  At this point I think I'd
prefer that over relying on retransmits.  After the above problem, I
considered increasing the timeout - clearly 30 seconds is too short! - but
left it unchanged largely to handle lossy servers.

Also - _are_ there any servers that sometimes discard requests?  Has this
become a non-issue?  I looked into Tru64 a few years ago and I vaguely
remember there was a path where we do that.  I'd have to hunt that down
from scratch, so I won't do it tonight.

The CMU/Harvard telnet was implemented inside the TOPS-10 kernel, err, monitor.
I used a coroutine to track protocol decoding.  Resources necessary for that
were miniscule compared to most NFS ops, but I don't remember what I did
when resources were unavailable.  Or if resources could become unavailable....

	-Ric Werme

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 19:55:53 -0500

> would simply not restransmit if the outgoing connection was full.  That

So we have an example where the proposal would have been helpful.

> from scratch, so I won't do it tonight.

Yes.  Do we know of servers that absolutely need this for TCP
connections?  Also, NFSv4 is a new beast and it can/does have
different requirements in many places and RPC/TCP usage can be another
of those with effecting the v2/v3 code base.

-- 
Spencer