TCP interactive data flow - TCP-IP

This is a discussion on TCP interactive data flow - TCP-IP ; Hiya I’m new at TCP/IP. Anyway, quite a few things about TCP interactive data flow confuse me. 1. We enable interactive data flow with setting PSH flag to 1. a) So if PSH = 1, does that mean that if ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 43

Thread: TCP interactive data flow

  1. TCP interactive data flow

    Hiya

    I’m new at TCP/IP. Anyway, quite a few things about TCP interactive
    data flow confuse me.



    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 )?




    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?



    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?



    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?




    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?!




    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?



    cheers

  2. Re: TCP interactive data flow

    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

  3. Re: TCP interactive data flow

    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?

  4. Re: TCP interactive data flow

    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...

  5. Re: TCP interactive data flow

    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?

  6. Re: TCP interactive data flow

    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.

  7. Re: TCP interactive data flow

    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...

  8. Re: TCP interactive data flow

    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

  9. Re: TCP interactive data flow

    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

  10. Re: TCP interactive data flow

    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".

  11. Re: TCP interactive data flow

    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

  12. Re: TCP interactive data flow

    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

  13. Re: TCP interactive data flow

    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

  14. Re: TCP interactive data flow

    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

  15. Re: TCP interactive data flow

    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).

  16. Re: TCP interactive data flow

    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 ***

  17. Re: TCP interactive data flow

    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


  18. Re: TCP interactive data flow

    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 ...

  19. Re: TCP interactive data flow

    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



  20. Re: TCP interactive data flow

    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...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast