Subject: [Gen-art] Gen-ART Review of draft-ietf-ipoib-connected-mode-02.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Feb 2006 18:16:03 -0600

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary: This document is on the right track for publication as a Proposed 
Standard. I do have some comments, but overall the document is in good 
shape.

Specific review comments:

There are a couple of places in the document that refer to 2^31-octet link 
MTUs for connected-mode Infiniband), and then talk about "reasonably large 
MTUs" without qualification. I would be more comfortable if the text talked 
about "reasonably large MTUs, up to the 64-kilobyte maximum IP length", just 
to manage expectations more clearly.

The document does attempt to explain "why use connected mode if datagram 
mode is most appropriate for IP?". The introduction names two advantages of 
connected mode (larger MTUs and enhanced reliability), but it would be nice 
to be a bit clearer ("These are the advantages of Infiniband connected mode 
over datagram mode:") - I'm not even sure from the text if these are the 
only advantages or not.

The document does talk about retransmission timer interaction with TCP RTO 
(in Section 7.1), and this is good, but the text suggests "the RC timers as 
well as the maximum message size supported at the IPoIB-RC connection must 
be set judiciously". This is actually harder than it looks, because TCP RTO 
is adaptive (with a minumum value of one second), so it would be nice to 
offer a little more guidance on selecting RC timer values.

In Section 8.0, Security Considerations, "A node may be returned a false set 
of flags by an imposter" is just a little too out-of-context for me to 
parse. Naming the operation being attacked and/or the message containing the 
false set of flags would help.

Editorial comments noticed during Gen-ART review:

In the second sentence of the Introduction, "The document [IPoIB_ARCH] 
provides" is awkward - the style used in the first sentence, "The InfiniBand 
specification [IB_ARCH] can be found" is clearer to me (this is a nit). 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Feb 2006 15:07:00 +0100

Spencer Dawkins wrote:
> Summary: This document is on the right track for publication as a 
> Proposed Standard. I do have some comments, but overall the document is 
> in good shape.
> 
> There are a couple of places in the document that refer to 2^31-octet 
> link MTUs for connected-mode Infiniband), and then talk about 
> "reasonably large MTUs" without qualification. I would be more 
> comfortable if the text talked about "reasonably large MTUs, up to the 
> 64-kilobyte maximum IP length", just to manage expectations more clearly.

What about IPv6 jumbograms? They were invented with HIPPI in mind,
but I'm sure they will go nicely over connected-mode IB.

      Brian

> mode is most appropriate for IP?". The introduction names two advantages 
> of connected mode (larger MTUs and enhanced reliability), but it would 
> be nice to be a bit clearer ("These are the advantages of Infiniband 
> connected mode over datagram mode:") - I'm not even sure from the text 
> if these are the only advantages or not.
> 
> The document does talk about retransmission timer interaction with TCP 
> RTO (in Section 7.1), and this is good, but the text suggests "the RC 
> timers as well as the maximum message size supported at the IPoIB-RC 
> connection must be set judiciously". This is actually harder than it 
> looks, because TCP RTO is adaptive (with a minumum value of one second), 
> so it would be nice to offer a little more guidance on selecting RC 
> timer values.
> 
> In Section 8.0, Security Considerations, "A node may be returned a false 
> set of flags by an imposter" is just a little too out-of-context for me 
> to parse. Naming the operation being attacked and/or the message 
> containing the false set of flags would help.
> 
> provides" is awkward - the style used in the first sentence, "The 
> InfiniBand specification [IB_ARCH] can be found" is clearer to me (this 
> is a nit).
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Feb 2006 08:53:16 -0600

Dear Brian,

Nice catch - thanks!

And my apologies (I've never seen a jumbogram on a network trace, so this 
was mentally mis-filed).

Spencer

From: "Brian E Carpenter" <[email-masked]>

>> link MTUs for connected-mode Infiniband), and then talk about "reasonably 
>> large MTUs" without qualification. I would be more comfortable if the 
>> text talked about "reasonably large MTUs, up to the 64-kilobyte maximum 
>> IP length", just to manage expectations more clearly.
>