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: ns-users@isi.edu > 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 > >
