On Jul 7, 4:20*pm, Sru...@gmail.com wrote:

> 1. We enable interactive data flow with setting PSH flag to 1.
>
> a) So if PSH = 1, does that mean that if app sends with a single
> write() 10 bytes of data to the TCP send buffer, then *these 10 bytes
> will be immediately send to other end each in its own segment ( thus
> 10 segments ), or does it mean that each write() from an application
> will be immediately send as single segment ( thus in our example a
> single segment will have 10 bytes of data )?

It means neither. TCP is a byte-stream protocol that does not preserve
application message boundaries.

> b) Can there be a situation, where two successive writes to TCP send
> buffer ( say first write() writes 2 and second write() writes 9
> bytes ) will be send in a single segment ( containing 11 bytes of
> data ) or does TCP somehow prevent this?

Absolutely that can happen.

> c) * * *How many packets can sender transmit before it has to stop and wait
> for an ACK ( assuming Nagle’s algorithm is disabled )? If just one,
> why?

It can send many, until the window is full. There is no specific
limit, as it will depend on how much data winds up in each packet.

> d) * * *Provided we have a fast connection between the two host, would
> interactive data transfer be faster or slower if TCP could transmit
> several packets before waiting for an acknowledgement?

It can, so this question doesn't make sense. Waiting for acks that
often would be a disaster if the ack dropped. You'd have to timeout
just to send more data.

> 2. Say we have a client application that can send text based commands
> via console windows to the server. For command to be sent, user must
> first type it into console windows and then press enter. Only then *is
> that command transmitted to TCP send buffer and then to the server.
>
> Now should we set the PSH flag on and thus enable interactive data
> flow or not? Is there a possibility that if PSH flag is not set to 1,
> that TCP send buffer won’t send that data immediately, but will
> instead wait for more data? I would assume that to be the case only if
> command is 1 or 2 bytes of length, but if it is 3 or more, then data
> will be send immediately?!

The PSH flag is a flag on the wire. It's not used to communicate
between an application and its local TCP implementation. So it cannot
affect when data is transmitted.

> 3. With bulk data enabled, I assume that if there are only few bytes
> in TCP send buffer, then TCP will wait for certain amount of time in
> case some more data will be available, so that more data could be send
> with a single segment? How long will it wait?

No, it won't. A bulk data sender will, presumably, transfer data in
bulk if possible. If it only sends a few bytes, that means it only has
a few bytes to send. (Why would it deliberately send 8 bytes if it had
450 to send?!) Why would the implementation assume the application is
broken?

DS

On Jul 10, 10:12 am, David Schwartz wrote:
> On Jul 7, 4:20 pm, Sru...@gmail.com wrote:
>
> > 1. We enable interactive data flow with setting PSH flag to 1.
>
> > a) So if PSH = 1, does that mean that if app sends with a single
> > write() 10 bytes of data to the TCP send buffer, then these 10 bytes
> > will be immediately send to other end each in its own segment ( thus
> > 10 segments ), or does it mean that each write() from an application
> > will be immediately send as single segment ( thus in our example a
> > single segment will have 10 bytes of data )?
>
> It means neither. TCP is a byte-stream protocol that does not preserve
> application message boundaries.
>
> > b) Can there be a situation, where two successive writes to TCP send
> > buffer ( say first write() writes 2 and second write() writes 9
> > bytes ) will be send in a single segment ( containing 11 bytes of
> > data ) or does TCP somehow prevent this?
>
> Absolutely that can happen.
>
> > c) How many packets can sender transmit before it has to stop and wait
> > for an ACK ( assuming Nagle’s algorithm is disabled )? If just one,
> > why?
>
> It can send many, until the window is full. There is no specific
> limit, as it will depend on how much data winds up in each packet.
>
> > d) Provided we have a fast connection between the two host, would
> > interactive data transfer be faster or slower if TCP could transmit
> > several packets before waiting for an acknowledgement?
>
> It can, so this question doesn't make sense. Waiting for acks that
> often would be a disaster if the ack dropped. You'd have to timeout
> just to send more data.
>
> > 2. Say we have a client application that can send text based commands
> > via console windows to the server. For command to be sent, user must
> > first type it into console windows and then press enter. Only then is
> > that command transmitted to TCP send buffer and then to the server.
>
> > Now should we set the PSH flag on and thus enable interactive data
> > flow or not? Is there a possibility that if PSH flag is not set to 1,
> > that TCP send buffer won’t send that data immediately, but will
> > instead wait for more data? I would assume that to be the case only if
> > command is 1 or 2 bytes of length, but if it is 3 or more, then data
> > will be send immediately?!
>
> The PSH flag is a flag on the wire. It's not used to communicate
> between an application and its local TCP implementation. So it cannot
> affect when data is transmitted.
>
> > 3. With bulk data enabled, I assume that if there are only few bytes
> > in TCP send buffer, then TCP will wait for certain amount of time in
> > case some more data will be available, so that more data could be send
> > with a single segment? How long will it wait?
>
> No, it won't. A bulk data sender will, presumably, transfer data in
> bulk if possible. If it only sends a few bytes, that means it only has
> a few bytes to send. (Why would it deliberately send 8 bytes if it had
> 450 to send?!) Why would the implementation assume the application is
> broken?
>
> DS

Now I'm confused. From your replies it seems that there is no
difference between
between interactive and bulk data flow ( thus it makes no difference
whether we set push flag on or not ). I must be missing something. So
what sets appart interactive and bulk data flows?

Srubys@gmail.com wrote:
> Now I'm confused. From your replies it seems that there is no
> difference between between interactive and bulk data flow ( thus it
> makes no difference whether we set push flag on or not ). I must be
> missing something. So what sets appart interactive and bulk data
> flows?

PSH is merely a "hint" that the receiving application should go ahead
and be notified of data arrival if it hasn't been already. As far as
how virtually all (?) TCP stacks today behave, PSH is (mostly) a noop.
Data arrives, app is notified, PSH or no PSH. (Modulo what
interaction, if any, there may be between PSH and an application
setting a watermark on the socket).

TCP setting PSH at the end of each "send" by the application is still
convenient to see in a packet trace - it gives the person reading the
trace _some_ idea of how the application was presenting data to TCP,
but one probably cannot _really_ count on that.

Go back to the days of "long ago and far away" there was at least one
TCP stack which abused the PSH bit as a message boundary - that was
the "NS Transport" of MPE/V and MPE/XL (and IX). However that was
contrary to the specs for TCP and was only exposed via the NetIPC
rather than BSC Sockets interface on those OSes.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
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...

hiya

It’s a bit confusing. In no way am I questioning your authority on the
subject, but after some googling I found TCP/IP guide ( online book )
that contradicts some of the stuff you say ( most likely I'm just
misinterpreting all of this )



1.
a)
> > 3. With bulk data enabled, I assume that if there are only few bytes
> > in TCP send buffer, then TCP will wait for certain amount of time in
> > case some more data will be available, so that more data could be send
> > with a single segment? How long will it wait?
>
> No, it won't.

Excerpt from TCP/IP guide:

"TCP includes a special “push” function to handle cases where data
given to TCP needs to be sent immediately. An application can send
data to its TCP software and indicate that it should be pushed. This
tells the sending TCP to immediately “push” all the data it has to the
recipient's TCP as soon as it is able to do so, without waiting for
more data.The segment will be sent right away rather than being
buffered. The pushed segment’s PSH control bit will be set to one to
tell the receiving TCP that it should immediately pass the data up to
the receiving application."

According to the above text when PSH is not set, TCP does buffer data
due to waiting on more data to arrive into TCP send buffer.



b)
> The destination device's TCP software, seeing this bit sent, will know that it
> should not just take the data in the segment it received and buffer it, but rather
> push it through directly to the application.
>
> PSH is merely a "hint" that the receiving application should go ahead
> and be notified of data arrival if it hasn't been already.

* What do we mean by the term notifying an app of received data? I
assume by that we mean immediately passing data to the app?

* If so, then only difference between PSH = 1 and PSH = 0 is/was that
when read() is issued by an app, data is read a bit more quickly if
PSH = 1, since it was already send to app from receiver buffer and
thus took less time to be read?



c)
> Data arrives, app is notified, PSH or no PSH.

So PSH was useful when lots of TCP stacks didn’t immediately notify
an app when new data arrived?
But the impression I got from the excerpts from TCP/IP guide is that
TCP stacks still behave that way even today, meaning if PSH = 0 they
will wait for more data before sending it




d)
> > c) How many packets can sender transmit before it has to stop and wait
> > for an ACK ( assuming Nagle’s algorithm is disabled )? If just one, why?
> It can send many, until the window is full. There is no specific limit, as it will
> depend on how much data winds up in each packet.

Assuming Nagle’s algorithm is disabled, then there is virtually no
difference between packets with PSH = 1 and packets with PSH = 0 when
it comes to the number of packets transmitted before waiting for an
ACK?


2. Is PSH of no use even when X Window System is used, where small
mouse movements need to be transmitted in “real time” in order to keep
the system responsive to the user?


3. Is Nagle’s algorithm enabled only when PSH=1?

Srubys@gmail.com wrote:
> According to the above text when PSH is not set, TCP does buffer data
> due to waiting on more data to arrive into TCP send buffer.

But it doesn't say that. It just says that TCP should PSH the data when
the PSH bit is set. It doesn't say that it shouldn't when it isn't. And
what you've been told here is that PSH is mostly a no-op. I've certainly
never seen an implementation where it isn't.

> Assuming Nagle’s algorithm is disabled, then there is virtually no
> difference between packets with PSH = 1 and packets with PSH = 0 when
> it comes to the number of packets transmitted before waiting for an
> ACK?

PSH has nothing to do with this.

> 3. Is Nagle’s algorithm enabled only when PSH=1?

The question doesn't make sense. Nagle's algorithm is enabled/disabled
on a per-socket basis. PSH is set on a per-send basis.

EJP wrote:
> > 3. Is Nagle's algorithm enabled only when PSH=1?

> The question doesn't make sense. Nagle's algorithm is
> enabled/disabled on a per-socket basis. PSH is set on a per-send
> basis.

Perhaps misreading the tea-leaves, but while I suppose it is
conceivable that PSH (is there actually a user-space option to set it
explicitly in (m)any stacks?) could override Nagle, it certainly
shouldn't override the congestion window, nor the classic TCP receive
window. So, an application would have to "deal" with it not "working"
in those cases which ends-up pretty much meaning an application has to
be able to work as if PSH never existed.

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 Jul 10, 5:31*pm, Sru...@gmail.com wrote:

> Excerpt from TCP/IP guide:

> "TCP includes a special “push” function to handle cases where data
> given to TCP needs to be sent immediately. An application can send
> data to its TCP software and indicate that it should be pushed.

This is confusing, because it's using the same word to mean two
different things. Yes, an application can indicate that the data
should be pushed, but not with the PSH flag. The PSH flag is a TCP
flag sent on the wire in a data packet. It can't be sent between an
application and its local TCP implementation.

> This
> tells the sending TCP to immediately “push” all the data it has to the
> recipient's TCP as soon as it is able to do so, without waiting for
> more data.

Right, so this is some communication between the application and its
local TCP stack.

> The segment will be sent right away rather than being
> buffered. The pushed segment’s PSH control bit will be set to one to
> tell the receiving TCP that it should immediately pass the data up to
> the receiving application."

Okay, so when the application does this, its local TCP stack tries to
send the data immediately. (Note that this is only one reason data
might be sent immediately and only one reason the PSH bit might be
set. In fact, it's one of the rarest reasons either of things could or
would happen.)

> According to the above text when PSH is not set, TCP does buffer data
> due to waiting on more data to arrive into TCP send buffer.

Again, you are confusing some 'push' option between an application and
its local TCP stack and the PSH flag on the wire between TCP stacks.
TCP may buffer data regardless of what the application says, and this
certainly has nothing to do with any PSH flags it may receive from the
other end.

> b)

> > The destination device's TCP software, seeing this bit sent, will know that it
> > should not just take the data in the segment it received and buffer it,but rather
> > push it through directly to the application.

> > PSH is merely a "hint" that the receiving application should go ahead
> > and be notified of data arrival if it hasn't been already.

> * What do we mean by the term notifying an app of received data? I
> assume *by that we mean immediately passing data to the app?

The stack can't immediately pass data to the app. If the application
doesn't call 'receive' there's nothing the stack can do. In practice,
it doesn't matter, receiving stacks *always* pass receiving data
immediately. They never wait for more data to accumulate in their
receive buffers.

> * If so, then only difference between PSH = 1 and PSH = 0 is/was that
> when read() is issued by an app, data is read a bit more quickly if
> PSH = 1, since it was already send to app from receiver buffer and
> thus took less time to be read?

Perhaps, though probably not. If the application is blocked in 'read',
a modern stack will unblock it the instant it can give it more than
zero bytes of data.

> c)
>
> > Data arrives, app is notified, PSH or no PSH.

Exactly.

> So PSH was useful *when lots of TCP stacks didn’t immediately notify
> an app when new data arrived?

Right.

> But *the impression I got from the excerpts from TCP/IP guide is that
> TCP stacks still behave that way even today, meaning if PSH = 0 they
> will wait for more data before sending it

Before *sending* it?! You are again confusing the PSH bit in a TCP
packet with some other communication mechanism between an application
and its local TCP stack.

> d)
>
> > > c) * * *How many packets can sender transmit before it has to stop and wait
> > > for an ACK ( assuming Nagle’s algorithm is disabled )? If just one,why?
> > It can send many, until the window is full. There is no specific limit,as it will
> > depend on how much data winds up in each packet.

> Assuming Nagle’s algorithm is disabled, then there is virtually no
> difference between packets with PSH = 1 and packets with PSH = 0 when
> it comes to the number of packets transmitted before waiting for an
> ACK?

> 2. Is PSH of no use even when X Window System is used, where small
> mouse movements need to be transmitted in “real time” in order to keep
> the system responsive to the user?
>
> 3. Is Nagle’s algorithm enabled *only when PSH=1?

Nagle's algorithm is always enabled unless an application chooses to
disable it. Responsiveness over low-latency links is fine with or
without Nagle, and Nagle doesn't significantly worsen latency for high-
latency links. (Assuming the applications are reasonably smart.)

DS

On Jul 10, 6:34*pm, Rick Jones wrote:

> Perhaps misreading the tea-leaves, but while I suppose it is
> conceivable that PSH (is there actually a user-space option to set it
> explicitly in (m)any stacks?) could override Nagle, it certainly
> shouldn't override the congestion window, nor the classic TCP receive
> window. *So, an application would have to "deal" with it not "working"
> in those cases which ends-up pretty much meaning an application has to
> be able to work as if PSH never existed.

Everybody who uses TCP *MUST* understand this: Fundamentally, TCP is a
byte-stream protocol that does not preserve message boundaries. Full
stop. All attempts to "teach" TCP to do different tricks fail.

DS

On Jul 10, 10:02*pm, David Schwartz wrote:
> On Jul 10, 6:34*pm, Rick Jones wrote:
>
> > Perhaps misreading the tea-leaves, but while I suppose it is
> > conceivable that PSH (is there actually a user-space option to set it
> > explicitly in (m)any stacks?) could override Nagle, it certainly
> > shouldn't override the congestion window, nor the classic TCP receive
> > window. *So, an application would have to "deal" with it not "working"
> > in those cases which ends-up pretty much meaning an application has to
> > be able to work as if PSH never existed.
>
> Everybody who uses TCP *MUST* understand this: Fundamentally, TCP is a
> byte-stream protocol that does not preserve message boundaries. Full
> stop. All attempts to "teach" TCP to do different tricks fail.
>
> DS

At the outset, TCP is probably a bad choice for a data flow that must
be "interactive" and "where small mouse movements need to be
transmitted in “real time” in order to keep the system responsive to
the user". TCP is a stream-based protocol, with a ton of built-in
latencies, such as sliding window, congestion, re-transmit back-off,
Nagle, delayed ACK, etc. With all these latencies, you might end up
regretting a choice to use TCP where you truly need and rely on
"interactive" and "real-time".

In article ,
Malachy Moses wrote:

>At the outset, TCP is probably a bad choice for a data flow that must
>be "interactive" and "where small mouse movements need to be
>transmitted in “real time” in order to keep the system responsive to
>the user". TCP is a stream-based protocol, with a ton of built-in
>latencies, such as sliding window, congestion, re-transmit back-off,
>Nagle, delayed ACK, etc. With all these latencies, you might end up
>regretting a choice to use TCP where you truly need and rely on
>"interactive" and "real-time".

Maybe so, but the fact that the only practical alternative in many
cases is UDP might be the reason why TCP is used for many interactive
applications including some where small mouse movements need to be
transmitted in "real time" including the X Windows.

Are there any common UNIX window systems that do not use TCP when
the I/O devices and the program are on different computers?

Note that talk about "sliding window, congestion, re-transmit back-off"
as intolerable "built-in latencies" is at best off the mark. No transport
protocol for non-trivial networks can do without equivalents of all of
those features. For example, an interactive application is unlikely
to be able to tolerate many lost mouse movements, which implies that
what ever network protocol used is likely to involve retransmissions.
No network protocol that involves retransmissions can do without
re-transmit back-offs and some form of congestion control and advoidance.


Vernon Schryver vjs@rhyolite.com

Malachy Moses writes:
> With all these latencies, you might end up
> regretting a choice to use TCP where you truly need and rely on
> "interactive" and "real-time".

"real-time" is correct: TCP *specifically* provides reliability at the
expense of timeliness. That's its point.

"interactive" I disagree with. Interactive *demands* reliability, and
TCP, at least as implemented in modern systems, provides ways to allow
an application supporting interactive exchanges to avoid the latencies
that TCP uses to be more efficient in bulk transfers. Well designed
applications can, in fact, use TCP take advantage of both ends of the
spectrum: being highly efficient whether there's a lot of data, and
still being reasonably timely when the data is coming in little
bursts.

-don

Hiya

Sorry for keep on dragging this topics


1.
> > So PSH was useful when lots of TCP stacks didn’t immediately notify
> > an app when new data arrived?
> Right.

I will ask this again just to be sure I haven’t misunderstood
anything:

So in the days of old TCP stacks ( when Stevens wrote his book ):

a) most TCP stacks didn’t immediately notify an app when new data
arrived?

b) when bulk data flow was enabled ( PSH = 0 ), TCP would buffer data
in hopes to receive more data, but now most TCP stacks immediately
send received data?

c) Due to reasons above PSH set to 1 really made a difference, but not
anymore?




2.
> TCP may buffer data regardless of what the application says, and this
> certainly has nothing to do with any PSH flags it may receive from the other
> end.

a) So in today’s TCP stacks TCP would buffer received data ( and thus
not immediately send it to the app ) only if app hasn’t issued a
read() statement yet?

b) In what circumstances TCP doesn’t try to send data immediately
( besides network problems or waiting for ACKs )?



3.
> > Excerpt from TCP/IP guide:
> > "TCP includes a special “push” function to handle cases where data given to
> > TCP needs to be sent immediately. An application can send data to its TCP
>> software and indicate that it should be pushed.
> This is confusing, because it's using the same word to mean two different
> things. Yes, an application can indicate that the data should be pushed, but
> not with the PSH flag. The PSH flag is a TCP flag sent on the wire in a data
> packet. It can't be sent between an application and its local TCP
> implementation.

a) How then does app tell TCP to push data?

b) However might app indicate to TCP that data should be pushed, TCP’s
reaction to this request is always to set PSH to 1 and then act
accordingly ( whatever "accordingly " may be in today’s stacks )?!








4.
> > According to the above text when PSH is not set, TCP does buffer data
> > due to waiting on more data to arrive into TCP send buffer.
> But it doesn't say that. It just says that TCP should PSH the data when
> the PSH bit is set. It doesn't say that it shouldn't when it isn't. And what you've
> been told here is that PSH is mostly a no-op. I've certainly never seen an
> implementation where it isn't.

It doesn’t say that explicitly, but if it says that due to PSH set to
1 TCP pushes data ( which reader interprets as that some action will
happen sooner ), then that would implicitly imply that PSH = 0 doesn’t
push data ( which reader would interpret as some action happening
slower than when pushed ). Else why didn’t he just say that setting
PSH to 1 has same effect as PSH = 0?



5.
> > d) Provided we have a fast connection between the two host, would
> > interactive data transfer be faster or slower if TCP could transmit
> > several packets before waiting for an acknowledgement?
> It can, so this question doesn't make sense. Waiting for acks that often would
> be a disaster if the ack dropped. You'd have to timeout just to send moredata.

If Nagle’s algorithm is enabled by default, then TCP stack waits for
ack after each packet sent, and only then sends another packet. So why
isn’t it disabled by default if it is such a performance killer?



6.
> > 3. Is Nagle’s algorithm enabled only when PSH=1?
> The question doesn't make sense. Nagle's algorithm is enabled/disabled
> on a per-socket basis. PSH is set on a per-send basis.

Stevens talks about Nagle’s algorithm only in the context of TCP
interactive data flow and since interactive flow is enabled only when
PSH=1, I assumed …



I really appreciate it

On Jul 11, 3:17*pm, Sru...@gmail.com wrote:

> If Nagle’s algorithm is enabled by default, then TCP stack waits for
> ack after each packet sent, and only then sends another packet. So why
> isn’t it disabled by default if it is such a performance killer?

Umm, no. You completely misunderstand Nagle's algorithm. First,
Nagle's algorithm only delays a packet if, and so long as, the stack
cannot send a full segment.

DS

On Jul 11, 5:17*pm, Sru...@gmail.com wrote:
> I will ask this again just to be sure I haven’t misunderstood
> anything:
>
> So in the days of old TCP stacks ( when Stevens wrote his book ):
>
> a) most TCP stacks *didn’t immediately notify an app when new data
> arrived?
>
> b) when bulk data flow was enabled ( PSH = 0 ), TCP would buffer data
> in hopes to receive more data, but now most TCP stacks immediately
> send received data?
>
> c) Due to reasons above PSH set to 1 really made a difference, but not
> anymore?


The issue is that the receiving TCP always buffers data up to some
locally determined limit. There is often some way of notifying the
application that data is available (beyond the typical recv and
select), but that's all. It's hard to see what an application would
really do with a knowing that there was data *and* a PSH available.
It's not like the application can wait to issue a recv until the PSH
arrives - it can't know how much buffer the TCP/IP stack has
available, and so cannot depend on there being enough room for the TCP
stack to receive and buffer the data before the PSH. So it's mostly
pointless at the receiving end.


> 2.
> a) So in today’s TCP stacks TCP would buffer received data ( and thus
> not immediately send it to the app ) only if app hasn’t issued a
> read() statement yet?


As above.


> b) In what circumstances TCP doesn’t try to send data immediately
> ( besides network problems or waiting for ACKs )?


TCP is (obviously) limited to sending no faster than the network can
support, so you can get substantial buffering there. And TCP cannot
send unless the other side has opened the window (by sending back a
non-zero window size), because the receiver has to be able to put the
data someplace once it arrives.


> 3.
> a) How then does app tell TCP to push data?


On most TCP/IP stacks, it can't. There’s just no exposed API for it.


> b) However might app indicate to TCP that data should be pushed, TCP’s
> reaction to this request is always to set PSH to 1 and then act
> accordingly ( whatever "accordingly " may be in today’s stacks )?!


Most stacks assume that the sender wants its data to get to the
receiver sooner rather than later, and so, unless there's a reason not
too (send window, network bandwidth, Nagle), it'll send. Note that
those reasons for not sending are very significant, and do lead to
significant combining of consecutive sends, especially in cases where
you're transmitting a lot of data quickly, or the link is slow or
busy. IOW, in most typical bulk flows, you *will* see the sending TCP
build full size segments simply because the sending application is
generating data faster than it can actually be sent.


> 4.
> It doesn’t say that explicitly, but if it says that due to PSH set to
> 1 TCP pushes data ( which reader interprets as that some action will
> happen sooner ), then that would implicitly imply that PSH = 0 doesn’t
> push data ( which reader would interpret as some action happening
> slower than when pushed *). Else why didn’t he just say that setting
> PSH to 1 has same effect as PSH = 0?


As I mentioned, PSH has little practical effect at the receiver. On
the sender, it might well be useful in the sense of increasing the
aggregation of consecutive sends. For example, the native APIs (APPC
and CPI-C) for LU6.2 provide for just that sort of thing (actually,
it's the other way around - the normal "send" only buffers, until you
explicitly "push" - or the stack needs to send because it's got a full
"segment").

But in a practical sense, if the network is *not* busy, it's not that
big a deal. If the network is busy, you'll get buffering and big
segments with aggregated data from multiple sends. And if the network
is not busy, why not use it to get the data to the other side a little
faster? There's really a fairly small range where explicitly
controlling buffering on a full duplex link (like TCP) will make much
practical difference. And in those cases the application can usually
help by doing only large sends (doing it's own buffering, if
necessary).

In article
<377bdc2f-53fb-44f0-bba3-4af33be8d1bb@25g2000hsx.googlegroups.com>,
David Schwartz wrote:

> On Jul 10, 5:31*pm, Sru...@gmail.com wrote:
>
> > Excerpt from TCP/IP guide:
>
> > "TCP includes a special ³push² function to handle cases where data
> > given to TCP needs to be sent immediately. An application can send
> > data to its TCP software and indicate that it should be pushed.
>
> This is confusing, because it's using the same word to mean two
> different things. Yes, an application can indicate that the data
> should be pushed, but not with the PSH flag. The PSH flag is a TCP
> flag sent on the wire in a data packet. It can't be sent between an
> application and its local TCP implementation.

Although if someone reads RFC 793 they could be excused for confusing
the API with the protocol. The sample API in the RFC makes the TCP
flags visible as parameters in the SEND() function. It describes a
TCP-specific API, rather than a more modern, general-purpose API.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 2008-07-10 16:24:06 -0400, Rick Jones said:

> TCP setting PSH at the end of each "send" by the application is still
> convenient to see in a packet trace - it gives the person reading the
> trace _some_ idea of how the application was presenting data to TCP,
> but one probably cannot _really_ count on that.


Rick, thanks for bringing this point up.

It's always been my understanding that the PSH bit is (*not*) a bit
that can be "set" by an application, it's an inference drawn up by the
TCP/IP stack when the application presumably has finished some kind of
"write()" to the socket - I'll stop here because I'm not really a
programmer, and stack implementations vary greatly, unfortunately. I
often go through traces looking for the PSH bit from the stack as an
indication of how the application is chunking or attempting to chunk
data. This has been very useful for me to figure out "application
stutter" - where the application is producing data to the network, but
some process behind the emitting application is latent in delivering
data and where the PSH bit is missing, the application hasn't finished
"talking", and you can inference problems from that. Not a 100%
troubleshooting diagnosis, and one that needs to be taken with a grain
of salt, but when you see things like:

- (customer data in packets)
- (long delay)
- (other data from a sql query)
- (rest of data from application)
- (packet with PSH bit set)

You can inference that the SQL query was latent behind the scenes.

/dmfh

--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx

Srubys@gmail.com wrote:
> So in the days of old TCP stacks ( when Stevens wrote his book ):
>
> a) most TCP stacks didn’t immediately notify an app when new data
> arrived?

They always did, at least within living memory, although maybe not when
the RFC was written, or maybe the RFC was written to allow that
behaviour and it was never implemented.

> b) when bulk data flow was enabled ( PSH = 0 ), TCP would buffer data
> in hopes to receive more data, but now most TCP stacks immediately
> send received data?

See above.

> c) Due to reasons above PSH set to 1 really made a difference, but not
> anymore?

Never, see above.

> a) So in today’s TCP stacks TCP would buffer received data ( and thus
> not immediately send it to the app ) only if app hasn’t issued a
> read() statement yet?

In the absence of a read that's all it can do, isn't it?

> b) In what circumstances TCP doesn’t try to send data immediately
> ( besides network problems or waiting for ACKs )?

When Nagle is on, which is the default, and the appropriate conditions
hold for it to take effect.

> a) How then does app tell TCP to push data?

It can't. See Stevens I #20.5.

> b) However might app indicate to TCP that data should be pushed, TCP’s
> reaction to this request is always to set PSH to 1 and then act
> accordingly ( whatever "accordingly " may be in today’s stacks )?!

See above. You've asked this question several times here. The answer
continues to be the same every time. The statement from the 'online TCP
Guide' you quoted: 'an application can send data to its TCP software and
indicate that it should be pushed' is incorrect. Don't rely on these
hobby sites: rely on Stevens. There's a lot of misinformation out there.
Whole websites full of it. I could point you at a few more ...

> Else why didn’t he just say that setting
> PSH to 1 has same effect as PSH = 0?

He does. See Stevens I #20.5.

> If Nagle’s algorithm is enabled by default, then TCP stack waits for
> ack after each packet sent, and only then sends another packet. So why
> isn’t it disabled by default if it is such a performance killer?

But it isn't a performance killer. It's a performance *improver*. You
haven't stated the conditions correctly here. See Stevens I #19.4.

> Stevens talks about Nagle’s algorithm only in the context of TCP
> interactive data flow and since interactive flow is enabled only when
> PSH=1, I assumed …

As a matter of fact, Stevens only talks about the PSH flag in the
context of TCP Bulk Data Flow! Your reasoning isn't very rigorous ...

hiya

>
> > If Nagle’s algorithm is enabled by default, then TCP stack waits for
> > ack after each packet sent, and only then sends another packet. So why
> > isn’t it disabled by default if it is such a performance killer?
>
> But it isn't a performance killer. It's a performance *improver*. You
> haven't stated the conditions correctly here. See Stevens I #19.4.
>


Aha, so Nagle’s algorithm only kicks in when packet to be send is very
small

thank you all

Srubys@gmail.com wrote:
> Aha, so Nagle?s algorithm only kicks in when packet to be send is very
> small

For some definition of very small, ususally < the TCP MSS (Maximum
Segment Size). In broad handwaving terms, Nagle (should) work like
this:

1) Is this send() by the user, plus any queued, untransmitted data, >=
MSS? If yes, then transmit the data now, modulo constraints like
congestion or receiver window. If no, go to question 2.

2) Is the connection otherwise "idle?" That is, is there no
transmitted but not yet ACKnowledged data outstanding on the
connection? If yes, transmit the data now, modulo constraints like
congestion or receiver window. If no, go to 3.

3) Queue the data until:
a) The application provides enough data to get >= the MSS
b) The remote ACK's the currently unACKed data
c) The retransmission timer for currently unACKed data (if any)
expires and there is room for (some of) the queued data in the
segment to be retransmitted.

rick jones
--
web2.0 n, the dot.com reunion tour...
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...