Re: ipoib-cm multiple connection model

Let me try to understand what you are worried about:
I am assuming that each TCP connection (5-tuple) can be on its own CM
connection, and not multiplex a single TCP connection over multiple CM
connections.

Is this your understanding ?

Now if this is what we are talking about - we don't have a problem.  TCP
only guarantees in order delivery to a single connection - if I have
multiple TCP connections to the same hosts, IP packets can be completely
reordered/jumbled by the intermediate network - and all I am guaranteed
is that each TCP stream will have in order delivery relative to itself.

I am not aware of any applications where in order IP packet delivery is
required between multiple streams.  If this is the case - it has to be
handled above TCP anyway, as TCP does not make this guarantee.

Comments ?
Bill

Dror Goldenberg wrote:

> I think that the current model for multiple connections establishment 
> between
> two peers works well for 1 connection but is broken for more than one 
> connection.
> Because of cases where CM packets are dropped or travel on different 
> VLs, they
> might get reordered on the way and observed in a different order than 
> were originally
> sent. This breaks the current model which assumes that the REQs are 
> sent and
> processed in order.
>  
> I think that we need to think of a model which is robust to CM packets 
> reordering
> which can be one of:
> - Adding a "channel ID" in the private data. The field goes 0,1,2 and 
> on. It helps
>    synchronizing both peers on which is the channel at question now. 
> The rest
>    of the decision (per channel) of whether to accept or reject can be 
> the same
>    as defined in the draft.
> - Not supporting multiple connections between the same peers.
>  
> -Dror
>
>------------------------------------------------------------------------
>
>_______________________________________________
>IPoverIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ipoverib
>  
>