Re: TCP question

From: Lloyd Wood ([email protected])
Date: Tue Aug 21 2001 - 16:39:23 EDT

  • Next message: Sergey Raber: "Re: TCP question"

    On Tue, 21 Aug 2001, Mark Allman wrote:

    > > If the Sender Maximum Segment Size (SMSS) is set to the same value
    > > as the Receiver Window (rwnd), will the window used by the sender
    > > - defined as min(rwnd,cwnd) - always remain at a constant value of
    > > rwnd?
    > >
    > > For example, if the sender receives a rwnd of 64K, can it set the
    > > MSS to 64K and keep its window wide open all the time - even if
    > > there is congestion?
    >
    > Clever. ;)
    >
    > I think you're correct since there is a lower bound on cwnd (i.e.,
    > it can never be less than 1 MSS).

    It strikes me that that might be a useful hack for the upper TCP in
    the hideous-go-through-firewalls hack that is TCP-in-TCP tunnelling.

    [ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

    grumbles about TCP congestion interaction and what happens if you
    don't block and drop on your streaming inputs - an infinite queue,
    in other words.]

    > But, I don't think this will actually work all that well -- and it
    > may be worse for the network than simply setting your TCP to never
    > adjust cwnd. The problem is that you are spitting out 64KB onto the
    > network at once. With a burst like that some packet is going to be
    > lost -- which means you'll end up retransmitting the TCP segment
    > again (in a 64KB burst). Packets from that segment will likely be
    > dropped, etc. So, you likely won't be getting much of anything
    > done.

    in the TCP-in-TCP case, you'd still want to tweak timeouts etc. (And
    obviously this isn't much use if your inner and outer TCPs aren't
    sitting on the same stack in the same box; it's only if they are that
    you start thinking of big mtus.)

    L.

    <[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



    This archive was generated by hypermail 2b29 : Tue Aug 21 2001 - 16:51:14 EDT