Re: comments on draft-kashyap-ipoib-connected-mode-02.txt

FYI...I've submitted a new draft (ipoib-connected-mode-00.txt) including
all the changes discussed below.

The draft also mentions the issue Margaret brought up on possible 
interaction between TCP/reliable transport and RC retransmission causing
further congestion. The current draft cautions that the RC retransmissions
be set judiciously with the above in mind. Further discussion will be 
helpful on this issue.

Vivek

On Mon, 13 Dec 2004, Vivek Kashyap wrote:

> 
> 
> 
> 
> David,
> 
> Addressing your comments here rather than inline since this mailer doesn't
> do that well:
> 
> 1. QPN alingnment:
> Yes, there was a suggestion on QPN alignment. I'll address it in the next
> draft. Please send in any comments if you have any.
> 
> 2. "In addition to all the above, there may still be some interest from
> folks in having the specification choose one of the *C transport types
> and a fixed logical MTU."
> 
> Is it not an implementation issue? One can choose to enable only the
> desired mode and always use the fixed MTU in all negotiations.
> 
> 3.  ARP in IPoIB-CM.
> 
> It is still part of the definiton of IPoIB-CM.  It is just that it won't be
> over the Connected modes.We do ARP/RARP over the UD QP.
> 
> Vivek
> 
> --
> Vivek Kashyap
> Linux Technology Center, IBM
> [email protected]
> [email protected]
> Ph: 503 578 3422 T/L: 775 3422
> 
> 
> 
>                                                                                                                                        
>                       "David M. Brean"                                                                                                 
>                       <David.Brean@Sun.        To:       [email protected]                                                             
>                       COM>                     cc:                                                                                     
>                       Sent by:                 Subject:  Re: [Ipoverib] comments on draft-kashyap-ipoib-connected-mode-02.txt          
>                       ipoverib-bounces@                                                                                                
>                       ietf.org                                                                                                         
>                                                                                                                                        
>                                                                                                                                        
>                       12/12/2004 12:55                                                                                                 
>                       PM                                                                                                               
>                                                                                                                                        
>                                                                                                                                        
> 
> 
> 
> 
> Hello,
> 
> Vivek Kashyap wrote:
> 
> snip ...
> 
> >
> >ok..let me posit what seems to be the summary to me (looking for more
> comments
> >from WG members here). I'm more or less reverting to the earlier version
> of
> >the draft.
> >
> >In an IPoIB subnet:
> >
> >            - Every interface MUST support IPoIB-UD
> >
> >            - An interface MAY optionally also support IPoIB-CM (one or
> both)
> >                        i.e. removing the mutually exclusive restriction
> on rc/uc
> >                        Note: IIRC, the same serviceID can be used for
> both RC/UC.
> >                        If not then they have to stay mutually exclusive.
> >
> >            - Interoperability is maintained by all nodes supporting
> IPoIB-UD.
> >              Any two interfaces that do not have a connection mode in
> common will
> >              fall back to IPoIB-UD.
> >
> >            - The support of any particular IB mode is indicated by the
> flags
> >              in the link layer address. Note: IPoIB-UD is always
> supported and
> >              hence there are no flags to indicate UD support.
> >
> >            - An interface completes the IPoIB-UD address resolution and
> then
> >          optionally MAY set up RC/UC connections based on the local
> support
> >              and received flags.
> >
> >            - A pure IPoIB-UD implementation ignores the RC/UC flags in
> link layer
> >              address in received packets. It zeroes them on transmit.
> >
> >            - Every implementation MUST accept all unicast transmissions
> received
> >              over any of the IPoIB modes it supports. Multicast/Broadcast
> by
> >              their nature will be transmitted and received over the
> IPoIB-UD only.
> >
> >            ***This implies that an interface MAY transmit/receive a
> packet
> >                        over any of RC or UC or UD depending on the modes
> supported
> >                    between the peer IP and itself.***
> >
> >            - It is an implementation's decision to connect or retry a
> connect on
> >              failure on the CM modes. This decision is independently made
> per
> >              transmission or reception of a connection request.
> >
> >            - An implementation MAY make multiple connections to a peer.
> This
> >          is a local decision. So is the decision of the peer to refuse
> >          such a connection.
> >
> >            The serviceID, link setup, the link address flags, MTU
> negotiation etc.
> >            are covered in the draft.
> >
> >
> >
> 
> Wasn't there a suggested change to the alignment of the QPN in the
> service ID?  (See
> http://www1.ietf.org/mail-archive/web/ipoverib/current/msg01158.html).
> 
> >            - MTU -- we need to discuss more as below.
> >
> >
> >
> snip ...
> 
> >
> >The interface MTUs at the peers need not be the same at IP or IB layers.
> >
> >I agree with the concept of just exchanging the max receive MTU at the IB
> >connection setup.
> >
> >
> >
> In addition to all the above, there may still be some interest from
> folks in having the specification choose one of the *C transport types
> and a fixed logical MTU.
> 
> Also, the I-D mentions ARP and RARP as "protocol types" in the frame
> format.  Seems like these would not apply to connected modes.
> 
> -David
> 
> 
> 
> 
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
>