Question on TCP segment sizes

[Paul Herman]

Hi -net,

While pondering sending large files across a jumbo frame network
using FreeBSD, I decided to first see how well the loopback
interface does.  Using ttcp on the same machine:

  ttcp -s -r 
  ttcp -s -t 127.0.0.1

I noticed that although the MSS is 16k, I don't ever see a full 16k
segment.  In fact, 16k packets in the form of one 2k packet and one
14k packet are sent, as the following tcpdump output shows:

.706018 127.0.0.1.1026  127.0.0.1.5001: S 3254883299:3254883299(0) win 57344 mss 
16344,nop,wscale 0,nop,nop,timestamp 112512 0 (DF)
.706108 127.0.0.1.5001  127.0.0.1.1026: S 2952251081:2952251081(0) ack 3254883300 win 
57344 mss 16344,nop,wscale 0,nop,nop,timestamp 112512 112512 (DF)
.706140 127.0.0.1.1026  127.0.0.1.5001: . ack 1 win 57344 nop,nop,timestamp 112512 
112512 (DF)
.707454 127.0.0.1.1026  127.0.0.1.5001: P 1:8193(8192) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708308 127.0.0.1.1026  127.0.0.1.5001: P 8193:22529(14336) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708346 127.0.0.1.5001  127.0.0.1.1026: . ack 22529 win 43008 nop,nop,timestamp 
112512 112512 (DF)
.708375 127.0.0.1.1026  127.0.0.1.5001: P 22529:24577(2048) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708508 127.0.0.1.1026  127.0.0.1.5001: P 24577:38913(14336) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708530 127.0.0.1.5001  127.0.0.1.1026: . ack 38913 win 43008 nop,nop,timestamp 
112512 112512 (DF)
.708549 127.0.0.1.1026  127.0.0.1.5001: P 38913:40961(2048) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708617 127.0.0.1.1026  127.0.0.1.5001: P 40961:55297(14336) ack 1 win 57344 
nop,nop,timestamp 112512 112512 (DF)
.708638 127.0.0.1.5001  127.0.0.1.1026: . ack 55297 win 43008 nop,nop,timestamp 
112512 112512 (DF)
[...repeats...]

The same happens phenomenon with FTP so I don't think there's any
voodoo going on with ttcp.  Interestingly enough, raising the MTU
on lo0 above 16k changes nothing.

Also, IPv6 (FTP) shows similar behavior:

.449842 ::1.1036  ::1.49153: P 92161:93185(1024) ack 1 win 57344 nop,nop,timestamp 
292774 292774
.449992 ::1.1036  ::1.49153: P 93185:107521(14336) ack 1 win 57344 nop,nop,timestamp 
292774 292774
.450018 ::1.49153  ::1.1036: . ack 107521 win 43008 nop,nop,timestamp 292774 292774 
[flowlabel 0x645a7]
.450099 ::1.1036  ::1.49153: P 107521:108545(1024) ack 1 win 57344 nop,nop,timestamp 
292774 292774
.450250 ::1.1036  ::1.49153: P 108545:122881(14336) ack 1 win 57344 
nop,nop,timestamp 292774 292774
.450275 ::1.49153  ::1.1036: . ack 122881 win 43008 nop,nop,timestamp 292774 292774 
[flowlabel 0x645a7]
.450354 ::1.1036  ::1.49153: P 122881:123905(1024) ack 1 win 57344 nop,nop,timestamp 
292774 292774
.450504 ::1.1036  ::1.49153: P 123905:138241(14336) ack 1 win 57344 
nop,nop,timestamp 292774 292774

So the question is, why don't we get two full sized 16344 (or at
least two 14336) sized segments?  It seems it would be more
efficient that way, no?

4.9-PRERELEASE from yesterday, all sysctls are system defaults...

-Paul.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Fwd: ipfw, pipes, queues, and IPv6

[Luigi Rizzo]

ipfw/ipfw2 will only see non-ipv4 packets at the layer2 level, i.e.
if you have net.link.ether.bridge.ipfw=1 or net.link.ether.ipfw=1

So you cannot do much classification except for the protocol type.

Re. ipv6 and pipes, i do not see any dummynet hooks in netinet6/
so almost surely it won't work.

The long term plan is to add ipv6-specific instructions to ipfw2
so you can replace ip6_fw with ipfw2, and then you only need
to add the post-ipfw processing from netinet/ip_{input,output}.c
in the corresponding netinet6/ files.

cheers
luigi


On Sun, Sep 21, 2003 at 08:10:29PM -0400, Michael W. Oliver wrote:
Content-Description: signed data
 [Folks, I posted this to ipfw@ last week, but had no takers over there.  
 Anyone here want to take a stab at it?  Thanks in advance!]
 
 I am looking for a little sanity check here.  I have a gif tunnel set up for 
 IPv6, and I am passing protocol 41 through the ipfw pipe/queue mechanism 
 to/from my tunnel provider (part of a grander pipe/queue scheme due to my 
 new Vonage service :).  A couple of questions:
 
 1) Am I correct in assuming that all IPv6 traffic that I am permitting via
 ip6fw is governed by the pipe/queue rules that I have configured for 
 protocol 41 in ipfw?
 
 2) If #1 is true, is there a way for me to use pipes/queues within ip6fw
 itself to discriminate by type of IPv6 traffic?
 
 Thanks for the info!
 
 -- 
 Mike
 perl -e 'print unpack(u,88V]N=%C=\!I;F9O(EN(AE861EG,*);'
 
 


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

SMC 2602W PCI Wireless

[Daniel Dias Goncalves]

The device SMC 2602W PCI works in the FreeBSD?

# uname -rs
FreeBSD 5.1-RELEASE
# pciconf -l -v
...

[EMAIL PROTECTED]:10:0:class=0x028000 card=0x260210b8 chip=0x82011317 rev=0x11 
hdr=0x00
vendor   = 'Admtek Inc'
class= network
...
#

kernel configuration:
device  cbb  # cardbus (yenta) bridge
device  pcic # ExCA ISA and PCI bridges 
device  pccard   # PC Card (16-bit) bus
device  cardbus  # CardBus (32-bit) bus   
device  wlan # 802.11 support
device  wi   # WaveLAN/Intersil/Symbol 802.11 wireless NICs.

wi* not work

Any idea ?

[]s Daniel Dias Gonçalves
[EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMC 2602W PCI Wireless

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Daniel Dias Goncalves [EMAIL PROTECTED] writes:
: The device SMC 2602W PCI works in the FreeBSD?
: vendor   = 'Admtek Inc'

unlikely.  The adm wireless driver is still being ported.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]