Well, I assume that cong_action is Congestion Action, and dropped packets are mainly caused by congestion, which leads to retransmission. So this makes sense. Thanks Amit! - Arne
_____ Fra: Amit Mondal [mailto:[EMAIL PROTECTED] Sendt: 28. juni 2006 00:13 Til: Arne Lie Emne: Re: [ns] TCP and packet drop: where are the retransmitted packets? Hi Arne, Are u sure ns-2 mark "A" flag only for retransmitted packet. In the trace.cc file it says cong_action only, not retransmitted packet. Rgds -Amit On 6/27/06, Arne Lie <[EMAIL PROTECTED]> wrote: Actually; I just discovered that the retransmitted packets ARE there in the trace file. The TCP sequence number (column two from the right) is used as it should, in addition an "A" flag is used to mark a retransmitted packet. Something went wrong with my first search on this topic. Again, ns-2 is my best friend, and thanks to Phil and Ethan for their time. - Arne > -----Opprinnelig melding----- > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne > av Phil Miller > Sendt: 27. juni 2006 14:30 > Til: Arne Lie > Kopi: [email protected] > Emne: Re: [ns] TCP and packet drop: where are the > retransmitted packets? > > >From what I've observed, the normal TCP agents don't > actually reliable > send each packet in the stream, they only simulate the flow > and congestion control dynamics that TCP would exhibit, so > that the amount of generated traffic is accurate. Give the > FullTCP agents a try. > > Phil > > On 6/27/06, Arne Lie < [EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > For some time I have only been interested in the congestion > response > > of the different TCP congestion control algorithms, and the way it > > balances flow throughput to available capacity, packet drop > statistics, etc. > > > > However, now I need to see how well TCP tackles > retransmissions, e.g. > > with SACK. When I inspect the event trace file, dropped > packets are "never" > > retransmitted, in that ns-2 seems to increment the sequence numbers > > (both per flow and per simulation) all the time, > > >>>>>>>making it impossible to know WHEN a retransmission > is performed. > > <<<<<<<<< > > > > Is this a correct observation? If yes, are there any > workarounds? If > > incorrect, how *do* I find the retransmission event, and e.g. how > > *many* packets are duplicated/retransmitted (SACK vs. non-SACK)? > > > > best regards > > > > Arne > >
