[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] A problem of using FullTcp in wireless simulation (a bugsomewhere?)
Hi All,
I'm trying to solve the below problem and found a clue.
The problem is related with a wireless node.
In mobile node, when a station sends a packet, the packet
go through a routing agent like AODV or DSDV.
Routing agent adds IP_HDR_LEN (20byte) when the station is
only in the case of the sender. I note that ETHER_HDR_LEN is
also added in mac layer ( see sendDATA in mac-802_11.cc).
On the other hand, a receiver "did" strip off the mac header
in mac layer ( see recvDATA ), however, "didn't" strip off IP
header until agent receive the packet.
Because a packet doesn't go through routing agent in receiver side,
we should take off IP header in somewhere else.
I suppose that the easiest way to modify it is to deal with adding/
deleting both IP header length and Mac header length in 802.11
mac layer, instead of attaching IP header in mobile IP routing
protocol. This seems to be ad-hoc and not so good.
I would like to ask where we should add/delete IP_HDR_LEN
"in general" in spite of wireless or wired network. I'm not sure that
ns take care about IP header in wired network: I couldn't find out
a point that IP header len is added in wired node.
Ideally, we should attach IP header in the sender and take it off
in the receiver in IP layer.
Give me suggestion.
masa
----- Original Message -----
From: "Huaiyu Liu" <[email protected]>
To: "Lloyd Wood" <[email protected]>; <[email protected]>
Sent: Monday, July 30, 2001 3:22 PM
Subject: Re: [ns] A problem of using FullTcp in wireless simulation (a
bugsomewhere?)
> Yes, the added overhead of 28. Following is the trace file of that
> simulation.
> As indicated by the field -Il in the trace, the pkt size is 40 when sent
out,
>
> but it becomes 68 when received.
>
> A overhead of 28 is got when DSR is used. If AODV, DSDV or TORA is the
> routing protocol, then the overhead is 20.
>
> Could anybody give any hint on solving the problem? Or will anyone take
> care of this problem? Thanks.
>
> M 0.0 nn 2 x 100 y 100 rp DSR
> M 0.0 prop Propagation/TwoRayGround ant Antenna/OmniAntenna
> Sconfig 0.00000 using MOBICACHE
> s -t 2.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 10.00 -Ny 10.00 -Nz 0.00 -Ne
> -1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It
tcp -Il
> 40 -If 11 -Ii 0 -Iv 32 -Pn tcp -Ps 0 -Pa -1 -Pf 0 -Po 0
> r -t 2.014113877 -Hs 1 -Hd 1 -Ni 1 -Nx 90.00 -Ny 10.00 -Nz
0.00 -Ne -1.000000
> -Nl AGT -Nw --- -Ma a3 -Md 1 -Ms 0 -Mt 800 -Is 0.0 -Id 1.0 -It tcp -Il
68 -If
> 11 -Ii 0 -Iv 32 -Pn tcp -Ps 0 -Pa -1 -Pf 1 -Po 0
> s -t 8.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 10.00 -Ny 10.00 -Nz 0.00 -Ne
> -1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It
tcp -Il
> 40 -If 11 -Ii 3 -Iv 32 -Pn tcp -Ps 0 -Pa -1 -Pf 0 -Po 0
> r -t 8.000968800 -Hs 1 -Hd 1 -Ni 1 -Nx 90.00 -Ny 10.00 -Nz
0.00 -Ne -1.000000
> -Nl AGT -Nw --- -Ma a3 -Md 1 -Ms 0 -Mt 800 -Is 0.0 -Id 1.0 -It tcp -Il
68 -If
> 11 -Ii 3 -Iv 32 -Pn tcp -Ps 0 -Pa -1 -Pf 1 -Po 0
>
> - Huaiyu(Kitty) Liu
>
>
> Lloyd Wood wrote:
>
> > 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/>
>
> --
> ******************************
> Huaiyu (Kitty) LIU
> Dept. of Computer Sciences,
> UT at Austin
> (tel) 512-471-9734 (O)
> ******************************
>
>
>
>