analysis of TCP flags
analysis of TCP flags
oc32tflags.pl is being used for an
analysis of some aspects of TCP flags.
sample results:
(older stuff:)
WAN mice
wide area mice -- a tragedy in 3 acts
(two different traces, updated 15 feb 97)
(inspired by dkerr and tli and
other fine upstandingly
inquisitive router building citizens
wondering
``Just what is this shit?''
This page not for young children or
anyone who thinks CDA stands for something)
Data: two 20min-ish FIXWest traces, 9/96 and 1/97.
(need ICM trace, think it's even more
tragic over there)
Goal of study: Give router vendors info on
wtf they're building stuff to switch.
Characterize the 40-byte packets,
the packets with flags set,
and the retransmitted packets.
From a very macroscopic perspective.
Gory details in tables at bottom,
we'll go thru the highlights.
tables below.
Ulterior goal: Get router vendors to sponsor Caida research.
For 40 byte packets:
-
How many are TCP? What are the others?
-
over 99% of the 40-byte packets are TCP.
ICMP, IGMP, UDP send a few. see table 2.
-
How many are SYN? SYN|ACK?
-
Very few 40-byte SYNs actually, less than .5%.
Most SYNs at this
collection point are 44 bytes (hellloo MSS option.)
can anyone verify this at other points for us?
@@Darren what's this you're saying about your
SYNs doing ttcp? what's up with that?? what's
a SYN doing ttcp for? or you meant a ttcp run
doing SYNs, and you're just randomly running a
lot of ttcp?
-
How many are RST?
-
Of the 40-byters
(26 and 18% of the total packets in the two traces,
i think it's more at ICM that's why i want to run
this script on ICM traces),
about 5% of them are pure RST,
but another scattered few have
RST plus other flags, most likely RST ACK.
But also some RST ACK PSH,
RST PSH, FIN RST ACK (hi there, PC TCP.),
and RST URG. Anyway, all those enhanced RSTs together
are less than 1% of 40-byters. (the 40s)
-
How many are FIN? FIN+ACK?
-
In 27 million packets, one lonely ackless FIN
(from a web server but didn't go find which one)
FIN ACKs are about 5-6% of your 40s.
A few FIN PSH ACKs,
and 1 FIN ACK URG, our FIN RST ACK from above,
and a FIN PSH ACK URG
[k to PC TCP: oh, now you're just showing off.]
-
how many 40 bytes are ACKs?
-
In both these traces,
about 95% of the 40s have the ACK bit set.
-
How many are retransmitted ACKs?
- You're not going to like this...
I'm just going to have to walk through
the whole re-mice table line by line:
total packets: 1.5M 1.16M
rexmitted TCP packets 3463748 1786628
retransmitted TCP mice (40) 2588665 1211293
of the re-mice:
flags packets 40s prc flag names flags packets 40s prc prcAgain[estimated]
====== ======= ======= =========== ====== ======= ======= ========
1 1 0.000 FIN 100
lovely, the single nakedFIN in all
the two traces meets my defn of retransmitted.
impressive.
maybe the first FIN was a FIN ACK or something.
would take too long for me to go back and figure out now.
hold peace.
2 4542 0.114 SYN 2 1633 0.080 25
4 75717 1.900 RST 4 15039 0.740 10-20
c 1091 0.027 RST PSH c 148 0.007 50
man over half of those puppies had to
be retransmitted, i guess being PSHy isn't
paying off here
10 2313424 58.065 ACK 10 1117806 55.032 65
notice that eighty six percent of the
forty-byte packets are ACKs, and
55-58% of the forty-byte
packets are retransmitted ACKs. Zoinks.
11 108916 2.734 FIN ACK 11 55636 2.739 50
12 4682 0.118 SYN ACK 12 2005 0.099 17
only about one-sixth of them get to go again.
guess no windowed-data'ed yet. [still on honeymoon]
14 14310 0.359 RST ACK 14 8765 0.432 60-65
15 19 0.000 FIN RST ACK 15 19 0.001 100
Only 19 of these in the whole trace, all retransmitted.
That host really wanted out of that relationship.
18 32964 0.827 PSH ACK 18 7998 0.394 70-80
19 31400 0.788 FIN PSH ACK 19 1643 0.081 80-97
1c 1577 0.040 RST PSH ACK 1c 596 0.029 40
24 16 0.000 RST URG 95
only 17 of these packets; 16 of them
apparently rexmits of the first one.
talk about a persistent connection
[k waves to PC TCP]
30 6 0.000 ACK URG 67
[only 9 to begin with; k waves to PC TCP]
39 5 0.000 FIN PSH ACK URG 83
[only 6 to begin with, k waves to PC TCP]
per dennis request about mbone packets
last updated 17 feb 97
questions or comments: kc@nlanr.net.