[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ns] A problem of using FullTcp in wireless simulation (a bugsomewhere?)



On Thu, 26 Jul 2001, Huaiyu Liu wrote:

> Hi all,
> 
> I'd like to use FullTcp in some wireless simulations. However, it seems
> that currently,  FullTcp upon a wireless link does not work well.
> ( I used ns-2.1b8a and run simulations on a Linux machine.)
> Attached is a tcl script I used for a simple scenario. The topology is
> like:
> 
>                    wireless link
> n0 <-----------------> n1
> FullTcp-agent                         FullTcp-agent
> 
> And I got the following error messages:
> 1.015565: FullTcpAgent::recv(_o46): bad ACK (29) for our SYN(1)
> 1.016846: FullTcpAgent::recv(_o47) got packet lacking ACK (seq 29)
> 7.000969: FullTcpAgent::recv(_o47) got packet lacking ACK (seq 29)
> 7.015133: FullTcpAgent::recv(_o46): bad ACK (29) for our SYN(1)
> 7.016474: FullTcpAgent::recv(_o47) got packet lacking ACK (seq 29)
> 
> I've diggen into tcp-full.cc a little bit, and find that something was
> wrong when the first SYN packet was received by node n1. The
> correct process should be:
> n0 ---------------------> n1
>        SYN, sequence #=0
> n0 <--------------------- n1
>         SYN + ACK (ack # =1)
> .................
> 
> However, in the wireless simulation, the ack number from n1 was set
> incorrectly. The process is like:
> n0 ---------------------> n1
>        SYN, sequence #=0
> n0 <--------------------- n1
>         SYN + ACK (ack # =29)
> .................
> 
> And, the reason ack is set to 29 is: in the recv() function of tcp1
> (attached to n1),  the packet size (th->size() , where th is a hdr_cmn
> pointer) is modified to 68 (40 is the right value, which is equal to the
> 
> sum of the size of tcp header(40) and datelen(0)).
> 
> Does anybody have a clue to what could be wrong? I suspect it may be
> the link layer or the MAC layer that accidently modifies the packet
> size.
> I also printed out some debugging messages, and hope that may help.

We had a similar problem in the satellite code; basically simulating
IP-in-IP tunnelling by adding 20 to packet size (emulating existing
wireless code) but forgetting to take it off later - and FullTcp
really does work on packet size, rather than an ACK bit.

The wireless code does add similar overhead - but last I looked, it
remembered to take it off, too. An overhead of 28 is new...

L.

<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>