Subject: more on NFSv4 over UDP

From: [email-masked]
Date: Mon, 25 Nov 2002 17:29:29 -0500 (EST)

Hmm, this has tickled some tired old brain cells. I now remember that,
in order to get the RTT estimator to work half decently for UDP, I needed
to separate the RPCs into categories (big vs small, basically). With the
compound RPC used for V4, this isn't going to be so simple. I think the
client will have to remember which OPs are going into the RPC (such as
read or write or...) so that the RPC can be categorized.

Testing the estimator was kinda fun. I just logged the estimated RTT and
actual RTT for all RPCs when talking to a server (using a large fixed
value for the actual timeout). Graphing the logs, I could see whenever
the lines crossed indicating the estimator had been too agressive. I had
a heap of these graphs before I was done. (An example of one of these
graphs and the results I got are in pub/nfsv4/oldnfspaper.ps that you
can get via anonymous ftp to snowhite.cis.uoguelph.ca if you're interested.)

Anyhow, I'll have to look at the BSD client someday and maybe try the
above again, to see if a decent estimator can easily be done.

Sounds like fun, rick

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 25 Nov 2002 17:57:26 -0500

Some tired old brain cells awakened on this side too! The OSF/1
NFSv3 UDP client performed congestion control and exponential
retry backoff very closely indeed to TCP's.

Congestion control was tricky since ops have variable size, this
leads to interpretation since for the server, ops are more important
than bytes. Also, in contrast to your message here I discovered
that the class of op was more important than size. Non-idempotent
ops (especially modifying directories) were a sure thing to require
additional leeway, with write ops only somewhat behind.

However - as long as a reasonable mix was being offered by the
client, the variance calculation in standard VJ congestion took care
of avoiding needless retries, for the most part. The per-op RTT
estimator wasn't always helpful - probably even less so today as
faster servers reduce normal response time to below the minimum
RTT in any case.

Personally, I would be tempted to interpret "server implements
congestion control" as "server follows client". The server doesn't
really have an ack available to it to pace its congestion - and to
use client UDP retries as a hint is at best an imperfect congestion
signal, with a very long delay loop.

Tom Talpey.