[c-nsp] Effect of simultaneous TCP sessions on bandwidth

[Youssef Bengelloun-Zahr]

Le 11 nov. 2013 à 06:21, Randy <randy_94108 at yahoo.com> a écrit :

> aah, so there is a 100M port in the picture.

Yes, wrote that in my first email :-)

> 
> the best you can achieve is 90M of throughout; which you are.

True and verified.

> 
> for UDP; given the nature of the protocol - a sends a packet-of-a-certain size and waits for an ack(the time it takes for ack to get back to A is dependant on the RTT of this link) before sending the next packet. So A sends a packet to B. Similarly, B does the same but there is the period of RTT where a doessn't send anything to B and B does the same. In other other words, you could very well have a situation where both endpoints report a throughput of 90M for simultaneous transfers because neither side sends a packet during the RTT.

Agreed.

> 
> TCP on the otherhand, is a completely different beast(congestion control, loss etc wrt the concept of slow-start; since it is session-oriented: see my previous response about how timestamping to determing RTT will cause slow-start to kick in)

Agreed.

> 
> In this case the 100 M port will buffer; tcp will as a result see an increase in RTT and throttle back.....no packets have to be dropped for this to happen. The main purpose of TCP is guaranteed-delivery unlike UDP.

Agreed.

> 
> It appears you have a clean-link and upstream is correct *when they talk about the nature of TCP*
> 
> If possible get the slowest-link to be a Gig on both ends and re-test. You will see a difference.

I think that getting ride of this FE port will help as it is a possible botttleneck. Still, it's a question of $$$

> 
> ./Randy
> 
> 
> 
> 
> 
> ----- Original Message -----
>> From: Youssef Bengelloun-Zahr <youssef at 720.fr>
>> To: Randy <randy_94108 at yahoo.com>
>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Sent: Sunday, November 10, 2013 1:26 PM
>> Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth
>> 
>> 
>> 
>> Le 11 nov. 2013 à 04:22, Randy <randy_94108 at yahoo.com> a écrit :
>> 
>>> 
>>> 
>>>>>>       - TCP traffic hits some kind of limit and isn't able
>> to achieve more
>>>>>> than 40-60 Mbits/s in average      <=== That's the
>> problem we are facing
>>> 
>>> what happens if you do this - 
>>> 
>>> 
>>> a transfer from host A(fra) to host B(ham) and another transfer at the same
>> time from host D(ham) to host C(fra)? Do still avg at 90M for each transfer or 
>> do both drop to the 40M avg? If you pull off 90M it would eliminate the link. If 
>> not; since you have enabled high performance options, tcp timestamping used to 
>> calculate RTT perceives congenstion(with the increase of traffic across link) 
>> and initiates slowstart.
>> 
>> Hello,
>> 
>> Funny you mention this :
>> 
>> a- first, we start transfer from A (FRA) to B (HAM), we achieve BW close to 90 
>> mbits/s,
>> 
>> b- second, we start transfer from B to A (while first transfer is running) and 
>> BW for first transfer collapses.
>> 
>> 
>>> 
>>> if what you are seeing only applies for simultanours transfers:
>>> 
>>> A To B and B to A, It would seem to imply A and B are the bottlenecks.
>> 
>> Hello, seems very unlikely to me :
>> 
>> - At location A, we have a Brocade CER-RT acting as a PE delivering Layer 2 
>> service to the customer.
>> 
>> Customer server is directly connected using a GigE port.
>> 
>> - At location B, we have some kind of Alcatel CPE provided by LL provider.
>> 
>> Customer server is directly connected using a FE port.
>> 
>> Thanks.
>> 
>> 
>> 
>>> 
>>> hth,
>>> ./Randy
>>