RE: multiple TCP connections

[pat_thaler@agilent.com]

Milan,

Perhaps you have not read 802.3ad (the link aggregation
standard is part of the 802.3 standard rather than .1).

It does not specify that "all traffic between a given source/
destination" stays on one path. What it says is:

Frame ordering must be maintained for certain 
sequences of frame exchanges between MAC Clients
(known as conversations, see 1.4). The Distributor 
ensures that all frames of a given conversation are
passed to a single port. For any given port, the 
Collector is required to pass frames to the MAC Client
in the order that they are received from that port. 
The Collector is otherwise free to select frames
received from the aggregated ports in any order. 
Since there is no means for frames to be misordered
on a single link, this guarantees that frame 
ordering is maintained for any conversation.

Implementations are free to use any method they desire for
determining what a conversation is. Many implementations 
use the simplest method and distribute based on all or part
of the source and destination addresses. A more sophisticated
implementation could look deeper into the packet and use 
session to identify a converstation.

Pat

-----Original Message-----
From: Merhar, Milan [mailto:mmerhar@pirus.com]
Sent: Thursday, August 03, 2000 12:35 PM
To: 'Steve Byan'; ips@ece.cmu.edu
Subject: RE: multiple TCP connections


Steve,

The problem with relying on Layer 2 link aggregation 
such as 802.1ad, is that it protects against packet reordering 
by keeping all traffic between a given source/destination
pair on a single pipe of the multi-link.  So, unless you 
have multiple attachments at each end (with multiple MAC 
address and multiple IP addresses,) you're limited to a
maximum of (in the case of TCP/IP and Gigabit Ethernet) 
around 920 Mbps of aggregate traffic between two end points. 

And, although 900+ Mbps seems to be plenty of bandwidth for 
any single storage device, concerns have been raised that 
it may not be sufficient for the case, for example, of a 
storage array controller talking to a mainframe.

This, in fact, had been presented as one rationale for 
spawning multiple TCP sessions within a single iSCSI session.
Each TCP could potentially have separate IP and MAC end point 
addresses, allowing them to be carried in parallel through 
802.1ad inter-switch links.  (Although, I agree with you that
being able to take advantage of multiple protocol accelerators
is in itself a pretty good justification.)

On the other hand, It may be a close race between introduction 
of Storage-over-IP devices that can take advantage of multiple
parallel Gigabit Ethernet links, and initial availablity of 
10 Gigabit Ethernet LANs.  We might find ourselves having 
designed a clever, but more complex, way of accessing 
greater bandwidth, which is superceded by the brute-force
solution of faster transport technology.

- milan


> -----Original Message-----
> From: Steve Byan [mailto:steve_byan@hotmail.com]
> Sent: Wednesday, August 02, 2000 3:14 PM
> To: ips@ece.cmu.edu
> Subject: Re: multiple TCP connections
> 
> 
> Sorry, I didn't understand TCP multihoming. I've been reading 
> RFC 1122 and 
> RFC 1123 and discovered that TCP binds to exactly one of the local 
> multihomed addresses, and that TCP applications must choose 
> exactly one of 
> the multihomed addresses for the remote host. Multiple 
> sessions starts to 
> make much more sense.
> 
> I noticed that there is a standard for ethernet link 
> aggregation (IEEE  
> 802.3ad), and that routers are available that will 
> load-balance over a set 
> of links. Given these two, it seems to me that multiple TCP 
> connections 
> aren't needed for speed or reliability, assuming ethernet 
> links at the 
> end-points. Am I still missing something?
> 
> The argument that makes sense to me is that of parallelizing 
> the TCP load 
> across multiple hardware accelerators.
> 
> Thanks.
> 
> Regards,
> -Steve
> 
> Steve Byan <stephen.byan@quantum.com>
> 
> ______________________________________________________________
> __________
> Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com