ddennerline
Active Member
I just took a look at clear-text outbound SMTP connection. It does take about 14 seconds to send email. Here’s what I can tell.
1) The outbound connection uses PAWS which is strange as inbound doesn’t use option. For such a short TCP connection, there’s no need to use PAWS. Even for an ElkRP cloud connection, the data volume would have to be substantial.
2) XEP sends two packets for every TCP data segment sent.
04:38:48.775991 example.net.41947 > somemailhost.org.ssmtp: Flags [.], ack 4651, win 8614, options [nop,nop,TS val 1139276190 ecr 1650367017], length 0
04:38:49.202067 IP example.net.41947 > somemailhost.org.ssmtp: Flags [P.], seq 709:746, ack 4651, win 8614, options [nop,nop,TS val 1139276610 ecr 1650367017], length 45
3) Elk sends tiny little segments – more than likely one line at a time. Each packet has about 250MS RTT.
4) Elk does not seem to get over the 8 packet TCP slow start transmit congestion window. It keeps waiting for an ACK for every packet.
I suspect that embedded TCP stack parameters where “optimized” without any real-world testing. Also, there’s no reason to have SACK without window scaling.
TLS with such small segments will make this situation a little more obvious because the cost per-segment will be higher.
1) The outbound connection uses PAWS which is strange as inbound doesn’t use option. For such a short TCP connection, there’s no need to use PAWS. Even for an ElkRP cloud connection, the data volume would have to be substantial.
2) XEP sends two packets for every TCP data segment sent.
04:38:48.775991 example.net.41947 > somemailhost.org.ssmtp: Flags [.], ack 4651, win 8614, options [nop,nop,TS val 1139276190 ecr 1650367017], length 0
04:38:49.202067 IP example.net.41947 > somemailhost.org.ssmtp: Flags [P.], seq 709:746, ack 4651, win 8614, options [nop,nop,TS val 1139276610 ecr 1650367017], length 45
3) Elk sends tiny little segments – more than likely one line at a time. Each packet has about 250MS RTT.
4) Elk does not seem to get over the 8 packet TCP slow start transmit congestion window. It keeps waiting for an ACK for every packet.
I suspect that embedded TCP stack parameters where “optimized” without any real-world testing. Also, there’s no reason to have SACK without window scaling.
TLS with such small segments will make this situation a little more obvious because the cost per-segment will be higher.
