SMB2/3 Credits (Multi-Credit) support

[Stefan (metze) Metzmacher]

Am 28.06.2012 01:16, schrieb Stefan (metze) Metzmacher:
> Hi Jeremy,
> 
>>> while reviewing the multi-credit code that already went to master
>>> a few weeks ago, I noticed some missing details in the multi-credit code.
>>>
>>> While debugging this I found some bugs in our credit handling code.
>>>
>>> I spend a lot of time testing against Windows 2012 RC.
>>> I think the code in this branch, let us behave almost like a windows server.
>>> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-credits
>>>
>>> The most important thing is that windows 2012 RC allows up to 8192 credits
>>> (also our default), but it normally it only grants up to (8192/16) = 512
>>> credits.
>>
>> Interesting - do you know if this is documented anywhere in the MS docs ?
>> The credit algorithm they use is not documented as far as I know.
> 
> No, not exactly, there're just the values
> 
>          default min/default max:
> desktop  128/2018
> server   512/8192
> 
>>> If the client uses very large credit-charge values (e.g. using all 512
>>> (or 256) credits just for one request)
>>> I'm able to get up to 8192 credits after a while.
>>>
>>> Note that it's only useful for a client to use up to 15 credits per
>>> request (for 1MB reads/writes).
>>>
>>> With my patches we only grant up to (8192/16) = 512 credits,
>>> adding more dynamic crediting between 512 and 8192 later.
>>
>> That sounds reasonable.
>>
>>> I'll do some more testing tomorrow, then I plan to push this to master
>>> (it already passed a private autobuild once).
>>
>> I noticed you removed DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR,
>> which is fine, but I need to tell you why that was added.
>>
>> What I observed back when we were advertising smaller credit
>> windows was that Windows clients would request sequence numbers
>> *outside* of the valid credit range.
>>
>> For example, if we have a valid sequence number space of 100-200,
>> then Windows clients would use requests with sequence numbers between
>> 100 - 300. Note that they'd never use more than the 100 outstanding
>> credits they had available, but they'd commonly miss a low
>> sequence number and then use numbers above the valid range,
>> finally filling in the missing low sequence number just before
>> running out of credits.
>>
>> So DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was a heuristic added
>> to allow us to cope with that. Christian worked with me on
>> this and can probably also remember some details.
>>
>> It sounds like you may have figured out the Windows algorithm,
>> and by restricting to 16th you may not hit the problem
>> DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was added to solve.
>>
>> I'd keep a close eye on this however, as normal testing
>> didn't reveal the seuqnce number problem, it took released
>> code in the wilds of IBM internal to have the problem be
>> seen.
> 
> DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was just there to hide real bugs.
> 
> 1. If the client starts with a SMB1 negprot, we never removed seqnum 0.
> 
> 2. when moving the seqnum_low, we didn't calculate the bitmap_offset
> correct.
> 
> 3. we moved seqnum_low + 1 (as lowest value) instead of id == seqnum_low.
> 
> 4. we didn't stop granting credits if the client didn't use seqnum_low.
> 

5. first we granted all credits that client asked for in the first response
   and our 1/16th logic, removed credits the client already had.
   I guess the windows client doesn't expect the server remove credits
   if he asks to keep the current credit level.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120628/dbac1425/attachment.pgp>