Mayur wrote: > Mats Folke wrote: >> Hi! >> >> It is a fundamental property of TCP to set the packet (segment) size >> of its own. This is set with respect to path MTU, and various >> buffers. Thus, the size of the incoming FTP packets will not impact >> the outgoing segment size, since TCP is a byte-oriented protocol. >> >> However, ns-2 is not a perfect realization of the real world. There >> is a parameter >> Agent/TCP set packetSize_ 1000 # packet size used by sender >> (bytes); >> at http://www.isi.edu/nsnam/ns/doc/node396.html. Perhaps that may >> help you? >> >> Many wishes, >> Mats Folke >> >> >> Mayur wrote: >> >>> Tatiana Polishchuk wrote: >>> >>>> Did you try to change the header size? Pls refer to the chapter >>>> 12.1.2 of the ns2 tutorial. >>>> Tatiana >>>> >>>> On Thu, Sep 25, 2008 at 9:03 AM, Mayur <[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]>> wrote: >>>> >>>> >>>> Dear all, >>>> >>>> I am using simple FTP over TCP. In ns, from the application >>>> layer (ftp) Though I send small packets, (eg. 100 bytes >>>> using '$ftp_($i) send 100' ), TCP's packet size remains fixed >>>> equal to 1000. What is the reason? How to change it. >>>> I tried to study the tcp.cc's send and sendmsg() function, but >>>> could not understand it well. >>>> >>>> Your cooperation is appreciated. >>>> >>>> regards, >>>> Mayur >>>> >>>> >>>> >>> Thank you Tatiana, for your quick response! >>> >>> I went through 12.1.2 of the ns Manual as you suggested. >>> >>> I know that each layer will add a header to the SDU (Service Data >>> Unit) received from its upper layer. And so, there is no point in >>> reducing the header size. My point is different. Consider following >>> explanation. >>> at Application layer the data from FTP is >>> ------------------------------- >>> | FTP data | >>> ------------------------------- >>> Now when this is handed over to the TCP layer, it will add its header >>> to it. And it will become following to be handed over to IP layer and >>> so on... >>> ---------------------------------------------------------- | >>> TCP Header | FTP Data | >>> ---------------------------------------------------------- That's >>> fine. So, the total size, at the TCP layer should be = >>> FTPDataSize + TCPHeaderSize. >>> >>> *Now, the problem I face is: *The TCP packet size is always remaining >>> same (1040 bytes), irrespective of the FTPDataSize, which I expect to >>> vary with it. eg. for FTPData of 200 bytes it should become >>> (200+TCPHeaderSize) bytes. I think theoretically I am correct, and >>> something I miss to set in the ns2. The expert users' suggestions are >>> awaited. >>> >>> I hope my question is now clear.... >>> >>> >>> regards, >>> Mayur >>> >> >> >> >> > Dear Mats, > > I understood that TCP is a byte-oriented protocol. So, theoretically a > TCP will set the segment size of its own depending upon many factors > as path MTU, etc. > But consider /only one application layer small 'packet'* */being > sent, say of size 200 bytes. (Let's consider this to be small enough > to be accomodated within a single TCP segment.) > Q.>*Now in such a case what will happen in theory?* I know the > answer for 'What will happen in ns2 simulation?". It is as follows: In > ns2, I observed that for this single packet too, TCP sends a single > packet of size 1040 bytes (Rock-Solid-Fixed!!, by the default setting > 'Agent/TCP packetSize_ 1000' as you rightly told). > I studied as you asked by changing 'Agent/TCP set pacektSize_ > <someOtherSize>'. It works, but it will work *on per flow basis,* > while I need it to work on "/*per packet (segment) basis*/". In short > I want to simulate /*more realistic scenario* in which the > segmentSize_ varies (may be, following some random distribution) > continuously. / > > * Is it possible in current ns2?* *If not*, (as it is not a perfect > realization of the real network), *what is the way out?* > > Regards, > Mayur > Dear all,
Sorry to all for the trivial query! It was my silly misunderstanding.... I have understood it now. A big message (>1000) from application layer is split by TCP layer into segments of 1000 each, while keeping the minimum segment size to be 1000 (fixed). Thanks to all for their considerations.... Mayur
