Re: [nfsv4] NFSv4.2: Optional attribute to retrieve MS branchcachecontent description

"Govind, Subin" <Subin.Govind@netapp.com> Mon, 24 August 2009 05:44 UTC

Return-Path: <Subin.Govind@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C01B3A6841 for <nfsv4@core3.amsl.com>; Sun, 23 Aug 2009 22:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGDXxWju0pZy for <nfsv4@core3.amsl.com>; Sun, 23 Aug 2009 22:44:24 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id DADF53A69F4 for <nfsv4@ietf.org>; Sun, 23 Aug 2009 22:44:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,263,1249282800"; d="scan'208";a="230207041"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 23 Aug 2009 22:44:27 -0700
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n7O5iP1F003478; Sun, 23 Aug 2009 22:44:26 -0700 (PDT)
Received: from btcrsexc1-prd.hq.netapp.com ([10.73.251.109]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Aug 2009 22:44:25 -0700
Received: from BTCMVEXC1-PRD.hq.netapp.com ([10.73.251.107]) by btcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 11:14:20 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Aug 2009 11:14:19 +0530
Message-ID: <CF4B8324B5D2934C9377BD36E370526B094BCC22@BTCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <1250854636.6514.33.camel@heimdal.trondhjem.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] NFSv4.2: Optional attribute to retrieve MS branchcachecontent description
Thread-Index: AcoiU8q5RTmI5SlaSbCmCEfCcZkjfQCKMWXQ
References: <CF4B8324B5D2934C9377BD36E370526B094BC586@BTCMVEXC1-PRD.hq.netapp.com> <43EEF8704A569749804F545E3306FCE3042CDBCB@SACMVEXC3-PRD.hq.netapp.com> <CF4B8324B5D2934C9377BD36E370526B094BC648@BTCMVEXC1-PRD.hq.netapp.com> <1250854636.6514.33.camel@heimdal.trondhjem.org>
From: "Govind, Subin" <Subin.Govind@netapp.com>
To: trond.myklebust@fys.uio.no
X-OriginalArrivalTime: 24 Aug 2009 05:44:20.0270 (UTC) FILETIME=[ED3584E0:01CA247D]
Cc: "Erasani, Pranoop" <Pranoop.Erasani@netapp.com>, nfsv4@ietf.org
Subject: Re: [nfsv4] NFSv4.2: Optional attribute to retrieve MS branchcachecontent description
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 05:44:25 -0000

There are quite a few differences between the two methods of data
caching.

It looks more like the draft on pnfs backend protocol is aimed at
increasing parallelism of data access.

On the other hand, branchcache is aimed at reducing WAN link load.

Furthermore Win7 is coming out with branchcache in a big way and it
would be a great advantage for NFS clients if they can interoperate with
Windows clients using branchcache.

I think it still makes sense to support both.

Thanks
Subin



 

-----Original Message-----
From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] 
Sent: Friday, August 21, 2009 5:07 PM
To: Govind, Subin
Cc: Erasani, Pranoop; nfsv4@ietf.org
Subject: Re: [nfsv4] NFSv4.2: Optional attribute to retrieve MS
branchcachecontent description

On Fri, 2009-08-21 at 08:23 +0530, Govind, Subin wrote:
> Pranoop,
>  
> At a very high level --
>  
> Its basically a collection of hashes and encryption keys. The hashes 
> are uses to test for integrity of data that a client can fetch from 
> its peer.
>  
> Data is broken up into chunks of 32 MB and each chunk is searched 
> using a key that can be computed from the hashes in the content 
> decription.
>  
> The encryption key used to decrypt the data that the client gets from 
> other peers on its network.
>  
> Please refer to http://msdn.microsoft.com/en-us/library/dd303704%
> 28PROT.10%29.aspx for detailed info.
>  
> Thanks
> Subin
>  
>  
>  
> 
> 
> ______________________________________________________________________
> From: Erasani, Pranoop
> Sent: Friday, August 21, 2009 1:22 AM
> To: Govind, Subin; nfsv4@ietf.org
> Subject: RE: [nfsv4] NFSv4.2: Optional attribute to retrieve MS 
> branchcachecontent description
> 
> 
> 
> Subin,
>  
> What information would be part of the branch cache file content 
> description?
>  
> - Pranoop
> 
>         
>         ______________________________________________________________
>         From: Govind, Subin 
>         Sent: Thursday, August 20, 2009 9:47 AM
>         To: nfsv4@ietf.org
>         Subject: [nfsv4] NFSv4.2: Optional attribute to retrieve MS
>         branchcachecontent description
>         
>         
>         
>         Hi,
>          
>         We should have an optional attribute that will help NFS
>         clients retrieve the Microsoft branch cache file content
>         decription. I propose this as a possible item for NFS 4.2.
>          
>         Using the decription, NFS clients will be able to open a file
>         and request other openers (possibly CIFS) who have same file
>         cached.
>         Content servers that have both CIFS and NFS will benefit most
>         from this     
>          
>         -Subin

Peer-to-peer nfs has already been proposed for the NFSv4.2 agenda, but
the plan was to reuse the pnfs mechanism. See

http://tools.ietf.org/id/draft-myklebust-nfsv4-pnfs-backend-protocol-00.
txt

Trond