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

[ns] ns problem: FullTcp packet size (fwd)



I've never used ad-hoc networking, and my comments related to the
satellite routing code, which was adding (but not later
subtracting) 20 bytes overhead for tunnelling. That copied some mobile
code.

And you don't say what version of ns you're using; I'd hope this was
fixed throughout by now.

anyone?

munging packet sizes (rather than having specific flags) just isn't
that robust.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---------- Forwarded message ----------
Date: Thu, 22 Feb 2001 17:46:58 -0500 (EST)
From: Prithwish Basu <pbasu@bu.edu>
To: l.wood@eim.surrey.ac.uk
Subject: ns problem: FullTcp packet size

Hello Lloyd,

This is regarding the ns-2 simulator - in particular the FullTcp agent..
Upon searching the ns users mailing lists I could see that you had written
a response (sometime in June 2000) which could solve my problem; hence
this mail...

I was having trouble with the initial SYN/ACK exchange in FullTcp over a
simulated wireless ad hoc network (currently static) using DSR for
routing. I am getting errors like "Bad ACK (33) for my SYN (1)" etc. at a
node that is expecting a SYN/ACK and there was a gap of 32 in all the
subsequent retries. Then I traced that this is due to the "datalen"
variable being set to 32 after the first SYN reaches. This happens in the
beginning of FullTcpAgent::recv() as datalen = common hdr size - tcp
header size = 72 - 40 = 32.

Now, before sending the SYN packet, I traced that the common header size
is assigned to the TCP base hdr size i.e. 40 but somewhere 32 is added to
40 in the lower layers and when the SYN packet shows up at the receiving
node! I also traced that the routing protocol DSR was adding 12 bytes of
header in my case, so that leaves the magical number 20 that is to be
accounted for. In your response on the ns users list, you had mentioned
something similar but it was not very specific. Can you please give me
some more details on where this magic number "20" is added so that I can
subtract it accordingly?

As a quick test I tried subtracting 32 in FullTcpAgent::recv() and the
initial ACK exchange was successful (!) but subsequent TcpApp data
transfers failed... that's how I figured that a uniform solution is needed
for this header size problem.

Any help will be greatly appreciated!

Thanks very much,
-- 
-Prithwish