none
[MS-SMB2] Suggestion regarding the language around SMB2_GLOBAL_CAP_LARGE_MTU RRS feed

  • Question

  • This is not a really a question but rather a thinking exercise followed by a suggestion:

    In relation to the server specifications, [MS-SMB2] 3.3.5.3.1 and 3.3.5.4 specify:

    1. if "the underlying connection is either TCP port 445 or RDMA, Connection.SupportsMultiCredit MUST be set to TRUE."

    2. The NEGOTIATE response Capabilities field MUST include "SMB2_GLOBAL_CAP_LARGE_MTU if Connection.SupportsMultiCredit is TRUE"

    Now let's think about this from the client point of view:

    Assuming that we have a theoretical server that does not set SMB2_GLOBAL_CAP_LARGE_MTU in those conditions (when the connection is either TCP port 445 or RDMA), from the client point of view of the specifications nothing will be broken:

    1. The client will send NEGOTIATE request (SMB 3.x: SMB2_GLOBAL_CAP_LARGE_MTU will be set and stored in Connection.ClientCapabilities - it will remain unused).

    2. The client will receive the aforementioned NEGOTIATE response, it will set Connection.SupportsMultiCredit to FALSE as specified in 3.2.5.2 and the connection will proceed correctly.

    It seems to me that the SMB2_GLOBAL_CAP_LARGE_MTU flag was put there for a reason (allowing the server to choose whether LARGE_MTU should be used), and I strongly feel that the wording should be changed from MUST to SHOULD.

    Thanks,

    Tal Aloni


    Saturday, September 2, 2017 1:25 PM

Answers

  • Hi Tal,

    I reviewed our SMB2 server code and a Microsoft SMB 2.1+ server that is using port 445 or RDMA (i.e., not using NetBT) will ALWAYS set the SMB2_GLOBAL_CAP_LARGE_MTU flag for the server-to-client [MS-SMB2] 2.2.4 “SMB2 NEGOTIATE Response” message.  The flag coming from the client is never taken in as a factor.  Thus, the specification is technically correct as to what a Microsoft SMB2 server end-point does.  Even if the client doesn’t send this flag, a Microsoft server still will (given 2.1+, 445 || RDMA).

    I’ll be at SNIA’s SDC next week for the SMB2/3 protocol Plugfest (perhaps you will be, too).  Let me consider this a bit more as I discuss this topic with our mutual peers.  I don’t think a specification change is in order as it follows our MUST v SHOULD commitment.  In this case the MUST accurately describes what a Microsoft server does.  But, your point is valid, too.

    A client that connects to a server that does not set this flag does properly function and our client (and probably most/all third-party clients) don’t complain.  But that would rely on a client initially setting LargeMTU to TRUE when it sends its capability and then setting it to FALSE when it gets the server response.  That client behavior is covered in the client processing rule:

                    [MS-SMB2] 3.2.5.2 “Receiving an SMB2 NEGOTIATE Response”

    If the client implements SMB 2.1 or SMB 3.x dialect family, the client MUST perform the following:

    […]

    If SMB2_GLOBAL_CAP_LARGE_MTU is set in the Capabilities field of the SMB2 NEGOTIATE Response, the client MUST set Connection.SupportsMultiCredit to TRUE. Otherwise, it MUST be set to FALSE.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by Tal Aloni Friday, September 8, 2017 9:59 PM
    Friday, September 8, 2017 7:59 PM
    Moderator
  • Clarification on:

    “A client that connects to a server that does not set this flag does properly function and our client (and probably most/all third-party clients) don’t complain.  But that would rely on a client initially setting LargeMTU to TRUE when it sends its capability and then setting it to FALSE when it gets the server response.  That client behavior is covered in the client processing rule”

    I should have said: it doesn’t matter if the client sets SMB2_GLOBAL_CAP_LARGE_MTU or not.  What matters is that the client sets LargeMTU to FALSE when it gets the message from the server that is absent the SMB2_GLOBAL_CAP_LARGE_MTU flag.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by Tal Aloni Friday, September 8, 2017 8:47 PM
    Friday, September 8, 2017 8:05 PM
    Moderator

All replies

  • Hi Tal:

    I have alerted the open specifications team regarding your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi

    Saturday, September 2, 2017 4:26 PM
    Owner
  • According to a post by Bill Wesse in the official blog of the Engineers supporting the Microsoft Open Specifications Documentation:

    "The SMB 2.1 protocol NEGOTIATE Request message ‘Capabilities’ (4 bytes) field has a newly defined flag: SMB2_GLOBAL_CAP_LARGE_MTU (0x4). This flag is set or cleared by the server to indicate whether or not multi-credit operations are enabled or disabled, respectively."

    While this blog entry is informative and not normative, it helps to illustrate my point.


    • Edited by Tal Aloni Saturday, September 2, 2017 8:17 PM
    Saturday, September 2, 2017 8:17 PM
  • Hi Tal,

    Thank you for your comments.

    In general:

    There are historical reasons as to how the specifications use RFC2119 terms: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".  The standard practice is to use absolute terms, like MUST and MUST NOT, to indicate what a Microsoft client or server does.  In some instances, it was discovered that a Microsoft platform varied from the spec – either in whole or in particular builds, SKUs or circumstances.  We’ll still advise third-parties of what we think the right behavior should be via a SHOULD or MAY and then add a Windows Behavior Note (<wbn>) indicating in what way the Microsoft platform deviated.  But, overall, from section-to-section, each in isolation, we will use MUST to document what a Microsoft endpoint does.

    There may be specific cases that a client or server could tolerate a partner that is not honoring the expected MUSTs and chose to continue to work.  [for instance, I have seen four- and eight-byte alignment rules where a Microsoft client or server, as the sending party, always follows the alignment rule but may tolerate non-alignment when a Microsoft endpoint is the receiver.]

     

    Looking at your example: At [MS-SMB2] 3.3.5.3.1 (server receives an SMB_COM_NEGOTIATE) “SMB 2.1 or SMB 3.x Support”:

    “If the server does not implement the SMB 2.1 or 3.x dialect family, processing MUST continue as specified in 3.3.5.3.2.

    Otherwise, the server MUST scan the dialects provided for the dialect string "SMB 2.???". If the string is not present, continue to section 3.3.5.3.2. If the string is present, the server MUST respond with an SMB2 NEGOTIATE Response as specified in 2.2.4. If the string is present and the underlying connection is either TCP port 445 or RDMA, Connection.SupportsMultiCredit MUST be set to TRUE. “

    Is saying that if you’re a SMB2 server and you see the SMB1 “SMB_COM_NEGOTIATE” message that includes the dialect “2.???”, we consider that a SMB2.1+ server implementation MUST support multi-credits (for TCP port 445 and RDMA).  Multi-credit support is not optional (for TCP port 445 and RDMA).

    Thus, a “theoretical server that does not set SMB2_GLOBAL_CAP_LARGE_MTU in those conditions” is already out on a limb.

    Furthermore, in the same section, we continue, as you point out:

    • The      Capabilities field MUST be set to a combination of zero or more of      the following bit values, as specified in section 2.2.4:
      • […]
      • SMB2_GLOBAL_CAP_LARGE_MTU       if Connection.SupportsMultiCredit is TRUE. [my note: if “SMB       2.???” Was listed in the dialects and the connection is using TCP port       445 or RDMA].

    Thus, the server MUST advise the client that it supports multi-credit.

    Once the server sends the SMB2 Negotiate response with SMB2_GLOBAL_CAP_LARGE_MTU, then section 3.2.5.2 “(client) Receiving an SMB2 NEGOTIATE Response” takes over and indicates that the client MUST also set Connection.SupportsMultiCredit to true.

    While I see a ADM element Connection.ClientCapabilities, the text just cited specifies that Connection.SupportsMultiCredit is set according to the existence of SMB2_GLOBAL_CAP_LARGE_MTU.  And, throughout [MS-SMB2] 3.2 “Client Details” cites Connection.SupportsMultiCredit often.

    What I don’t see is anywhere in the Client Processing Rule at 3.2.5.2 “Receiving an SMB2 NEGOTIATE Response” that indicates that client should reject (disconnect a connection or otherwise trigger a failure) if SMB2_GLOBAL_CAP_LARGE_MTU is NOT present when TCP port 445 or RDMA is used, which gets me back to my point above: There may be specific cases that a client or server could tolerate a partner that is not honoring the expected MUSTs and chose to continue to work.

    Based on my review, I believe that the MUSTs are appropriate.  However, there is nothing in the specification per the client processing rules that would prohibit a client from not working if TCP port 445 or RDMA is used and the server does not return SMB2_GLOBAL_CAP_LARGE_MTU.  Sometimes this is useful when an implementer wants to phase in an implementation.  He or she may delay adding this feature as he or she gets other elements of the protocol sketched in.

    However, be advised that other features may rely on multi-credit, like, perhaps, RDMA itself or RSVD, etc., and we believe that multi-credit  is an important feature of [MS-SMB2]


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, September 5, 2017 7:06 PM
    Moderator
  • Hi Bryan, Have you looked at the post by Bill Wesse I mentioned?

    From a software developer point of view, it feels to me that there may have been a mistake putting the MUST there in the first place, so instead of relying on the document, could you please look into it from an engineering perspective and try to find a justification why SMB2_GLOBAL_CAP_LARGE_MTU MUST always be set?

    I have tested various Windows implementation From Windows 7 to Windows 10 and I could not find a single problem with clearing SMB2_GLOBAL_CAP_LARGE_MTU.

    From everything I've read it feels to me that LARGE_MTU was designed to be a feature, but the current language of the document makes it unclear.

    Thanks!

    Tal Aloni



    • Edited by Tal Aloni Tuesday, September 5, 2017 8:39 PM
    Tuesday, September 5, 2017 8:32 PM
  • Hi Tal,

    I originally took your message as a request for general clarification of MUST v SHOULD with an example to illustrate the point.  I now realize that your quest is specifically about your example.  What I hear you saying is that having the client originally send its Large MTU capability to the server makes no sense if the server is just to ignore it and always set the flag anyway.  What I’ll do is look at the code itself to see if I see evidence that the server sets that flag (server-to-client) only if the client indicated it supports Large MTU, too.  It may, so I’ll research further.  I suspect that a Microsoft client (post 2.1) will always send it, making the point mute in a Microsoft-to-Microsoft case and in a Microsoft client(2.1+)-to-third party server case.  But, may apply to down-level Microsoft clients and other third-party clients.  I’ll report what I find.  Is the foregoing acceptable?

    BTW, yes, I did look at Bill's post.  He was a colleague of mine on this exact team.  The blog provides a vehicle for the team to share what we think may be valuable insight or background to the protocols to augment the official specs.  But, as you pointed out, they are informative only.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, September 7, 2017 3:11 AM
    Moderator
  • Thanks Bryan, that would be very helpful!

    let me explain my motivation a little better: I have written an SMB 2.1 server using the minimum set of features required for my project, Large MTU is not one of them.

    In addition, NetApp SMB 2.1 server implementation does not support Large MTU as well but is still marketed as an SMB 2.1 server.

    Any client compliant with the SMB 2.1 specifications can successfully communicate with both servers, yet according to the language of the specifications they are not SMB 2.1 servers because they don't support Large MTU. this makes little sense.

    If indeed (as I suspect) Microsoft clients honor the SMB2_GLOBAL_CAP_LARGE_MTU and treat large MTU as a feature , than it's likely that something got "lost in translation" when the server specifications were written.

    As you pointed out, software developers usually like to start with the bare minimum and grow from there, and I do believe large MTU was designed to be a server feature, it would be very beneficial to implementers to get this sorted out. (there are other benefits as well)

    Thank you for investigating it!

    Thursday, September 7, 2017 6:49 AM
  • Hi Tal,

    I reviewed our SMB2 server code and a Microsoft SMB 2.1+ server that is using port 445 or RDMA (i.e., not using NetBT) will ALWAYS set the SMB2_GLOBAL_CAP_LARGE_MTU flag for the server-to-client [MS-SMB2] 2.2.4 “SMB2 NEGOTIATE Response” message.  The flag coming from the client is never taken in as a factor.  Thus, the specification is technically correct as to what a Microsoft SMB2 server end-point does.  Even if the client doesn’t send this flag, a Microsoft server still will (given 2.1+, 445 || RDMA).

    I’ll be at SNIA’s SDC next week for the SMB2/3 protocol Plugfest (perhaps you will be, too).  Let me consider this a bit more as I discuss this topic with our mutual peers.  I don’t think a specification change is in order as it follows our MUST v SHOULD commitment.  In this case the MUST accurately describes what a Microsoft server does.  But, your point is valid, too.

    A client that connects to a server that does not set this flag does properly function and our client (and probably most/all third-party clients) don’t complain.  But that would rely on a client initially setting LargeMTU to TRUE when it sends its capability and then setting it to FALSE when it gets the server response.  That client behavior is covered in the client processing rule:

                    [MS-SMB2] 3.2.5.2 “Receiving an SMB2 NEGOTIATE Response”

    If the client implements SMB 2.1 or SMB 3.x dialect family, the client MUST perform the following:

    […]

    If SMB2_GLOBAL_CAP_LARGE_MTU is set in the Capabilities field of the SMB2 NEGOTIATE Response, the client MUST set Connection.SupportsMultiCredit to TRUE. Otherwise, it MUST be set to FALSE.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by Tal Aloni Friday, September 8, 2017 9:59 PM
    Friday, September 8, 2017 7:59 PM
    Moderator
  • Clarification on:

    “A client that connects to a server that does not set this flag does properly function and our client (and probably most/all third-party clients) don’t complain.  But that would rely on a client initially setting LargeMTU to TRUE when it sends its capability and then setting it to FALSE when it gets the server response.  That client behavior is covered in the client processing rule”

    I should have said: it doesn’t matter if the client sets SMB2_GLOBAL_CAP_LARGE_MTU or not.  What matters is that the client sets LargeMTU to FALSE when it gets the message from the server that is absent the SMB2_GLOBAL_CAP_LARGE_MTU flag.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by Tal Aloni Friday, September 8, 2017 8:47 PM
    Friday, September 8, 2017 8:05 PM
    Moderator
  • Hi Bryan,

    I appreciate you taking the time to review the issue, your detailed answer is very helpful.

    Your findings confirm that something indeed got "lost in translation" and that the original designers of the protocol intended for large MTU to be a server feature.

    I have been working with Microsoft specifications for years, in all other cases, I didn't care if the MUST was really a MUST because there was no cost to conform to the MUST.

    This is a different case entirely, here you have a complex feature that is incompatible with what has historically been transported on port 445 and in some cases require updates of network related software (optimization and/or security), for many players, the cost of implementing large MTU is not negligible. relying on historic reasons to use confusing language is simply not good enough in this case.

    I know that Microsoft is making a big push to phase out SMB1, and I think that making the SMB2 specifications as clear as possible to partners and accurately discerning between server requirements and features should be part of that effort.

    Again, I feel strongly that the language should be corrected to reflect that large MTU is a server feature.

    Thanks again for your investigation into this,

    I won't be in SNIA’s SDC, but I'm willing to call whoever necessary if you need help making the case for the suggested change.

    Tal Aloni

    Friday, September 8, 2017 9:59 PM
  • Tal,

    Today I filed a request with the document owner to consider this issue.  I'll follow up with a post once an outcome has been determined.  There will be a delay as the request is considered.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, September 13, 2017 9:48 PM
    Moderator
  • Hi Tal,

     

    We were given the mandate that the documents be normative to Windows, thus: MUST: –Windows always does it, MUST NOT: –Windows never does it , SHOULD: –Windows does it, except as noted and MAY/SHOULD NOT: –Windows doesn’t do it, except as noted.  “As noted” refers to a behavior note in Appendix A ”Product Behavior”, indicated by <nnn> notation.  The statements are not necessarily written to constrain other implementations, but to match Windows, they’re necessary.  Doing anything other is untestable and unverifiable.

     

    The above was lifted from a 2011 presentation given by the owner of the specification at https://sambaxp.org/archive_data/SambaXP2011-DATA/day1/DevelopersViewOfMSDocumentation.pdf.  We discussed your issue.  Take particular interest in slides 15-19, especially slide 17.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, September 14, 2017 2:04 AM
    Moderator