From: Juan Francisco Torreblanca (juan.torreblanca@tartec.com)
Date: 10/29/03
Subject: RE: tcptrace RTT time evolution; SACK in tcptrace Date: Wed, 29 Oct 2003 13:47:30 +0100 Message-ID: <CAC72BB3C3E1E245AB6084426EDCBCB819F4E4@tartessos.tartec.local> From: "Juan Francisco Torreblanca" <juan.torreblanca@tartec.com>
Hi,
Thanks a lot Mani, your information has been really useful and accurate,
now a have a file with raw rtt and its temporal information.
I'm going to develop RTO and retransmission timer function (most
probably using matlab) in order to print them together with the RTT
samples. If someone is interested I'll be pleased to provide them as
soon as I do it.
Regarding the question of retransmission due to RTO or packet loss
detection, I've been checking tcptrace stats with the relative ethereal
trace following Mani suggestion and they don't match: retrx packets 5,
triple dupacks 2, but no more than 1 RTO has happened.
Probably SACK option (which it is enabled) affects to this mismatching,
looking into the traces I found that a retx happens with 3 dupacks
(containing SACK) and in a short time a couple of retx happens only with
2 dupacks (containing SACK), I don't know how congestion control acts
after a retx due to SACK, any hint? And also, does anyone know how
tcptrace treats SACK? (Could it be known the number of retx due to
SACK?)
Rgds,
Thank you very much,
Juan Torreblanca.
-----Original Message-----
From: Manikantan Ramadas [mailto:mramadas@masaka.cs.ohiou.edu]
Sent: Monday, October 27, 2003 10:42 PM
To: Juan Francisco Torreblanca
Cc: tcptrace@tcptrace.org
Subject: Re: tcptrace RTT time evolution
> relative time. Do you know if it is possible to do it with tcptrace?
> (Somehow to have the mentioned raw RTT samples files with time
reference
> as well) Any other option in negative case?
Well, getting temporal information along with the raw RTT samples is
pretty easy.
In file rexmit.c, look for the dump_rtt_sample() function that actually
does the job.
You just need to modify the last statement of the function :
Mfprintf (ptcb->rtt_dump_file, "%lu %lu\n",
pseg->seq_firstbyte,
(int) (etime_rtt / 1000) /* convert from us to ms */ );
into something like :
Mfprintf (ptcb->rtt_dump_file, "%ld.%ld %lu %lu\n",
current_time.tv_sec, current_time.tv_usec,
pseg->seq_firstbyte,
(int) (etime_rtt / 1000) /* convert from us to ms */ );
Note : current_time is the timeval structure that contains the pcap
timestamp
of the ACK segment that caused the generation of this RTT sample.
> I would also need to know if tcptrace shows the number of
retransmission
> timer expirations, I know it shows the number of retransmission
packets
> but I would need to distinguish the retransmission due to timer
> expiration and packet loss detection (I mean retransmission trigger by
> fast transmission algorithm).
>
Well, the long output (options : -lr) also carries a field
"triple dupacks" indicating the number of triple dupacks seen. One
possible
heuristic would be to infer "triple dupacks" number of "rexmt data pkts"
as retransmissions due to fast-retransmit and the remainder of
"rexmt data pkts" as retransmissions due to RTO timeout (assuming we
captured all the retransmissions that followed triple dupacks in the
trace file).
- Mani.
-- "Strength does not come from physical capacity. It comes from an indomitable will." - Mahatma Gandhi ____________________________________________________________________ * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas * ____________________________________________________________________ ---------------------------------------------------------------------------- To unsubscribe, send a message with body containing "unsubscribe tcptrace" to majordomo@tcptrace.org.
This archive was generated by hypermail 2.1.7 : 10/30/03 EST