3b3fca2d   
   From: rick.jones2@hp.com   
      
   newbie123  wrote:   
   > thx for helping. why does it say 65535 in the window field in a   
   > sniffer trace?   
      
   Does your sniffer trace also include the SYNchronize segments? Some   
   TCP stacks may follow a simple (perhaps simplistic) heuristic of "when   
   the window size is configured for > 65535 set the window field to   
   65535 and pick the "closest" window scaling value to include the   
   actual window size.   
      
   This is why interpreting the TCP window field is, well, difficult,   
   when one has not also captured the connection establishment...   
      
   > many documents say that the congestion window will   
   > atmost be 2 or 3 mss which is what is the maximum that can be sent.   
      
   There are really several "windows" in play in TCP these days, that is   
   what I was trying to convey before.  There is the "classic" TCP   
   receive window, which is what you see in the packet traces.  Since ca   
   1988 there is also a "congestion" window, which is purely an artifact   
   of the sending TCP and does not appear in the header.  That is the   
   sending TCP's idea of how much data it can send at one time without   
   overwhelming the network between him and the receiver.   
      
   So, in the context of those two, a sending TCP will send no more than   
   his computed congestion window, *or* the receivers advertised window,   
   whicever is _less_   
      
   Now, the bits you see about 2 or 3 MSS are likely referring to the   
   *initial* congestion window.  A sending TCP "learns" how much it can   
   send by, well, "feeling its way" by sending some number of segments,   
   then as ACKs come back (indicating those segments have left the   
   network - if they have been ACKed, it means the receiver has received   
   them which means they are no longer out on the network...) it   
   increases its idea of how much it can send without triggering   
   congestion (aka packet loss somewhere between the sender and the   
   receiver).   
      
   At the beginning of the connection, TCP typically has no "history" of   
   what it has successfully sent to the destination without causing   
   packet losses.  So, TCP has to have an initial congestion window.  It   
   *could* be like Farragut at Mobile Bay and say "Damn the congestion,   
   full send ahead!" :) and send a full receiver's window's worth of data   
   at the start of the connection.  However, the folks who design the   
   protocols and heuristics have decided it is better to start with   
   something less, hence the 2 or 3 MSS initial congestion window.   
      
   > so essentially when its configured in the registry that the window   
   > size is 65535 or more it doesn't matter on the initial startup of   
   > the tcp connection. is that correct?   
      
   Yes.   
      
   rick jones   
   --   
   The computing industry isn't as much a game of "Follow The Leader" as   
   it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."   
                                                       - Rick Jones   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)