:
On 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
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
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
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
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
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
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
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
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
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
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 I am
11 matches
Mail list logo
