All of lore.kernel.org
 help / color / mirror / Atom feed
From: bert hubert ahu@ds9a.nl
To: lartc@vger.kernel.org
Subject: [LARTC] TEQL question
Date: Sun, 17 Dec 2000 19:39:43 +0000	[thread overview]
Message-ID: <marc-lartc-98373938217034@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938217031@msgid-missing>

<PRE>On Sun, Dec 17, 2000 at 02:00:45AM +0100, Rene 'Lynx' Pfeiffer wrote:

&gt;<i> uniformly under load. The same is true for UDP floods. When using single TCP
</I>&gt;<i> transfers (for example SCP from the SSH package) not all 8 links are used. The
</I>&gt;<i> packets use 3 or 4 links of the 8.
</I>
I think this is how it is supposed to work, I'm afraid. What happens is
this. The outgoing side initially queues a few packets, but not too much.
That is how TCP works - by receiving ACKnowledgement packets from the
remote, the sending side knows how much data it can send.

It will now wait until the remote ACKs the first three packets, say, and it
will then send a couple more. The problem is that while your bandwidth has
gone up, your latency hasn't. 

This means that in order to use all 8 of your links, the sending side should
ship 8 packets 'into the blind', without acknowledgement. You might make
this possible by raising the window size on the receiving side.

However, then there is the dark problem of packet reordering. Lets say 8
packets are sent simultaneously, they can arrive in any order and it is
highly unlikely that this order is 1 2 3 4 5 6 7 8.

Lets say the order is 1 3 8 2 6 5 4 7, the receiving side might interpret it
as follows:

	1: ok -&gt; ack up to 1
	3: missed packet 2 -&gt; ack up to 1
	8: missed packet 2, 4, 5, 6, 7 -&gt; ack up to 1
	2: missed packet 4, 5, 6, 7 -&gt; ack up to 3
	6: missed packet 4, 5, 7 -&gt; ack 3
	5: missed packet 4, 7 -&gt; ack up to 3
	4: missed packet 7 -&gt; ack up to 6
	7: ack up to 7

The sending side receives the following:

ack 1, ack 1, ack 1, ack 3, ack 3, ack 3, ack 6, ack 7

This will probably be interpreted as 'packet 1 got lost, lets resend it',
'packet 3 got lost, lets resend it'. This is not the case however, but all
this resending makes the sending kernel decide to slow down, and lower the
'congestion window'.

This means that the kernel will not allow a lot of packets to be 'in flight'
simultaneously.

&gt;<i> Any ideas? I would like to distribute the load over all 8 links.
</I>
If you have a lot of separate streams going, it gets better. Also, if the
receiving side is Linux, it might get less confused by this packet
reordering. I think regular Linux is able to reorder up to 3 out of place
packets.

&gt;<i>  GNU/Linux Manages! - Support, Administration, Consulting
</I>&gt;<i>   RP3191-RIPE       - Networking, Programming, Installation
</I>
Good luck!

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet


</PRE>

  reply	other threads:[~2000-12-17 19:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-17  1:00 [LARTC] TEQL question Rene
2000-12-17 19:39 ` bert [this message]
2003-02-19 23:14 ` [LARTC] teql question Bartlomiej Zarzecki
2003-02-20 14:54 ` Bartek Krajnik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-98373938217034@msgid-missing \
    --to=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.