►
From YouTube: IETF111-NFSV4-20210730-2130
Description
NFSV4 meeting session at IETF111
2021/07/30 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
B
C
B
B
D
B
So,
if
you're
here
yesterday
welcome
to
the
nfs
version
for
working
group
part
two,
this
is
ietf
111
in
case
you
were
unaware
of
where
you
were.
We
have
gone
through.
Half
the
agenda.
Sorry
dave!
I
just
want
to
get
this
out
of
the
way,
because
I
gotta
tell
the
note.
Well,
we
have
four
remaining
sections
to
finish
today.
Chuck
lee
will
be
leading
most
of
them
on
signing
rdma
over
rpg
over
rdma
docs
nfs
version,
four
enabling
use
of
quick
and
discussion
on
future
work.
B
B
These
cover
patents
and
code
of
conduct,
and
I,
if
you
are
unaware
of
them,
please
read
the
documents
they
are
make
for
good
reading
participating
in
the
ietf.
You
agree
to
follow
it
process
policies,
but
the
most
important
things.
If
you're
aware
that
any
itef
contribution
is
covered
by
patents
or
patent
applications
that
are
owned
or
controlled
by
you
or
sponsor,
you
must
disclose
that
fact
or
not
participate
in
the
discussion
and
you
are
being
recorded,
written
audio
photograph
records
of
the
meetings
may
be
made
available
and
the
personal
information
that
you
provide.
B
B
A
A
A
We're
not
really
clear
about
who
wants
rpc
over
quick
now
that
we
have
tls
support
for
our
pc.
That's
probably
the
main
benefit
that
rpc
would
see
with
kwik
is
is
a
transporter
security.
There
are
some
other
advantages
as
well.
They
might
not
be
available
immediately,
just
because
quick
is
not
quite
done
yet.
There
are
some
extensions
that
are
that
are
looking
kind
of
interesting
that
might
be
interesting
to
rpc.
A
A
So
I'm
I'm
kind
of
a
quick
newbie,
but
there
are
some
things
that
we've
sort
of
been
looking
at
and
and
and
salivating
a
little
bit
over
one
so
and
I've
listed
them
here
on
the
slide
and
one
of
the
things
that
quick
would
provide
us
is
having
more
than
one
reliable
stream
per
connection,
and
in
that
way
we
could
probably
separate
the
forward
and
reverse
direction.
Rpc
transaction
streams
so
forward
would
be
on
one
stream
and
reverse
would
be
on
another.
A
We
can
also
do
things
clever
things
like
creating
more
than
one
stream
per
connection,
because
each
stream
has
its
own
head
of
cube,
locking
so
blocking
on
one
stream
would
not
would
not
block
a
progress
activity
on
on
another
stream.
So
anyway,
that's
that's
one
of
the
technical
details
that
we'll
need
to
drill
into
on
the
mailing
list,
as
we
absolutely
as
we
drill
into
quick
a
little
deeper.
A
Another
thing
that
quick
might
offer
rpc
is
better
loss,
recovery,
congestion,
detection
and
control
is
more
robust
than
it
is
for
tcp.
I'm
not
sure.
That's
all
that
interesting
for
nfs,
just
because
that
typically
runs
on
on
data
center
networks.
Originally
of
course,
20
years
ago,
when
we
created
nfsv4,
we
had
the
the
lofty
goal
of
making
nfs
a
wide
area
file
system,
and
that's
where
this,
this
kind
of
advanced
error
and
congestion,
detection
and
control
might
be
advantageous
over
wide
area
networks.
A
Also,
it's
it's
pretty
well
known
that
rpc
sec,
gss,
doesn't
doesn't
obscure
the
the
rpc
headers.
Those
are
in
the
clear
once
we
have
tls
or
quick
with
with
with
a
transport
layer
security,
we
would
be
able
to
obscure
the
entire
rpc
request.
Each
of
them
would
be
completely
private
well
and
for
tls
we
still
have
to
have
a
tls
probe
in
the
clear
and
with
quick
tls
is
built
in,
and
so
that
wouldn't
the
client
would
need
to
probe
tls.
It
would
just
be
there:
it's
not
opportunistic.
A
A
A
D
G
Nick
banks
for
microsoft,
main
developer
for
ms
quick,
the
library
that
windows
uses
when
you're
seeing
lots
of
performance
like
I'm,
asking
specifically
what
the
the
target
network
conditions
are
here,
because,
if
you're
going
over
the
internet,
all
tests
we
have
the
internet
is
limiting
factor,
not
the
the
cpu
costs
of
encryption.
So
that's
why
I
was
asking
like
when
you're
talking
about
loss
of
performance
here.
What
is
the
scenario
that
you
expect
to
lose?
So
no,
I
lose
performance.
Yes,
cpu
is
spent
on
encryption,
but
that's
not
necessarily
the
bottleneck.
A
We
think
the
cpu
cost
is
going
to
be
the
limiting
factor.
I'm
also
a
little
concerned
about
scalability
on
the
server
side,
because
the
server
is
basically
going
to
be
spending
a
lot
of
time,
handling,
encryption
and
decryption,
for
you
know,
potentially
thousands
tens
of
thousands
of
clients.
So
we
think
that's
going
to
be
an
issue.
A
A
A
And
nick
has
shared
some
performance
data
in
the
chat
room
if
people
are
interested
in
that,
so
there
might
be
some
benefit
for
situations
where
the
client
does
some
port
mapping
or
other
arcane
things
at
the
beginning
of
connection.
But
after
that,
really
you
know
having
a
two
or
three
handshakes
instead
of
one
is,
is
really
not
much
different,
so
I
don't.
A
I
don't
think
rtt
is
going
to
be
especially
interesting
as
it
is
for
things
like
web
web
client,
where
they're
making
lots
of
connections
all
at
the
same
time.
Over
and
over
again,
we
also
had
a
dream
of
being
able
to
use
datagrams
in
a
reliable
context
and
quick
doesn't
have
reliable
datagrams.
It
has
an
unreliable
datagram
extension.
That's
that's
in
the
works,
so
we're
still
going
to
need
some
record
fragment
framing
that
is
similar
to
what
we
do
with
tcp
streams
each.
A
A
We
need
to
request
appropriate
net
ids.
We
have
two
for
each
of
tcp,
udp
and
rdma.
So
we'd
probably
need
something
like
quick
and
quick
six,
but
we
need
to
discuss
the
guidelines
around
how
rpc
consumers
like
nfs
might
want
to
use
multiple
streams
on
one
connection,
and
then
I
mentioned
the
trpc
transport
nomenclature
at
the
bottom.
I
don't
think
the
itf
has
anything
binding
to
say
about
those,
but.
A
We
have
to
do
something
that
that
describes
connections
that
that
allow
multiple
streams
per
connection-
and
maybe
maybe
we
just
pumped
on
that
and
say
we're
not
going
to
comment,
but
I
think
for
user
space
implementations
that
depend
on
the
ti
rpc
api.
We're
going
to
have
to
have
some
some
some
thought
behind
that.
A
Some
quick,
quick
transport,
specific
issues,
let's
remind
myself.
What's
on
this
slide,
oh
yeah,
I
was
having
a
conversation
with
one
of
the
smb
over
quick
engineers
at
sdc
a
couple
years
ago,
and
he
was
mentioning
that,
because
quick
runs
over
udp,
there's
gonna
have
to
be
some
some
discussion
of
how
an
mfa
server
that
listens
on
udp
ports
will
be
able
to
steer
traffic
to
quick
and
udp.
A
At
the
same
time,
I
think
that's
just
gonna
require
some
some
prototyping
and
then
some
some
language
in
the
in
the
the
transport
document
that
we
that
we
come
up
with
we
can.
We
can
reuse
the
some
of
the
rpc
with
tls
specification,
in
particular
the
alpn
and
certificate
usage
guidelines,
and
that
in
that
document
would
apply
to
quickv1
as
well.
Since
quickv1u
uses
the
tlsv
1.3
handshake
protocol,
that
that
is
something
that
we
can
reuse.
A
I
think
lars
mentioned
that
there
can
be
two
to
the
62
streams
per
connection.
We
could
probably
set
up
an
individual
stream
for
each
slot
in
a
session,
for
example,
if
we
wanted
to
do
that,
we'd
have
to
answer
some
questions
about
what
bind
condis
session
does
now
that
there
are
multiple
streams
and
a
connection.
A
We
also
have
this
issue
about
nfsv4
requiring
a
server
to
drop
a
drop.
The
connection,
if
it
ever
loses
an
rpc
transaction
clients
depend
on
that.
Would
we
change
that
to
be
like
the
the
server
terminates,
a
stream
when
it
when
it
it
drops
of
an
rpc?
We
will
have
to
have
some
discussion
around
that
to
figure
out
exactly
how
rpc
transaction
loss
is
signaled
by
servers
on
quick
transports.
A
A
Maybe
we
need
to
take
that
to
the
that
question
to
the
list,
or
we
could
do
a
quick
poll
here
to
see
if
there's
anybody
who
opposes
beginning
work
on
rpc
over
quick,
I
also
had
a
question:
that's
really
just
due
diligence,
whether
we
need
a
charter
update
for
the
working
group
to
work
on
rpc
over
quick.
I
thought
the
question
was
pertinent.
A
A
F
F
So
if
you,
if
we
would
like
to,
I
mean
so,
I
would
like
to
understand
like
why
why
we
are
doing
it
and
what
what
quantifies
the
gain
we
get
out
of
it
like
what
are
the
problems
that
we
already
see,
that
was
gonna,
that
rpc
over
quick
is
going
to
help
with.
So
what
is
what
is
our
goal
here?
Actually
I
mean,
I,
I
see
your
slides
in
the
beginning.
I
didn't
get
those
like
really
concrete
answers
and
there
is
no
quantifiable.
F
I
cannot
quantify
the
gain,
that's
what
I'm
saying
like
I
mean
I
don't.
I
just
don't
want
us
to
work
with
this,
just
because
this
is
something
cool
to
work
with,
but
we
also
understand
like
what
is
the
achievements
and
what
is
what
what
we
try
to
achieve
here.
So
I
just
want
to
clarify
those
things
to
the
working
group.
A
Now,
that's
that's
absolutely
fair.
I
think
I've
communicated
my
own
fuzziness
on
these
ideas
already.
I
I
don't
have
good
answers
and
I
think
that
you
know
the
initial
slide
I
put
up.
That
said,
it's
not
clear!
Why
we'd
be
doing
this
that
that
that
says
it
all.
We
don't
know
those
answers
yet
and
I'm
not
clear
on
exactly
how
I.
F
Maybe
I
would
like
us
to
actually
have
more
discussions
on
it
on
the
mailing
list
and
we
understand
try
to
do
what
we're
trying
to
achieve
and
what's
gain
we're
trying
to
get.
I
mean,
obviously
this
this
is,
I
mean
you
know
like
I'm.
I'm
super
happy
to
see
like
people
are
picking
up
quick
and
trying
to
do
a
lot
of
thing.
We
had
another
discussion,
a
media
over
quick.
This
is
rpc
work
week.
This
these
are
cool
things
to
do.
Do
I
think,
but
why
and
what?
F
D
A
A
A
A
The
sender
can
gate
it's
its
transmission.
I
did
reach
out
to
to
janna
twice.
I
was
not
able
to
get
a
response.
Martin
suggested
talking
with
him,
but
without
that
I
just
sort
of
went
ahead
and
and
built
something
that
I
thought
would
be
reasonable.
My
co-author
dave
has
looked
at
this
and
and
thinks
it's
it's
reasonable
ahead
with.
We
don't
have
a
location
in
the
header
message
for
the
second
field.
That's
the
only
thing.
That's
stopping
me
from
actually
implementing
it
right
at
the
moment.
F
A
Yeah,
what
I'm
looking
for
is
some
expert
review,
I'm
hoping
that
that
the
language
now
in
the
editor's
copy
on
the
github
is
clear
enough
that
it
that
you
know
it's
just
a
page
or
two
and
will
be
easy
for
someone
to
who
understands
these.
The
theory
here
to
sit
down
and
look
at
and
go
yeah.
That's
that's
good!
No!
That's
stupid!
Do
it
this
other
way.
A
There
was
some
complaint
on
the
list
a
few
months
ago
when
I
brought
this
up
earlier
that
we
need
to
be
careful
not
to
spell
to
be
too
specific
about
the
algorithms
that
are
being
used
by
the
center
and
receiver.
I
hope
I
haven't
crossed
that
boundary.
I
I
hope
the
language
in
the
document
describes
the
protocol
and
and
doesn't
doesn't
really
lock
either
any
implementation
into
into
a
particular
algorithm.
A
As
I
was
looking
over
the
quick
rfcs
recently
published,
I
noticed
that
they
have
ayanna
registries
for
error,
codes
and
transport
properties,
and
I'm
wondering
if
our
pc
have
already
made
version.
Two
should
do
the
same
or
maybe
include
other
aspects
of
the
protocol.
Like
the
message
header
numbers,
that's
certainly
something
we
can.
We
can
take
that
discussion
to
the
list.
We
don't
have
to
go
into
that
here.
A
So
now,
what's
up
for
the
working
group
you're
still
sort
of
waiting
for
prototypes?
I
think
we
have
a
milestone
date
to
deliver
this
document
by
december
of
this
year
this
calendar
year.
I'm
not
convinced
we're
going
to
make
that,
because
there
are
so
many
items
in
this
specification
that
are
new
since
v1.
The
credit
accounting
protocol
is
one
of
them,
but
other
things
like
peer
authentication
and
transparent
properties
and
other
things
or
in
particular
message.
A
A
As
far
as
I
know,
right
now,
the
linux
prototypes
are
the
only
ones.
I
would
like
to
see
a
second
prototype
at
least
brought
to
testing
events,
so
that
we
can
have
some
interoperability,
some
confirmation
of
interoperability,
and
I'm
wondering,
if
maybe
we
should
extend
the
milestone
farther
than
just
maybe
a
year
or
understand
what
the
priority
of
this
work
is,
so
that
we
can.
We
can
focus
on
some
of
the
things
that
that
more
people
are
interested
in
than
just
this
one.
This
particular
new
version
of
protocol.
A
A
A
F
A
A
You
know
an
application
isn't
going
to
want
to
read,
use
the
entire
library
they're
just
going
to
want
to
use
little
bits
of
it,
and
you
know
a
linear
digest
like
md5
or
sha-1.
For
example,
you
know
you've
got
to
read
the
entire
file
to
compute
the
the
the
digest
and
verify
it,
and
the
problem
is
that
that
sort
of
is
not
real.
A
A
Certain
parts
of
the
file
can
be
purged
from
memory
and
that
memory
reclaimed
for
other
purposes,
in
which
case
then
you
know
the
next
time
the
file
is
read
from
untrusted
media.
It's
got.
It's
got
to
be
read
as
a
whole
block
in
order
to
confirm
that
it,
the
digest,
hasn't,
hasn't
changed
the
file
measures
the
same
way
as
it
did
before
so
to
resolve
that
issue.
People
turn
to
a
tree
of
digest,
often
known
colloquially,
as
merkel
trees.
A
The
the
only
issue
with
merkel
trees
is
that
they're
not
they're,
not
a
fixed
sized
piece
of
metadata.
You
know
a
linear
hash
like
sha-1
or
shot
256
digest,
that's,
you
know,
usually
less
than
a
than
four
kilobytes
in
size,
much
less
in
fact,
and
so
that's
easy
to
guarantee
that
you
know
a
file
system
can
store
that
that
little
bit
of
metadata,
but
a
hash
tree
can
get
quite
big
like
into
100
hundreds
of
megabytes.
A
You
basically
reconstitute
that
tree
and
you
can
either
store
it
on
local
storage
if
that,
if
the
local
file
system
can
store
hundreds
of
megabytes
of
of
sidecar
data
or
you
can
cache
the
tree
in
memory
and
use
it
on
demand
anytime,
you
read
you
open
the
file
either
one
is
possible
whatever.
Whatever
you
have
facilities
for
you.
Can
you
can
choose
between
the
two
or
a
combination?
A
A
So
the
combination
of
these
two
things
would
give
us
the
kind
of
letter
of
approval
that
we
might
want
to
ship
with
distribute
with
the
software
that
is
installed
on
end
user
systems.
So
I
have
these
these
questions.
I'm
not
sure
this
is
the
right
forum
for
for
an
interactive
discussion
of
these
things,
but
so
I'd
just
like
to
have
people
think
about
this.
A
little
bit,
maybe
I'll
I'll,
take
all
of
this
to
the
list.
A
A
A
B
E
B
B
B
B
C
C
B
B
We
don't
have
a
prepared
presentation
on
the
future
work.
There
was
just
a
couple
of
notes
in
the
agenda
that
was
for
the
steve
as
you
as
you
noted,
the
pnfs
nvme
and
pnfs
rdma
work,
if
I
don't
have
a
status
on
where
we
left
that
and
and
then
dave
had
a
note
about
ideas
to
address
other
needs
which
are
part
of
our
charter,
but
not
being
given
serious
attention.
D
B
B
G
G
B
E
A
E
I
was
able
to
get
an
xml
file
and
put
it
into
a
tool
into
a
tool
that
I
can
use
and
with
luck
we
won't
get
bit
by
the
changes
to
the
the
xml
template.
A
workaround
is
known,
which
is
just
don't
send
notes.
I
know
the
text,
they
don't
care,
I'm
hoping
that
that
that
that
will
be
the
case.
The
tool
chain
issue
was
was
it
was
overcome.
Last
time
I
was
able
to
work
on
this.