XPost: comp.os.linux.networking   
   From: grahn+nntp@snipabacken.se   
      
   ["Followup-To:" header set to comp.protocols.tcp-ip. You should have   
   mentioned that you started crossposting.]   
      
   On Sat, 2011-05-21, Mark Hobley wrote:   
   > On Sat, 21 May 2011 14:58:32 +0000, Mark Hobley wrote:   
   ...   
   >> 03:40:48.745614 IP venus.markhobley.yi.org.52196 >   
   >> news.eternal-september.org.nntp: Flags [S], seq 185692436, win 14600,   
   >> options [mss 1460,sackOK,TS val 47088682 ecr 0,nop,wscale 5], length 0   
   >   
   > The value of win 14600 here is presumably the number of bytes of data that   
   > venus is prepared to receive in a single instance. Is that right? Presumably   
   > that is just data, and excludes headers. Is that right? It is bigger than   
   > any datagram that my ISP can carry. Does it have any effect on datagram   
   > sizes?   
      
   No.   
      
   ...   
   > 03:43:04.320740 IP venus.markhobley.yi.org.52201 >   
   >> news.eternal-september.org.nntp: Flags [S], seq 2304145392, win 14600,   
   >> options [mss 1460,sackOK,TS val 47122576 ecr 0,nop,wscale 5], length 0   
   >   
   > A big window again. Hey look at the mss value! That looks big to me.   
   > My ISP cannot carry a datagram above 1412 bytes.   
      
   1460 looks perfectly normal to me; it's the mss for a normal Ethernet.   
   n.e-s.o cannot know that your ISP is weird.  As far as I can tell   
   you're not using Path MTU discovery, so you're relying on the routers   
   on the way handling IP fragmentation correctly. Which they must.   
      
   Perhaps you should have captured ICMP messages too, in case there are   
   any which are relevant.   
      
   ...   
      
   I've looked some at your tcpdump.  It's a bit confusing because it   
   contains multiple sessions -- n.e-s.org times out and forces your   
   client to reconnect a few times.   
      
   Anyway, I don't see anything really strange, apart from the fact that   
   large segments from you (at least 1368 and upwards) don't get through.   
   You send a bunch of them and resend them, but the server never ACKs   
   any of them.  For example in this part (abbreviated for clarity):   
      
   1:55.072935 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368   
   1:55.072986 IP C > S: Flags [P.], seq 1434:2113, ack 324, win 457, length 679   
   1:55.073028 IP C > S: Flags [.], seq 2113:3481, ack 324, win 457, length 1368   
   1:55.073074 IP C > S: Flags [.], seq 3481:4849, ack 324, win 457, length 1368   
   1:55.242762 IP S > C: Flags [.], ack 66, win 46, length 0   
   1:56.524109 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368   
   1:59.424110 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368   
   2:05.232112 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368   
   2:16.832117 IP C > S: Flags [.], seq 66:1434, ack 324, win 457, length 1368   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)