[cifs-protocol] [REG:111051857287367] BranchCache and SMB2: Questions specific to BranchCache.

Christopher R. Hertel crh at ubiqx.mn.org
Thu Jun 9 15:35:10 MDT 2011


Thanks again for this reply.  I have some comments which I hope you will 
pass along to the documentation team and engineers.

On Tue, May 31, 2011 at 08:43:22PM +0000, Edgar Olougouna wrote:
> Chris,
> Please find our answers as follows. 
> BranchCache divides content into 32 megabyte segments and further
> subdivides these segments into 64 kilobyte blocks.

Yes.  [MS-PCCRC] does a good job of explaining that part.

> The content information encodes:
> (1) ullOffsetInContent - the offset within the content at which the 
> first segment present in the content information begins and

Again yes, this makes sense to me.

> (2) dwOffsetInFirstSegment - the offset from ullOffsetInContent at which 
> the first block of the first segment present in the content information 
> begins.

This is where things get confusing.

> Let's walk through this with an example.
> Let's assume the client requests a content range starting at content 
> offset 33554433 (a.k.a. 32 megabytes plus one byte) and extending for 10 
> bytes.

Problem #1 (for me):  The examples given in the document specifically 
state that they show requests for entire files.  From section 3.1:

   "A client requests the entirety of the 125 kilobyte content from the 
   server. The server responds with Content Information of the following 

>From section 3.2:

  "The same server S now receives a client request for a 125-megabyte 

...so, the examples in [MS-PCCRC] do not cover the use of ranges.  These 
are whole-file requests, so there is no example of how 
dwOffsetInFirstSegment or dwReadBytesInLastSegment might be used (though 
there are descriptions).

> ullOffsetInContent will be 32 megabytes because that is where the first 
> segment present in the content information begins.

Makes sense.

> dwOffsetInFirstSegment will be 1 because the first segment in the 
> content information is the second segment in the actual content because 
> the requested content range starts at 32 megabytes plus one.

So...  If I understand this correctly, the situation is that BranchCache 
must operate in terms of Segments, and when it returns the Segment 
Information for this segment, it is including an offset, relative to the 
start of the Segment, at which the *requested* content begins.

Is that correct?

> dwReadBytesInLastSegment will be 10 because that is the length of the 
> content range that lies within the final segment present in the content 
> information.

If my new understanding of dwOffsetInFirstSegment is correct, then I 
believe that my understanding of dwReadBytesInLastSegment is now also 
correctly updated.

Basically, if the client requests a range the server must send Content 
Information covering the segments that completely include the requested 
range.  These two values indicate how to handle the cached segments when 
the client retrieves them from the cache, as follows:

  dwOffsetInFirstSegment   - Discard this many leading bytes of the first 
                             segment retrieved from cache.

                             Retain all bytes of all subsequent segments
                             retrieved from cache except the last one.

  dwReadBytesInLastSegment - Retain only this many leading bytes of the 
                             last segment retrieved from cache.

  Is that correct?

> Note that dwReadBytesInLastSegment may be zero if the client did not 
> request a content range (i.e. the client asked for the entire content).

So a dwReadBytesInLastSegment value of zero is interpreted as "all bytes" 
in the segment.

> The scenarios in which dwReadBytesInLastSegment will be zero are Windows 
> specific behavior. In Windows 7, this happens whenever the content
> information covers the entire content. In order to participate in the
> MS-PCCRC protocol, a client must be able to parse content information
> that contains a zero value for dwReadBytesInLastSegment. The client must 
> react by treating the segment size for the final segment encoded in the 
> content information as the amount of data in the final segment. If
> dwReadBytesInLastSegment is non-zero then the client must only attempt 
> to read dwReadBytesInLastSegment from the final segment, regardless of 
> the segment size of the final segment.

Not quite...  Assuming that I'm catching on here, and that such a bug 
could happen, the goal would be something like the following:

  if 0 == dwReadBytesInLastSegment
    readbytes = cbSegment
    readbytes = min( dwReadBytesInLastSegment, cbSegment )

If, due to some bug, the dwReadBytesInLastSegment were greater than the 
number of actual bytes in the segment then you would still want to read 
only the number of actual bytes in the segment.  I can envision something 
like this happing if the requested range extended beyond the end of the 
Content and the server did not clean up the results properly.

Okay, so I am being picky here... but it serves to verify whether or not 
I am understanding these fields.

> On Windows 7, if the content fits in one segment and the client issued a 
> request for the entire content then, dwReadBytesInLastSegment should be 
> zero and dwOffsetInFirstSegment should be zero.

It was my understanding, based on my reading of a number of several MSDN 
web pages, that only Windows 2008R2 servers could be BranchCache servers.  
Windows 7 systems could only be clients.  Vista and Windows 2008 systems 
could also be clients if an additional package was installed.  (W2Kr2 
servers can also be BranchCache clients, I believe.)

The idea that Windows 7 cannot be a BranchCache Server is somewhat 
supported by the following Windows Behavior note from [MS-PCCRC]:

  "<2> Section 2.3: In Windows 7, the [MS-PCCRR] implementation can only
  accept segment IDs generated using SHA-256, whereas the Windows Server 
  2008 R2 implementation of the hash generation part can generate segment 
  IDs using one of three hashing algorithms: SHA-256, SHA- 384, or 

Note that the behavior note only talks about Windows 7 in client mode and 
says nothing about its capabilities in server mode.  I believe that's 
because Windows 7 doesn't support server mode.  Also, only a Windows 
2008r2 server can act as a hosted cache.  Windows 7 clients, I believe, 
can operate as peer caches.

So... Do you mean to say Windows 7 or Windows 2Kr2 in the statement above?  
If Windows 7, then are you talking about W7 clients sending content 
requests to the hosted cache server or as broadcasts on the local LAN?  
If so, that part of BranchCache is outside of the scope of [MS-PCCRC] ... 
which leaves me confused as to what you are trying to explain to me when 
you describe Windows 7 behavior.

> The product team will be reflecting the above clarification in the
> protocol document. Let me know whether this answers your questions.

It would be quite helpful if an additional example were presented in order 
to show how these values are used.  I found the descriptions of these 
values to be difficult to interpret when reading the documentation.  

Unless you tell me that my understanding, given above, is incorrect I 
believe that your description has clarified things nicely.


Chris -)-----

> Regards,
> Edgar
> -----Original Message-----
> From: Edgar Olougouna 
> Sent: Tuesday, May 31, 2011 11:07 AM
> To: 'Christopher R. Hertel'
> Cc: cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: Questions specific to BranchCache.
> Chris,
> I am actively working on this with the product team to clarify a few more points. I will update you as soon as possible.
> Regards,
> Edgar
> -----Original Message-----
> From: Christopher R. Hertel [mailto:crh at ubiqx.com]
> Sent: Sunday, May 29, 2011 5:57 PM
> To: Edgar Olougouna
> Cc: MSSolve Case Email; cifs-protocol at samba.org
> Subject: Re: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: Questions specific to BranchCache.
> Edgar,
> I am just checking in on this ticket.  I understand that the resolution to these issues can take some time, but I want to test my implementation at the FileSharing Plugfest in a few weeks time.  Having the answers would help me complete my testing implementation.
> Thanks.
> Chris -)-----
> Obaid Farooqi wrote:
> > Hi Chris:
> > Thank you for contacting Microsoft regarding your query on branch cache. A member of the protocol documentation team will be in touch soon.
> > 
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> > 
> > Exceeding your expectations is my highest priority.  If you would like 
> > to provide feedback on your case you may contact my manager at 
> > allisong at microsoft.com
> > 
> > 
> > -----Original Message-----
> > From: Christopher R. Hertel [mailto:crh at ubiqx.com]
> > Sent: Tuesday, May 17, 2011 9:12 PM
> > To: Interoperability Documentation Help
> > Subject: BranchCache and SMB2: Questions specific to BranchCache.
> > 
> > I have a couple of questions regarding BranchCache and [MS-PCCRC].  As you know, BranchCache--particularly the Content Information format specified in [MS-PCCRC]--can be used as an extension to SMB2.
> > 
> > 1) In the Content Information structure ([MS-PCCRC:2.3]), there is the
> >    following field definition:
> > 
> >    dwOffsetInFirstSegment (4 bytes): Number of bytes into the first
> >      segment within the Content Information data structure at which
> >      the content range begins.
> > 
> >    I can't make heads nor tails of that description, and the captures I
> >    have done on the wire typically show that field set to zero.
> >    Similarly, the examples in section 3 of [MS-PCCRC] show the value of
> >    this field to be zero.
> > 
> >    The field is 4 bytes in length, so it cannot be an offset into the
> >    content itself, since content offsets are (should be) 8 bytes (64-bit).
> > 
> >    Please clarify:  What does dwOffsetInFirstSegment actually represent?
> > 
> > 2) I am not getting what I expect in the dwReadBytesInLastSegment field.
> >    This field is defined in [MS-PCCRC:2.3], as follows:
> > 
> >    dwReadBytesInLastSegment (4 bytes): Total number of bytes of the
> >      content range which lie within the final segment in the Content
> >      Information data structure.
> > 
> >    It seems to me that this value represents the number of bytes
> >    of actual content included in the calculation of the final
> >    Segment block of the Content Information.  That interpretation
> >    is supported by the examples in section 3.
> > 
> >    In actual captures, however, Windows IIS server returns zero
> >    (0x00000000) in the dwReadBytesInLastSegment field.
> > 
> >    Is this a documentation bug or is the IIS server returning the
> >    wrong value?
> > 
> >    This is IIS running on W2K8r2 with fairly up-to-date patches
> >    applied.
> > 
> > Looking forward to the replies.
> > 
> > Thanks.
> > 
> > Chris -)-----
> > 
> > --
> > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
> > Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
> > jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
> > ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
> > OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org
> > 
> -- 
> Christopher R. Hertel -)-----             Storage Architect & CIFS Geek
> http://www.ubiqx.com/               Data Storage and Systems Consulting
> "Implementing CIFS - the Common Internet FileSystem"   ISBN: 013047116X

More information about the cifs-protocol mailing list