Subject: Re: TCP send buffer free space
To: None <tech-net@netbsd.org>
From: Wolfgang Rupprecht <wolfgang+gnus20010710T134118@wsrcc.com>
List: tech-net
Date: 07/10/2001 13:54:20
jhawk@MIT.EDU (John Hawkinson) writes:
> |  /* set IP_TOS to request bulk-type packet queuing */
> |  tos = IPTOS_THROUGHPUT;
> |  if (setsockopt(fd, IPPROTO_IP, IP_TOS, (char *) &tos, sizeof(tos)) < 0)
> |  {
> |	  syslog(LOG_ERR, "setsockopt IPTOS_THROUGHPUT on fails: %m");
> |  }
> 
> Just how will this help? The master controller will still have to
> buffer the TCP packets until they all arrive in-order because they
> are part of one tcp connetion.
> 
> Changing the TOS in the middle of the TCP connection is not going to
> help you.
> 
> The constraint is that there is only one tcp connetion.

If you go up the thread you will see I advocated ignoring the single
socket constraint and simply doing the right engineering thing -
making one TCP socket for each of the two types of streams
(interactive and bulk-file "playback").

The single socket method, even with a kvm-groveler to snoop how much
of the TCP send window is used will simply transmit until some part of
the system has built up a backlog equal to the used part of the
window.

If the master-controller to ground link is the weakest link, that will
leave most of the outstanding packets sitting in its transmit queue.
So even thought there will now be room in netbsd's send queue for the
interactive packets, they will still have to wait behind the bulk
transfer packets already sitting on the master controller.

-wolfgang
-- 
       Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/