1d00c920   
   From: gah@ugcs.caltech.edu   
      
   David Schwartz  wrote:   
   > On Dec 12, 5:09?am, karthikbalaguru    
      
   >> Also, why is the multiplication factor static ?   
      
   > Whatever you choose, once you've made a choice, that   
   > choice doesn't change.   
      
   >> I think, it should be dependent on various   
   >> other factors. Like, for example,   
   >> I think, it can be initially multiplied by 1.5 and   
   >> if it fails during that time, then the original can be multiplied   
   >> by 2, and if it fails during that time also, then the original   
   >> can be multiplied by 2.5 . Some other factors(if possible)   
   >> can be taken into consideration before deciding on this   
   >> and making the selection dynamic. Any thoughts ?   
      
   > Then someone will say "Why does it go 1.5, then 2, then 2.5 all the   
   > time? Why isn't it dynamic -- deciding what to change to based on   
   > other factors?".   
      
   For ethernet, where it is done in hardware, 2 is easy.  When ethernet   
   was new, hardware had to be simple.  If you want to see that   
   exponential isn't the only way, find references to BLAM related   
   to ethernet.  I think for ethernet going to 2 first is likely   
   the best choice, what comes after that probably doesn't matter much.   
      
   In the ethernet case, if two stations collide, they choose one   
   of two values for the retransmit.  If they choose the same they   
   will again collide.  It should be simple math to find the best   
   value for two stations to minimize the average time until they are   
   successful in transmitting.   While it has to work for larger values,   
   the most important is the two station case.   
      
   > Whatever you do, once you've chosen an algorithm, that algorithm is   
   > static.   
      
   > Multiplying by a constant factor is as dynamic as any other choice, as   
   > the result of the multiplication will changes based on conditions.   
      
   Well, for ethernet the conditions are the load on the net.  At low   
   load, it is unlikely that more than two will be transmitting at once.   
   AS the load increases, the average number increases, and the timing   
   has to adjust for that increase.  I am not so sure it is the same   
   for TCP.  It might be that they just borrowed from ethernet.   
      
   -- glen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)