RE: A Couple of IPoIB Questions
Dror Goldenberg <[email protected]> Sat, 20 Nov 2004 18:49:08 +0200
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
-----Original Message----- From: Michael Krause [mailto:[email protected]] Sent: Friday, November 19, 2004 3:45 AM To: Vivek Kashyap Cc: IPoverIB Subject: Re: [Ipoverib] A Couple of IPoIB Questions At 05:14 PM 11/18/2004, Vivek Kashyap wrote: RC and UC both have benefits. There is almost no difference other than the connection flag between the two. Many host OS implementations do not support UC as RC and UD are all that is really required within the industry. The ACK overhead associated with RC is truly noise and the end-to-end credits are very nice as IB now supports three signaling rates combined with 4 link widths (though only three are really being implemented). Such a permutation in bandwidth capability makes RC a more tenable / good citizen as we designed it to be so I'd prefer RC. [DG] Mike, A few reasons I think that the end to end credits / RNR in an RC connection is a problem. It may be worth discussing it: 1) Lack of receive WQEs in the responder implies a slow responder. Getting the messaged dropped in this case is desirable from protocols that have injection control such as TCP. In this case it is supposed to back off and restart slowlier. While UC/UD result in a similar behavior of messages being dropped at the receiver when it's slow, RC does not. Instead, there is persistence in getting the message transmitted and the receiver won't be able to tell the requester that it's being slow. 2) How would you configure the RNR retry counters. Would they be configured to infinity ? Doesn't sound good. Would they be configured to a finite value (should be <7), in which case, in the case of a slow receiver you'd end up recreating connections that had end to end credits problem, which is a real overhead on the protocol. 3) What happens with implementations that don't support RNR Nak generation ? That poses more difficulties on (2). _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib