[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: postfix milter body chunk length
From:       Matthias Schneider <matthias.schneider () rmail ! de>
Date:       2019-08-20 12:22:19
Message-ID: 570c9904-34b8-1ae8-c1e0-9f26d3d638b4 () rmail ! de
[Download RAW message or body]

Am 20.08.19 um 13:09 schrieb Wietse Venema:
> Why does the kernel return this nonsensical mss value which is
> 1/3 of the MTU? 40kB of packet the framing overhead for loopback?


Good question, i have the same problem on different ubuntu machines, 
there is no tunneling or vpn, just plain network.
I also get TCP_MAXSEG 21845 on a newly launched VPS on a cloud provider 
(loopback mtu 65536).


net.ipv4.tcp_congestion_control = cubic

but i have tried "reno" too, no difference. I have no idea where the mtu 
/ 3 happens.



Thanks

Matthias Schneider



> Are you on PPPoE or some other tunnel? I would expect mss=1460
> for TCP/IP over ethernet.
> 
> > Since this is strange i prefer to switch to unixsocket.
> Don't bother fighting with a hostile network stack :-)
> 
> 	Wietse
> > I also researched where the delay happened in my milter: its while
> > waiting for the 64k packet
> > https://protection.retarus.com/v1?u=https%3A%2F%2Fgithub.com%2Fmschneider82%2Fmilt \
> > er%2Fblob%2Fb4a6d7c78ac39b8a1d71b53b74bc08d95652d310%2Fsession.go%23L101&c=3ii9Gwp&r=6kteDpYm1BWnNiGBD8pxt3&k=7s1&s=Qa2GzZMyAcLdZiwoBnfkEaAvdOpcAbRSJXPoLZJBjYB
> >  
> > 
> > Best regards
> > 
> > Matthias Schneider
> > 
> > 
> > 
> > Am 19.08.19 um 20:05 schrieb Wietse Venema:
> > > Matthias Schneider:
> > > > Hi Wietse,
> > > > 
> > > > 
> > > > > I suspect that the bottleneck is on the receiving side.
> > > > > 
> > > > > - Maybe the loopback stack does not like the 65535 block size. Try
> > > > > using an ethernet interface address instead.
> > > > I tried switching from interface lo to eno1 - same issue.
> > > What's the en01 MTU size? Postfix has code (in vstream_tweak.c
> > > which is called by the Milter client and other Postfix code) to
> > > automatically increase the VSTREAM buffer from 4096 to the maximal
> > > segment size, to avoid Nagle delays, though that would not help if
> > > the MTU is > 65535 (the Milter's 'packet' size).
> > > 
> > > I would therefore not expect Nagle delays on en01.
> > > 
> > > > I compared some tcpdumps with postfix as client and my milterclient
> > > > (which is fast) as client.
> > > > 
> > > > It seems that we run into nagle timeout (the ACK is always delayed).
> > > > Setting TCP_QUICKACK on my milter socket doesnt help, is there a way to
> > > > set TCP_NODELAY on the milter connection in postfix?
> > > You've got the source.
> > > 
> > > 	Wietse


[prev in list] [next in list] [prev in thread] [next in thread]