I was comparing some traces from SCP and SFTP when transferring the same
file 200MB file between the same host pairs. Even when I put SFTP in
batch mode I noticed that I saw 403208 bytes from the receiver in
comparison to 3368 bytes with SCP. I've attached the relevant output
from tcptrace below (the b->a column is the return side of the trace).
Mostly I'm just curious as to what is generating so much return traffic
for SFTP? Actually, now that I think about it, why almost an additional
9000 packets* for SFTP on the sending side as well?
Is it just some artifact of my network that I didn't pick up on or does
the sftp mechanism require this?
Thanks!
Chris Rapier
*I didn't disable TSO before taking these dumps so these pakets size
don't necessarily correspond to the actual MTU.
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004
155626 packets seen, 155626 TCP packets traced
elapsed wallclock time: 0:00:00.722889, 215283 pkts/sec analyzed
trace file elapsed time: 0:00:19.943138
TCP connection info:
1 TCP connection traced:
TCP connection 1:
host a: delta
host b: echo
complete conn: yes
first packet: Tue Apr 17 16:27:22.204583 2007
last packet: Tue Apr 17 16:27:42.147722 2007
elapsed time: 0:00:19.943138
total packets: 155626
filename: sftp2echo200mb.dump
a->b: b->a:
total packets: 74547 total packets:
81079
ack pkts sent: 74546 ack pkts sent:
81079
pure acks sent: 34 pure acks sent:
74806
sack pkts sent: 0 sack pkts sent:
0
dsack pkts sent: 0 dsack pkts sent:
0
max sack blks/ack: 0 max sack blks/ack:
0
unique bytes sent: 205796103 unique bytes sent:
403208
actual data pkts: 74511 actual data pkts:
6271
actual data bytes: 205848615 actual data bytes:
403208
rexmt data pkts: 22 rexmt data pkts:
0
rexmt data bytes: 52512 rexmt data bytes:
0
zwnd probe pkts: 0 zwnd probe pkts:
0
zwnd probe bytes: 0 zwnd probe bytes:
0
outoforder pkts: 0 outoforder pkts:
0
pushed data pkts: 18049 pushed data pkts:
6271
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent:
1/1
req 1323 ws/ts: Y/Y req 1323 ws/ts:
Y/Y
adv wind scale: 9 adv wind scale:
7
req sack: Y req sack:
Y
sacks sent: 0 sacks sent:
0
urgent data pkts: 0 pkts urgent data pkts: 0
===============================TCP connection 2:
host c: delta
host d: echo
complete conn: yes
first packet: Tue Apr 17 13:40:48.350911 2007
last packet: Tue Apr 17 13:40:55.841408 2007
elapsed time: 0:00:07.490497
total packets: 140843
filename: scp2echo200mb.dump
c->d: d->c:
total packets: 65970 total packets:
74873
ack pkts sent: 65969 ack pkts sent:
74873
pure acks sent: 20 pure acks sent:
74837
sack pkts sent: 0 sack pkts sent:
0
dsack pkts sent: 0 dsack pkts sent:
0
max sack blks/ack: 0 max sack blks/ack:
0
unique bytes sent: 205256455 unique bytes sent:
3368
actual data pkts: 65948 actual data pkts:
34
actual data bytes: 205364239 actual data bytes:
3368
rexmt data pkts: 37 rexmt data pkts:
0
rexmt data bytes: 107784 rexmt data bytes:
0
zwnd probe pkts: 0 zwnd probe pkts:
0
zwnd probe bytes: 0 zwnd probe bytes:
0
outoforder pkts: 0 outoforder pkts:
0
pushed data pkts: 10483 pushed data pkts:
34
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent:
1/1
req 1323 ws/ts: Y/Y req 1323 ws/ts:
Y/Y
adv wind scale: 9 adv wind scale:
7
req sack: Y req sack:
Y
sacks sent: 0 sacks sent:
0
Okay, so I believe I figured out why this is happening but I still have a couple of questions I'm hoping someone can answer. So I believe the extra data is from the SFTP messages requesting data (in chunk sizes determined by -B) and the subsequent acknowledgment of the write to the file system. So the larger you set -B (up to 256K) the fewer messages will be passed back and forth and so less extra data. From my tests it seems that this step is actually blocking so fewer messages not only decreases the total amount of data but it also keeps the link from sitting idle as often. If I am correct in this I was wondering why its set up this way? Is it to prevent writing to a full file system or some place where the user doesn't have appropriate permission? Thanks! Chris Rapier wrote:> I was comparing some traces from SCP and SFTP when transferring the same > file 200MB file between the same host pairs. Even when I put SFTP in > batch mode I noticed that I saw 403208 bytes from the receiver in > comparison to 3368 bytes with SCP. I've attached the relevant output > from tcptrace below (the b->a column is the return side of the trace). > Mostly I'm just curious as to what is generating so much return traffic > for SFTP? Actually, now that I think about it, why almost an additional > 9000 packets* for SFTP on the sending side as well? > > Is it just some artifact of my network that I didn't pick up on or does > the sftp mechanism require this? > > > Thanks! > Chris Rapier > > > > *I didn't disable TSO before taking these dumps so these pakets size > don't necessarily correspond to the actual MTU. > > Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 > > 155626 packets seen, 155626 TCP packets traced > elapsed wallclock time: 0:00:00.722889, 215283 pkts/sec analyzed > trace file elapsed time: 0:00:19.943138 > TCP connection info: > 1 TCP connection traced: > TCP connection 1: > host a: delta > host b: echo > complete conn: yes > first packet: Tue Apr 17 16:27:22.204583 2007 > last packet: Tue Apr 17 16:27:42.147722 2007 > elapsed time: 0:00:19.943138 > total packets: 155626 > filename: sftp2echo200mb.dump > a->b: b->a: > total packets: 74547 total packets: > 81079 > ack pkts sent: 74546 ack pkts sent: > 81079 > pure acks sent: 34 pure acks sent: > 74806 > sack pkts sent: 0 sack pkts sent: > 0 > dsack pkts sent: 0 dsack pkts sent: > 0 > max sack blks/ack: 0 max sack blks/ack: > 0 > unique bytes sent: 205796103 unique bytes sent: > 403208 > actual data pkts: 74511 actual data pkts: > 6271 > actual data bytes: 205848615 actual data bytes: > 403208 > rexmt data pkts: 22 rexmt data pkts: > 0 > rexmt data bytes: 52512 rexmt data bytes: > 0 > zwnd probe pkts: 0 zwnd probe pkts: > 0 > zwnd probe bytes: 0 zwnd probe bytes: > 0 > outoforder pkts: 0 outoforder pkts: > 0 > pushed data pkts: 18049 pushed data pkts: > 6271 > SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: > 1/1 > req 1323 ws/ts: Y/Y req 1323 ws/ts: > Y/Y > adv wind scale: 9 adv wind scale: > 7 > req sack: Y req sack: > Y > sacks sent: 0 sacks sent: > 0 > urgent data pkts: 0 pkts urgent data pkts: 0 > > > > ===============================> TCP connection 2: > host c: delta > host d: echo > complete conn: yes > first packet: Tue Apr 17 13:40:48.350911 2007 > last packet: Tue Apr 17 13:40:55.841408 2007 > elapsed time: 0:00:07.490497 > total packets: 140843 > filename: scp2echo200mb.dump > c->d: d->c: > total packets: 65970 total packets: > 74873 > ack pkts sent: 65969 ack pkts sent: > 74873 > pure acks sent: 20 pure acks sent: > 74837 > sack pkts sent: 0 sack pkts sent: > 0 > dsack pkts sent: 0 dsack pkts sent: > 0 > max sack blks/ack: 0 max sack blks/ack: > 0 > unique bytes sent: 205256455 unique bytes sent: > 3368 > actual data pkts: 65948 actual data pkts: > 34 > actual data bytes: 205364239 actual data bytes: > 3368 > rexmt data pkts: 37 rexmt data pkts: > 0 > rexmt data bytes: 107784 rexmt data bytes: > 0 > zwnd probe pkts: 0 zwnd probe pkts: > 0 > zwnd probe bytes: 0 zwnd probe bytes: > 0 > outoforder pkts: 0 outoforder pkts: > 0 > pushed data pkts: 10483 pushed data pkts: > 34 > SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: > 1/1 > req 1323 ws/ts: Y/Y req 1323 ws/ts: > Y/Y > adv wind scale: 9 adv wind scale: > 7 > req sack: Y req sack: > Y > sacks sent: 0 sacks sent: > 0 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev