why the ip packet size is too small

I use IPAD to connect to the server and use tcpdump to log the tcp
packets on the server.
Here is the log.
Why the IP packet size is so small?
When the IP packet size is smaller than 1500, it is still splitted.
http://www.mediafire.com/?btn74fybod5zjpb
this is the log file.
Here are some of this log.
http://ffmpeg.pastebin.com/AVf8vDUE

Hello,

Thinking a écrit :
> I use IPAD to connect to the server and use tcpdump to log the tcp
> packets on the server.
> Here is the log.
> Why the IP packet size is so small?
> When the IP packet size is smaller than 1500, it is still splitted.
> http://www.mediafire.com/?btn74fybod5zjpb
> this is the log file.
> Here are some of this log.
> http://ffmpeg.pastebin.com/AVf8vDUE

Maybe because all the TCP data segments have the P (PUSH) flag set ?

On Mon, 2011-01-24, Thinking wrote:
> I use IPAD to connect to the server and use tcpdump to log the tcp
> packets on the server.
> Here is the log.
> Why the IP packet size is so small?
> When the IP packet size is smaller than 1500, it is still splitted.
> http://www.mediafire.com/?btn74fybod5zjpb
> this is the log file.
> Here are some of this log.
> http://ffmpeg.pastebin.com/AVf8vDUE

Which of the 11 IP packets at that URL is a fragment, according to you?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+(E-Mail Removed)> wrote:
> Which of the 11 IP packets at that URL is a fragment, according to you?

Keeping in mind that "fragment" has particular meaning in the context
of IP datragams - when IP is given a datagram that is larger than the
MTU of the link it will fragment it into two or more IP datargam
fragments, which are then reassembled by *IP* at the destination and
passed up the stack.

TCP, on the other hand, does segmentation of the data it is presented
with by the user and the remote TCP will reassemble those segmens into
the byte-stream that is presented to the user. TCP strives to pass to
IP, TCP segments that fit in the MTU.

However, TCP does not always give full sized segments to IP -
depending on the behaviour of the application, it may send a series of
much smaller TCP segments, which themselves become smaller-than-MTU IP
datagrams.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Jorgen Grahn <grahn+(E-Mail Removed)> wrote:
> And here's a briefer version of that stuff:

> .563525 IP client > server: Flags [S], seq 2200502233, win 65535, options [mss 1460 ...], length 0
> .563528 IP server > client: Flags [S.], seq 2421843058, ack 2200502234, win 5792, options [mss 1460 ...], length 0
> .567291 IP client > server: Flags [.], ack 1, win 32942, options [...], length 0

> .569943 IP client > server: Flags [P.], seq 1:408, ack 1, win 32942, options [...], length 407
> .569955 IP server > client: Flags [.], ack 408, win 54, options [...], length 0
> .570097 IP server > client: Flags [P.], seq 1:212, ack 408, win 54, options [...], length 211
> .570137 IP server > client: Flags [FP.], seq 212:635, ack 408, win 54, options [...], length 423

> .575873 IP client > server: Flags [.], ack 212, win 32889, options [...], length 0
> .576323 IP client > server: Flags [.], ack 636, win 32783, options [...], length 0

> .578935 IP client > server: Flags [F.], seq 408, ack 636, win 32942, options [...], length 0
> .578944 IP server > client: Flags [.], ack 409, win 54, options [...], length 0

> I don't understand it either. Specifically:
> - why does the server ack 408 only 0.1ms before starting to send data?
> I thought piggybacking would happen at those time scales.

If the server is coded to try to make sure that the sender's cwnd
opens quickly it may be coded to essentially do an immediate ACK of
the first data segment received.

> - Similarly, there are just 0.04ms between the server's 1:212 and 212:635.
> Why aren't they combined into a bigger segment?

setsockopt(TCP_NODELAY) by the application? To answer the question
requires either server application source code or a system call trace.

> - It takes a further 5.7ms before the client starts ACKing, and it
> seems to do so very slowly, and still not bothering to collapse the
> two ACKs into one.

Perhaps it has something to do with the client having a similar
"immediately ack the first segment" heuristic and second ACK covering
a FIN and so being triggered immediately.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Mon, 2011-01-24, Rick Jones wrote:
> Jorgen Grahn <grahn+(E-Mail Removed)> wrote:
>> Which of the 11 IP packets at that URL is a fragment, according to you?
>
> Keeping in mind that "fragment" has particular meaning in the context
> of IP datagrams [...]

Yes -- I should have said explicitly that I believed the original
poster was confused. He said

"When the IP packet size is smaller than 1500, it is still splitted."

(i.e. talking about IP fragmentation) when he probably meant

"When the TCP writer apparently had a piece of data less than 1460
octets ready, it was sent as two segments instead of just one."

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Mon, 2011-01-24, Thinking wrote:
> I use IPAD to connect to the server and use tcpdump to log the tcp
> packets on the server.
> Here is the log.
> Why the IP packet size is so small?
> When the IP packet size is smaller than 1500, it is still splitted.
> http://www.mediafire.com/?btn74fybod5zjpb
> this is the log file.
> Here are some of this log.
> http://ffmpeg.pastebin.com/AVf8vDUE

And here's a briefer version of that stuff:

..563525 IP client > server: Flags [S], seq 2200502233, win 65535, options [mss 1460 ...], length 0
..563528 IP server > client: Flags [S.], seq 2421843058, ack 2200502234, win 5792, options [mss 1460 ...], length 0
..567291 IP client > server: Flags [.], ack 1, win 32942, options [...], length 0

..569943 IP client > server: Flags [P.], seq 1:408, ack 1, win 32942, options [...], length 407
..569955 IP server > client: Flags [.], ack 408, win 54, options [...], length 0
..570097 IP server > client: Flags [P.], seq 1:212, ack 408, win 54, options [...], length 211
..570137 IP server > client: Flags [FP.], seq 212:635, ack 408, win 54, options [...], length 423

..575873 IP client > server: Flags [.], ack 212, win 32889, options [...], length 0
..576323 IP client > server: Flags [.], ack 636, win 32783, options [...], length 0

..578935 IP client > server: Flags [F.], seq 408, ack 636, win 32942, options [...], length 0
..578944 IP server > client: Flags [.], ack 409, win 54, options [...], length 0

I don't understand it either. Specifically:
- why does the server ack 408 only 0.1ms before starting to send data?
I thought piggybacking would happen at those time scales.
- Similarly, there are just 0.04ms between the server's 1:212 and 212:635.
Why aren't they combined into a bigger segment?
- It takes a further 5.7ms before the client starts ACKing, and it
seems to do so very slowly, and still not bothering to collapse the
two ACKs into one.

Does the IPAD use Ethernet, or what medium are they talking over?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Jan 23, 10:13*pm, Thinking <zhihang.w...@gmail.com> wrote:
> I use IPAD to connect to the server and use tcpdump to log the tcp
> packets on the server.
> Here is the log.
> Why the IP packet size is so small?

I appears each packet contains a full protocol message from the layer
above TCP (SSL?). So there's no way to send larger packets since the
other side must reply to the SSL negotiation and session setup
messages before any bulk application data can flow.

DS

The key problem is that in line 6 and line7 from the url
http://ffmpeg.pastebin.com/AVf8vDUE
#
10:18:05.570097 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [P.],
seq 1:212, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
151698887], length 211
#
10:18:05.570137 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [FP.],
seq 212:635, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
151698887], length 423

The server send 2 packets to the IPAD. Why does the server send TWO
packets to IPAD bug not ONE packet?

Thinking a écrit :
> The key problem is that in line 6 and line7 from the url
> http://ffmpeg.pastebin.com/AVf8vDUE
> #
> 10:18:05.570097 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [P.],
> seq 1:212, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
> 151698887], length 211
> #
> 10:18:05.570137 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [FP.],
> seq 212:635, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
> 151698887], length 423
>
> The server send 2 packets to the IPAD. Why does the server send TWO
> packets to IPAD bug not ONE packet?

<http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Forcing_data_deliver y>