Re: ipoib-cm nits/clarifications

On Wed, 19 Oct 2005, Dror Goldenberg wrote:

> Technical comments:
> -page 7, "The node receiving the IB connection request, however cannot
> determine
>   the initiating node IP address". I don't think it needs to know the IP
> address. It
>   needs to know the Link Layer Address.
>   (The solution you propose solves the problem of knowing the peer link
> layer address.)

ok

>
> - page 7, section 3.3 - Isn't it worth at least noting that simultaneous
> connections are
>    handled differently than the IB active-active. This can be helpful to
> avoid confusion.



>
> - page 7, section 3.3 - need to be explicit about the numerical comparison
> of
>   link layer address. It is unclear who forms the MSbits, it is the QPN or
> the GID.

yes, will add that.

>
> - page 7, section 3.4, worth noting the following issues:
>    * since connection teardown is out of band in IB, some messages in
> transit can
>              be dropped as a result of teardown.
>    * simultaneous teardown can also happen (and is supported by the IB
> architecture)

I left the details out since it should be expected..however, we can add this
information.

>
> - page 10, section 6.0, I don't think that all CM messages should include
> the UD QPN
>    and the receive MTU. You need both of them in REQ. You only need receive
> MTU
>    in REP. And that's all. The rest are supposed to be persistent because
> of the
>    Communication ID being used.
>    This worth some discussion. I don't think that the current definition is
> broken, I just
>    think that it has some redundancy.

It is easier to go with one format so we can leave it as such.

>
> - page 10, section 6.0 - what is the final MTU of a connection ? is it the
> minimum between
>   the two "receive MTU" , or is it hybrid - different MTU per half
> connection ?

The receive MTU gives you the peer's minimum value. An implementation can
work this way. However, it might be useful to state it as the minimum
of the two in the draft..since an implementation is likely to use the 
the same size buffers when sending or receiving. That is if A advt. recv of 
32K it will very likely send packets which are only 32K even if the peer 
send a receive MTU of 64K.

thoughts?

>
>
> Some nits:
> - page 6, 4th paragraph, "the receiver", remove non ASCII char following it.
> - page 6, 8th paragraph, "the peer", same comment
will do

> - page 6 "RTA" should be "RTU"
ok
> - page 6, "The CM messages include...Service ID" - this is not true for
>    *all* the CM messages. So maybe worth rewording.
ok..
> - page 7, paragraph before 3.3, after "node" you have non ASCII, 2
> occurrences.
> - page 7, paragraph before 3.3, after "sender" you have non ASCII.
> - page 12, 12.0 remove non ASCII after "Author"
>
yep..need to figure out why they got in...

> My apologies if I'm repeating Jerry's comments...

np. thanks for the comments.

Vivek
>
> -Dror
>