Re: 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.


> > To be explicit, I think there is benefit in implementing one and only one
> > of the two.  Having two options serves no purpose and adds unnecessary
> > complexity.  Interoperability will end up requiring both to be done if
> > customers are to not get upset.  Let's just pick one of the two and apply
> > KISS.  To get this started, I'll propose RC as that is a bit nicer to the
> > fabric than UC and is already implemented in most OS and CA drivers today
> > so it makes it faster to adopt with minimal driver software update.
> >
> > <snip>
> >
> > > > If a designer is stupid, they may do this. However, one would 
> expect some
> > > > intelligence here and one may prefer to have specific data flows or
> > > > DiffServ code points or whatever used to determine which connection or
> > > > which UD QP and that one would again apply an intelligent and 
> predictable
> > > > algorithm such that mix-n-match for a given TCP connection does not
> > > > occur.  Given multiple *C QP can be supported, it is not tenable to 
> state
> > > > that all unicast must go over a given QP or that no unicast can 
> occur on a
> > > > UD QP.
> > > >
> > >
> > >You mised my point which was that the specification cannot be silent 
> on this
> > >and say it is a local issue. That can lead to interoperability 
> failure. The
> > >specification must support or disallow  unicast communication over UD QP
> > >in an
> > >IPoIB-CM.
> > >
> > >You prefer that such communication be supported. That works. Any other
> > >thoughts?
> >
> > I prefer that guidance be provided and that it remain a local
> > implementation issue as to what QP is used for a given flow.  I do not see
> > interoperability issues only potential performance if people are
> > stupid.  The industry has a way to deal with stupidity and too much 
> time is
> > spent on preventing people from being stupid.  Even a so-so intelligent
> > implementation could have a simple flag for a given target IP address that
> > states which QP to target for all or a subset of the flows with minimal
> > cost to implement and troubleshoot / validate.
>
>If something is left unspecified there is every chance that incompatible
>implementations result - this has nothing to do with the mental faculties
>of the implementors. Therefore I'll add relevant text.

One can just provide an implementation note to avoid any mental short 
comings and still avoid specifying this.  That should be sufficient while 
maintaining KISS.

Mike

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib