--- I'm using 'ns1.3' simulator. --
>This is very IMPORTANT. You must use the "setsockopt" in the application
>for both the sender and the receiver. The sender's SNDBUF must equal the
>receiver's RCVBUF. When the connection is established, the lower of the
>two values is negotiated because the sender doesn't want to overflow the
>receiver. And the it does the receiver no good to advertise a larger
>RCVBUF than the sender can fill with his SNDBUF.
You know, for using larger than default (general 4096), we use 'SO_SNDBUF' and
'SO_RCVBUF' options. I think, they set before connection initiate using
'setsockopt'.
Assume, FTP server received 'connection request' from 'Client' with window
scale option.
Now, How about SOCKET on server?
Is it same scale factor to 'client' ? --> how?
If not, TCP throughput is limited by 'Sender Buffer size' (?)
>>OK, slow-start ramps up exponentially until reach to ssthresh.
>>Assume that ssthresh is equal to 'window size, (packet = 1000 bytes)
>> 300 packets -->
>> 600 packets --> <-- 300 acks (slow-start mode!!!)
>>
>>600 packets passing time and 300 packets passing time from application
>>to Socket buffer SAME. So, 300 packets are transmited and other
>>300 packets are still in Sender Buffer.
>>It cause Data packets to 'queue' or 'overflow' in Sender Buffer, i think.
>>Simulations ensure this phenomenon.
>Just to be sure that I understand what you are observing;
>Is the 'overflow' really occurring in the socket buffer space,
>or is it occuring at the network *interface*?
I'm not sure. Simulator has only one BUFFER concept on node, I think.
Anyway...
AS increas 'BUFFER' size on node, not occur 'Sender BUFFER overflow' during
slow-start.
......
OK, your comments very helpful and notify me some misunderstanding.
--------------------------------------
Yong-sin Kim. DCN-SSU-KOREA.
Lab:02-820-0823 Pager:015-101-3904
--------------------------------------
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:36 EST