Re: clarification : Re: "renice" netowork usage.

Re: clarification : Re: "renice" netowork usage.

[Andi Kleen]

Jan Vicherek <honza@ied.com> writes:
> 
>    My understanding of TCP tells me that "if the line conditions are
> poor", the server adjusts the TCP window size to something smaller. Now
> how the heck would the server knows what kind of line conditions are
> ahead?! It doesn't. So how can it adjust the window side then ? By
> guessing the line conditions from number and latency of ACKs.

Read up on http://ftp.ee.lbl.gov/floyd/cbq.html, and maybe
http://ftp.ee.lbl.gov/floyd/ecn.html too. Linux implements the first 
already, but there is no documentation (yet) and the code is still
rather experimential and rough. Note that the best way to implement
that is not on the end host, but rather on the router before the
bottleneck link. 

If you want a basic explanation of the current TCP congestion
avoidance algorithms read RFC 2001. The current algorithm penalizes 
slow streams over fast streams a bit though.


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

clarification : Re: "renice" netowork usage.

[Jan Vicherek]

On Sat, 9 May 1998, Marc Lehmann wrote:

> 
> You can do this already in 2.1 kernels (TOS), per port. But note that _both_
> sides need to do this, otherwise it would almost have nil effect.

    Suppose the remote side is an HTTP server. The local (linux) side has
the HTTP client. The server doesn't have a clue as to what bandwidth is
available. So when the initial request for, say, a 200MB file is received,
it sends out about 10 (I guess) packets of data. That makes the TCP window
to be 10.

   As of now, the client responds with ACKs as soon as the data come
through the 33.6 pipe. Thus the server figures out that because it has got
the ACKs, it can now send more data. So it fills the pipe with 10 more
packets.

   My understanding of TCP tells me that "if the line conditions are
poor", the server adjusts the TCP window size to something smaller. Now
how the heck would the server knows what kind of line conditions are
ahead?! It doesn't. So how can it adjust the window side then ? By
guessing the line conditions from number and latency of ACKs.

   To regurgitate, WE CAN simulate low-bandwidth link by controlling the
number and latency of ACKs (and maybe even sequence). And this way we
trick the server and so control the flow out of the server.

   Are there any flaws in the above ?

   Please note that this must be implemented in the kernel, since TCP
clients don't currently have a way to control number and latency of ACK
packets to the data that it receives.
   This thread is about implementing such control into kernel.

     Thank you,

          Jan Vicherek

 -- Gospel of Jesus is the saving power of God for all who believe --
Jan Vicherek ## To some, nothing is impossible. ##  www.ied.com/~honza
    >>>    Free Software Union President  ...  www.fslu.org    <<<
Interactive Electronic Design Inc.    -#-    PGP: finger honza@ied.com



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu