Subject: Re: [nfsv4] Proposed charter changes (with updates)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 3 Jun 2020 13:54:46 +0000

Hi,

I think the last sentence of the last paragraph will get comments by the IESG.
It is a bit to much a blank check for you to go do anything which IETF doesn't
already do. So are there ways to be more specific?

Otherwise it might be possible to add some safe guard to this sentence. However,
I would actually prefer that we rather run through rechartering if you want to
updated or extend things in areas outside of your current scope.

Cheers

Magnus

On Sun, 2020-05-24 at 07:25 -0400, David Noveck wrote:
> First of all, thanks to Daniel and Tom for corrections/suggestions.
> 
> I am proposing replacing the second paragraph of the extensions section which
> now reads:
> 
> > Similarly, associated ONC protocol components that have a versioning/
> > extension framework can be incrementally extended, when necessary.
> 
> By the following two-paragraph replacement:
> 
> > In dealing with needed extensions to areas that underlay NFSv4, the working
> > group's role will depend on the specific area needing extension.  In the
> > case of associated ONC protocol components, those that have a
> > versioning/extension framework can be incrementally extended, when
> > necessary.
> > 
> > In the case of lower-layer facilities of particular importance to NFSv4, the
> > working group will work with the responsible working group to make sure
> > needed extensions are available.  In cases in which there is no assigned
> > working group, it can help develop the necessary extension itself.
> 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Tom Talpey <[email-masked]>
Date: Wed, 3 Jun 2020 14:17:44 +0000

In my earlier suggest, I proposed "e.g. transport". While I don't think the WG needs to dive into TCP or SCTP, there is certainly an RDMA item, and I would foresee a possible QUIC extension someday?

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Wednesday, June 3, 2020 9:55 AM
To: [email-masked]
Cc: Tom Talpey <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: Proposed charter changes (with updates)

Hi,

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 3 Jun 2020 15:43:55 +0000

On Wed, 2020-06-03 at 14:17 +0000, Tom Talpey wrote:
> In my earlier suggest, I proposed "e.g. transport". While I don't think the WG
> needs to dive into TCP or SCTP, there is certainly an RDMA item, and I would
> foresee a possible QUIC extension someday?

So, e.g. transport is very wide. It would allow you to do a new transport
protocol which I don't think is ok. And I think you may want to do is what QUIC
working group calls a protocol mapping, rather than a QUIC extension which is an
actual extension to the QUIC protocol. 

I really prefer the charter to be quite specific on what you want to do. 

I also want to remind you that I really want to you to finish up your core items
include updates to take care of the major issues around security,
internationalization etc that the partial update to 4.1 discussed. 

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: Tom Talpey <[email-masked]>
Date: Wed, 3 Jun 2020 19:21:34 +0000

Thanks for the QUIC terminology correction, previously I understood the
upper-layer specific stuff to be considered "extensions". And, at this time
none are proposed by or for NFSv4, although I suspect there will be someday.
Also it's worth noting again that this is only for cases where no WG exists.

I'll leave it to Dave to propose final text, except to suggest that to address your
preference, we might word this as 

  In cases in which there is no assigned working group, and under the coordination
  of the relevant Area Director(s), the NFSv4 WG can help develop the necessary
  extension itself.

  An extension to RDMAP, RFC5040/7306, for enhanced memory placement
  ("Push Mode") is chartered, as the first such effort.

Comments?

Tom.

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Wednesday, June 3, 2020 11:44 AM
To: [email-masked]; Tom Talpey <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: Proposed charter changes (with updates)

Cheers

Magnus

-- 
Cheers

Magnus Westerlund

---

From: David Noveck <[email-masked]>
Date: Thu, 4 Jun 2020 07:42:35 -0400

> none are proposed by or for NFSv4, although I suspect there will be

Rdma-oriented work  is certainly possible and would be of interest to us

I'm assuming that QUIC will continue to exist for quite a while so such
work is unlikely to be relevant to the charter changes being discussed.

> I'll leave it to Dave to propose final text,

I certainly hope it is final.  As Magnus rightly points out, there is
important core work to do, so I think we have to limit how much time we
spend  on assuaging IESG anxieties about us doing crazy things that are
clearly outside the limits we propose.

except to suggest that to address your
> preference, we might word this as

I like your changes and will produce proposed final text below.  One change
I will make is to address the contradiction between "help" and "itself".
You got that from my original text ☹️.

This proposed text will be in the original multi-paragraph format to make
it clearer that only *extensions *are to be done and not whole new
transport protocols.😩

  In cases in which there is no assigned working group, and under the
> coordination

I am now proposing replacing the second paragraph of the extensions section
which now reads:

By the following three-paragraph replacement:

In the case of  extensions needed to lower-layer transport facilities of
particular importance to NFSv4, the working group will work with the
responsible working group to make sure needed extensions are available.

In cases in which there is no assigned working group,  the  Nfsv4 working
group can, with coordination provided by the relevant Area Director(s), help
by developing the necessary extension itself. For example, an extension to
RDMAP, RFC5040/7306, for enhanced memory placement ("Push Mode") would be
authorized, as one such effort.

> > > > In the case of lower-layer facilities of particular importance to
> NFSv4,
> > > > the

---

From: Tom Talpey <[email-masked]>
Date: Thu, 4 Jun 2020 08:17:29 -0400

Your reply really chopped up the quoting. I'll cherry-pick...

On 6/4/2020 7:42 AM, David Noveck wrote:
> 
> 
> On Wed, Jun 3, 2020, 3:21 PM Tom Talpey <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     none are proposed by or for NFSv4, although I suspect there will be
>     someday..
> 
> 

Indeed. But I'm not sure the QUIC WG will take up an upper layer-
specific matter, so I am expecting the same rule might apply. That's
why I suggested an AD needs to be in the loop, to review the assignment.

> I like your changes and will produce proposed final text below.  One 
> change I will make is to address the contradiction between "help" and 
> "itself".  You got that from my original text ☹️.
> 
> This proposed text will be in the original multi-paragraph format to 
> make it clearer that only /extensions /are to be done and not whole new 
> transport protocols.😩
> 
> I am now proposing replacing the second paragraph of the extensions 
> section which now reads:
> 
>     In dealing with needed extensions to areas that underlay NFSv4, the
>     working group's role will depend on the specific area needing
>     extension.  In the case of associated ONC protocol components, those
>     that have a versioning/extension framework can be incrementally
>     extended, when necessary.
> 
>     In the case of  extensions needed to lower-layer transport
>     facilities of particular importance to NFSv4, the working group will
>     work with the responsible working group to make sure needed
>     extensions are available. 
> 
> 
>     In cases in which there is no assigned working group,  the  Nfsv4
>     working group can, with coordination provided by the relevant Area
>     Director(s), help by developing the necessary extension itself. For
>     example, an extension to RDMAP, RFC5040/7306, for enhanced memory
>     placement ("Push Mode") would be authorized, as one such effort.

This sounds hypothetical. Because this is a charter update, I think the
"for example", "would be", and "as one such effort" should be deleted or
moved to a separate statement.

Tom.

>     From: Magnus Westerlund <[email-masked]
>     <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>; Tom Talpey
>     <[email-masked] <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>
>      > From: Magnus Westerlund <[email-masked]
>     <mailto:[email-masked]>>
>      > To: [email-masked] <mailto:[email-masked]>
>      > Cc: Tom Talpey <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>      > Otherwise it might be possible to add some safe guard to this
>     sentence..
>      > However,
>      > > I am proposing replacing the second paragraph of the extensions
>     section
>      > > which
>      > > now reads:
>      > >
>      > > > In dealing with needed extensions to areas that underlay
>     NFSv4, the
>      > > > working
>      > > > In the case of lower-layer facilities of particular
>     importance to NFSv4,
>      > > > the
>      > SE-164 80 Stockholm, Sweden | mailto:
>     [email-masked] <mailto:[email-masked]>
>      >
>     <mailto:[email-masked]>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: David Noveck <[email-masked]>
Date: Thu, 4 Jun 2020 09:01:53 -0400

> specific matter,

Possibly not.

> so I am expecting the same rule might apply.

I dont'see how we can take a rule designed for the case in which the
responsible working group doesn't exist and apply it to a case in which the
responsible working group does not want to take on the work.   That's
clearly a different situation.

In that case, the work charter proposal says we "will work with the
responsible working group to make sure needed extensions are available".
 In the case in which we want something that the Quic working goup doesn't
want to do, we would do it, unless it is something that the QUIC working
group doesn't think should be done.

> That's why I suggested an AD needs to be in the loop, to review the
assignment.

I thought it was intended to assure the IESG, that we are not going to do
stuff without supervision.

In any case, as a practical matter, there is no way would do any of this
without the responsible AD's approval/support.

On Thu, Jun 4, 2020 at 7:42 AM David Noveck <[email-masked]> wrote:

>> someday.
> working group's role will depend on the specific area needing extension.
> In the case of associated ONC protocol components, those that have a
> by developing the necessary extension itself. For example, an extension
> to RDMAP, RFC5040/7306, for enhanced memory placement ("Push Mode") would
> be authorized, as one such effort.
>
>
>> Tom.
>>

---

From: David Noveck <[email-masked]>
Date: Thu, 4 Jun 2020 09:15:20 -0400

> moved to a separate statement.

I see your point but the fact is, it is being cited as an example.  How
abut the following as the final paragraph:

In cases in which there is no assigned working group,  the  Nfsv4 working
group can, with coordination provided by the relevant Area Director(s), help
by developing the necessary extension itself, as is being done in providing
an extension to RDMAP, RFC5040/7306, for enhanced memory placement ("Push
Mode").

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 5 Jun 2020 07:23:24 +0000

On Thu, 2020-06-04 at 09:01 -0400, David Noveck wrote:
> responsible working group does not want to take on the work.   That's clearly
> a different situation.
> 
> responsible working group to make sure needed extensions are available".   In
> the case in which we want something that the Quic working goup doesn't want to
> do, we would do it, unless it is something that the QUIC working group doesn't
> think should be done.

So from a structural point of view when it comes to RDMA over QUIC I would like
to point to that such a mapping onto QUIC may actually be done outside of QUIC
WG. 

So the QUIC charter has the following paragraph: 

The third focus area describes the mapping between the HTTP application protocol
and the transport facilities of QUIC. This mapping will have performance
characteristics comparable with HTTP/2, and provide extension mechanisms similar
to HTTP/2. Upon completion of this mapping, work to define additional mappings
may be included by updates to this charter, or may be worked on by other working
groups.

Note the last sentence, that it is both an explicit recharter to bring in
additional mappings and that mappings may very well be done in the WG of the
protocol being mapped onto QUIC. However, if one think the mapping is going to
be particular thorny and possibly also require QUIC protocol extensions, i.e.
have requirements that other QUIC users may benefit from it could make sense to
do the work in QUIC. 

For that reason I would recommend that one work through the technical proposal
to better understand what desired propoerties of RDMA over QUIC has, as well as
what is required to realize those from QUIC. Then one can likely make a good
decision if that work should be done in QUIC WG or in this or another WG. 

> without the responsible AD's approval/support.

So, this may calm the IESG. Still the wider review that recharters get from the
review call help avoiding surprises and unfortunate interactions between working
groups. 

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Jun 2020 10:25:48 +0300

Hi,

> decision if that work should be done in QUIC WG or in this or another WG.

+1

An initial individual draft would be very useful in triaging where the best place for this work would be.

Lars

---

From: Tom Talpey <[email-masked]>
Date: Fri, 5 Jun 2020 08:15:35 -0400

> An initial individual draft would be very useful in triaging where the best place for this work would be.

So, to be clear I was describing a process for a potential
NFSv4-over-QUIC binding, not an RDMA-over-QUIC one. Although,
I have been thinking about both.

I'd like to get the RDMA Push Mode extension draft process
through the knothole before considering the next one. :-)

Tom.

---

From: David Noveck <[email-masked]>
Date: Fri, 5 Jun 2020 09:03:29 -0400

On Fri, Jun 5, 2020 at 8:15 AM Tom Talpey <[email-masked]> wrote:

> NFSv4-over-QUIC binding, not an RDMA-over-QUIC one.

That would probably take the form of an extension to RPC, updating RFC
5531, with no change to QUIC itself anticipated.  Unless I'm missing
something, that could be done even under the current charter, although I'm
cc-ing Lars to make sure he is aware of the possibility of us doing this.

> Although,
> Apparently, Magnus read your mind.   I'm not sure how I feel about having
AD's with that capability :-)

> through the knothole before considering the next one. :-)

I hope "through the knothole" means waiting for IESG approval.   Waiting
for publication as an RFC has lately become a process of unbounded duration.

I think you are the right person to do the individual draft for
RDMA-over-QUIC and hope that you would be interested in doing it, when the
time is ripe.

With regard to RPC-over-QUIC, I'd be glad if you are interested in doing
this, but there are a number of people that can participate so it would not
take all that much of your time.  It is interesting to the working group
primarily because of its security implications.

---

From: Tom Talpey <[email-masked]>
Date: Fri, 5 Jun 2020 09:19:12 -0400

On 6/5/2020 9:03 AM, David Noveck wrote:
> 
> 
> On Fri, Jun 5, 2020 at 8:15 AM Tom Talpey <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On 2020-6-5, at 10:23, Magnus Westerlund
>     <magnus.westerlund=[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > An initial individual draft would be very useful in triaging
>     where the best place for this work would be.
> 
> something, that could be done even under the current charter, although 
> I'm cc-ing Lars to make sure he is aware of the possibility of us doing 
> this.

The NFSv4 WG has already published an Upper Layer Binding ("ULB") for
various dialects of NFS atop RPC-over-RDMA, so yes, I agree.

However, with a new transport, in my opinion, there is always the
possibility of finding something "missing", for example, the current
Push Mode extension for RDMA. It's this latter aspect in which I
strongly believe the upper layer, e.g. NFSv4, can add value.

> Apparently, Magnus read your mind.   I'm not sure how I feel about 
> having AD's with that capability :-)
> 

Achieving IESG approval, yes. That's why I added the word "process".
Once approved, we can start the actual work.

> RDMA-over-QUIC and hope that you would be interested in doing it, when 
> the time is ripe.
> 
> this, but there are a number of people that can participate so it would 
> not take all that much of your time.  It is interesting to the working 
> group primarily because of its security implications.

I'm flattered, and thanks. I'm not unique in having thought about it
though. Earlier, it was clear that standardizing a base QUIC protocol
was needed before considering this. As QUIC moves forward, I'd be hopeful
that it makes sense to explore RDMA.

Tom.