Marker PDU Aligned Framing for TCP Specification
draft-ietf-rddp-mpa-08

[Ballot comment]
This did not rise to the level of blocking, but I found this disquieting:


  (2a) only indicate a preference to not use CRCs on the explicit
      request of the system administrator, via an interface not defined
      in this spec.  The default configuration for a connection MUST be
      to use CRCs.



  The decision for hosts to request CRC suppression MAY be made on an
  administrative basis for any path that provides equivalent protection
  from undetected errors as an end-to-end CRC32c.


Like many "consenting adults" statements in protocol documents, it leaves open
how the two consent.  The second statement also presumes path stability,
which seems a pretty dubious proposition for anything not limited to a single
link.


Nit:

AOne deterministic approach

State Change Notice email list have been change to rddp-chairs@tools.ietf.org, steph@sandburst.com, paul.culley@hp.com, uri@broadcom.com, recio@us.ibm.com, carrier@cray.com from rddp-chairs@tools.ietf.org, rrs@cisco.com, caitlinb@siliquent.com, hemal.shah@intel.com, vivk@us.ibm.com, sganguly@yahoo.com, steph@sandburst.com, paul.culley@hp.com, uri@broadcom.com, recio@us.ibm.com, carrier@cray.com

PROTO writeup:

Stream Control Transmission Protocol (SCTP) Remote Direct Memory Access
            (RDMA) Direct Data Placement (DDP) Adaptation
                    draft-ietf-rddp-sctp-02.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited review outside the WG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Most of the WG is primarily interested in rddp over TCP.  There is limited
interest in SCTP.  The portion of the WG that is interested in SCTP
understands and agrees with this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The online ID nits checker says everything is ok.

  1.h) Is the document split into normative and informative references?

Yes.  All references are normative.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are four normative references to Internet-Drafts:

o draft-ietf-rddp-ddp, draft-ietf-rddp-rdmap - publication has
already been requested.
o draft-ietf-tsvwg-sctpsocket, draft-ietf-tsvwg-addip-sctp -
I don't know the completion schedule for these tsvwg drafts.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

  This document describes a method to adapt Direct Data Placement (DDP)
  and Remote Direct Memory Access (RDMA) to Stream Control Transmission
  Protocol (SCTP) RFC2960 using a generic description found in
  the RDMA and DDP specifications.  This adaption provides a method
  for two peers to know that each side is performing DDP or RDMA thus
  enabling hardware acceleration if available.

  Some implementations may include this adaptation layer within their
  SCTP implementations to obtain maximum performance but the behavior
  of SCTP will be unaffected.  In order to accomplish this we specify
  the use of the new adaptation layer indication as defined in the
  SCTP ADDIP specification.

-- Working Group Summary

  In contrast to the lengthy discussion of how to adapt rddp to TCP,
  there has been very little controversy over or dissent from this
  draft's approach for adapting rddp to SCTP.

-- Protocol Quality

  The protocol has been reviewed for the rddp WG by David L. Black.
  Randy Stewart, an SCTP expert, is a co-author of this draft.

PROTO writeup:
              Marker PDU Aligned Framing for TCP Specification
                    draft-ietf-rddp-mpa-03.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited IETF review outside the WG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

This draft contains a significant quantity of TCP-specific behavioral
details.  The WG has settled on an approach that does not involve
making changes to TCP.  Expert Review from a TCP expert would be a
good idea to make sure that nothing has been overlooked that could
result in an unintended TCP change or unwarranted restriction.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG as a whole understands and agrees with this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

Not recently.  Doug Otis ceased participating in the rddp WG a long time
ago.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits online checker says everything is fine.

  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

The only normative reference to an Internet-Draft is:
o draft-ietf-rddp-security - publication has already been requested.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

  MPA (Marker Protocol data unit Aligned framing) is designed to work
  as an "adaptation layer" between TCP and the Direct Data Placement
  [DDP] protocol, preserving the reliable, in-order delivery of TCP,
  while adding the preservation of higher-level protocol record
  boundaries that DDP requires. MPA is fully compliant with applicable
  TCP RFCs and can be utilized with existing TCP implementations. MPA
  also supports integrated implementations that combine TCP, MPA and
  DDP to reduce buffering requirements in the implementation and
  improve performance at the system level.

-- Working Group Summary

  The degree to which TCP should be changed for MPA (and hence the
  rddp protocol stack) has been a source of controversy.  The WG has
  adopted an approach that requires no TCP modifications, and there is
  now strong WG consensus for that approach.

-- Protocol Quality

  The protocol has been reviewed for the rddp WG by David L. Black.
  There are multiple implementations of the MPA protocol, including
  the Request and Reply frames for connection setup added by the WG
  at the direction of the Transport Area.

State Change Notice email list have been change to rddp-chairs@tools.ietf.org, rrs@cisco.com, caitlinb@siliquent.com, hemal.shah@intel.com, vivk@us.ibm.com, sganguly@yahoo.com, steph@sandburst.com, paul.culley@hp.com, uri@broadcom.com, recio@us.ibm.com, carrier@cray.com from black_david@emc.com