Subject: Questions about TCP in linux system

From: Renato Narcisi <[email-masked]>
Date: Wed, 30 May 2001 03:41:01 -0700 (PDT)

Good morning to everyone,
I'm introducing some modifications to the
implementation of the TCP (Linux kernel 2.2.17)
in order to optimize performance in satellite
networks.

I have some problems and I hope you can help me:

1. I need the RTT value immediately after the 
sync phase between the two TCP entities.
Is the RTT evaluated during the sync phase? If so,
can you
suggest me in which variable is it stored (infact
the
RTT values should be stored in "tp->srtt", which is
zero after the sync phase)

2. I read in a book ("TCP/IP Illustrated" which
surely
referes to an older version of linux kernel) that
the
tcp_time_stamp is practically an integer number
which
counts "ticks" of 500msec and, as a consequence, it
is
updated every 500 msec... is it possible? how could
i
have a good evaluation of RTT if i can estimate only
ticks of such a big interval? 

I hope someone of You can kindly help me...

thank You in advance

Renato Narcisi

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: Mark Allman <[email-masked]>
Date: Wed, 30 May 2001 10:43:19 -0400

> 2. I read in a book ("TCP/IP Illustrated" which surely referes to
> an older version of linux kernel)

Actually, the above book covers BSD networking code.  A very
different animal than the linux code, I am sure.

> that the tcp_time_stamp is practically an integer number which
> counts "ticks" of 500msec and, as a consequence, it is updated
> every 500 msec... is it possible? 

Under BSD that is true.  I think linux has a finer-grained clock.  

> how could i have a good evaluation of RTT if i can estimate only

TCP does not try to obtain a "good evaluation of RTT".  TCP attempts
to determine an appropriate **retransmission timeout** (RTO), which
is a much different problem.  See the following paper for an
evaluation of the impact of clock granularity (among other things)
on the standard RTO algorithm:

    Mark Allman, Vern Paxson. On Estimating End-to-End Network Path
    Properties.  ACM SIGCOMM, September 1999, Cambridge, MA. 
    http://roland.grc.nasa.gov/~mallman/papers/estimation.ps

(The conclusion from the paper is that finer-grained timers provide
better RTO performance when used in conjunction with a fairly
healthy lower bound on the RTO.)

RFC 2988 outlines the standard RTO algorithm.

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/