Mon, 31 Jul 2006, Oumer Teyeb wrote:
-If multiple timeouts occur for one packet then even if we are using the
timestamp option or FRTO TCP linux is not able to detect spurious
retransmissions... and TCP linux is able to detect spurious retransmissions
only for a single timeout for one packet
consideration on
my future postings.
Thanks for the tip!!
Regards,
Oumer
David Miller wrote:
From: Oumer Teyeb <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 19:49:28 +0200
it would be so great if some of you could spare a few minutes and take a
look at the traces I provided.see below f
ormal behaviour occured after only a couple of packets
were retransmitted...here it took quite some retransmissions before the
same problem happend... any insight into this is greatly appreciated!!
Thanks in advance,
Oumer
Oumer Teyeb wrote:
Hi all,
I have some questions regarding Linux TCP i
Hi all,
I have some questions regarding Linux TCP in the presence of delays or
packet drops. It is somehow long mail, but the questions are two or
three, just wanted to provide a detailed information so that the problem
is clear. thanx for the patience!!
Best regards,
Oumer
Note that for th
download times)? because I
couldnt figure it out,also is there anywhere where the reordering
response of tcp linux described? (it seem dupthreshold is dynamically
adjusted based on the reordering history... but I was not able to find
out how...)...
Oumer Teyeb wrote:
Oumer Teyeb wrote:
Hi
Oumer Teyeb wrote:
Hi,
Alexey Kuznetsov wrote:
Condition triggering start of fast retransmit is the same.
The behaviour while retransmit is different. FACKless code
behaves more like NewReno.
Ok, that is a good point!! Now at least I can convince myself the
CDFs for the first
Hi,
Alexey Kuznetsov wrote:
Condition triggering start of fast retransmit is the same.
The behaviour while retransmit is different. FACKless code
behaves more like NewReno.
Ok, that is a good point!! Now at least I can convince myself the CDFs
for the first retransmissions showing that SAC
Hi ,
Alexey Kuznetsov wrote:
Hello!
DSACK) is used, the retransmissions seem to happen earlier .
Yes. With SACK/FACK retransmissions can be triggered earlier,
if an ACK SACKs a segment which is far enough from current snd.una.
That's what happens f.e. in T_SACK_dump5.dat
01:28:15.
Hi David,
I am using an emualtor that I developed using netfilter (see
http://kom.aau.dk/~oumer/publications/VTC05.pdf for a description of the
emulator).. and I emualte a UMTS network with RTT of 150ms, and I use a
384kbps connection. There is UMTS frame erasure rate of 10%, but I have
persi
Could you please CC your answers to me? thanx!
Oumer Teyeb wrote:
Hi Stephen,
Thanks for the quick response.
I have done what you asked and you can find the files at
www.kom.auc.dk/~oumer/sackstuff.tar.gz
I have run the different cases 10 times each,
NT_NSACK[1-10].dat---no timestamp, no
hesistate to ask me if anything is not clear...
Thanks a lot for taking the time
Regards,
Oumer
Stephen Hemminger wrote:
On Tue, 18 Jul 2006 18:20:47 +0200
Oumer Teyeb <[EMAIL PROTECTED]> wrote:
Hello Guys,
I have some questions regarding TCP SACK implementation in Linux .
As
Hello Guys,
I have some questions regarding TCP SACK implementation in Linux .
As I am not a subscriber, could you please cc the reply to me? thanks!
I am doing these experiments to find out the impact of reordering. So I
have different TCP versions (newReno, SACK, FACk, DSACK, FRTO,) as
i
12 matches
Mail list logo
