home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 13,846 of 14,669   
   Rick Jones to Dara   
   Re: Packet loss?   
   03 May 12 01:15:13   
   
   180f7dbe   
   From: rick.jones2@hp.com   
      
   Dara  wrote:   
   > As an exercise I am trying to implement a very simple packet-loss   
   > measurement tool (copying the approach in Sting: a TCP-based Network   
   > Measurement Tool by Stefan Savage). I am sending a padded HTTP GET   
   > request as a sequence of TCP packets with 1 byte of payload to   
   > various web servers and watching the acks coming back. I pause for 1   
   > second between sending each TCP packet. I have two questions:   
      
   I'm not familiar with Sting, but why single-byte segments one second   
   apart?   
      
   > 1. I am not seeing any packet loss. Am I getting lucky or is the   
   > size of the packet (1 byte payload) somehow not big enough to   
   > encourage packet loss?   
      
   It depends.  Certainly with a single byte segment once a second, you   
   are very unlikely to trigger any congestion yourself.  While bit   
   errors can lead to dropped segments, 99 times out of 10 (very   
   scientific phrase...) a packet is dropped in response to congestion.   
      
   I seem to recall some assertions that the "last mile" (as in, to you)   
   is most frequently the point of congestion.  So, if you aren't going   
   to trigger any congestion in the last mile, the chances of seeing any   
   become that much more remote.   
      
   > 2. Some web servers are happy to wait for the entire padded HTTP GET   
   > request to arrive but others react after a fixed number of bytes   
   > have arrived (e.g. 30).  They send some data and close the   
   > connection. Is this web server behaviour configurable?   
      
   Perhaps it is actually a fixed length of time.  It sounds like a   
   defense against a denial of service whereby the client tries to keep   
   the connection open and so consuming some web server resources, for as   
   long as possible.  You can check bytes vs time by keeping the timing   
   the same, but including two, three, four bytes per segment.   
      
   rick jones   
   --   
   the road to hell is paved with business decisions...   
   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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca