Thanks for your comments, see in-line responses below...
rragland@hns.com wrote:
>
> Hello Everyone,
>
> I would like to make the following comments on the IETF Internet Draft document
> entitled, "TCP Performance Implications of Network Asymmetry"
> (draft-ietf-pilc-asym-04.txt).
>
> Section 4.1 Bandwidth Asymmetry
>
> The second paragraph of the section provides some very useful calculations on
> when an upstream bottleneck becomes saturated before the downstream bottleneck
> does. Unfortunately, it makes an assumption that a client has the ability to
> occupy the full capacity of the downstream link, which may not be true in all
> cases.
Agreed, for a single session, because number of TCP bytes sent is not
sufficient
to open cwnd, or TCP window size is not big enough for the path delay
bandwidth product.
> For example, consider a T1 (1.544 Mbit/s) wireless link with an RTT of
> about 650 milliseconds. If the maximum TCP window is 65,535 bytes then the
> calculated throughput this client could achieve (over an individual connection)
> is limited to 806 Kbit/s, which is obviously less than the full capacity of the
> channel.
Agreed, or you could use TCP-LW window scaling.
But all this is only for one TCP flow, if we assume more than one TCP
flow, as
may be common with modern web browsers, etc. then window (and transfer size)
is not necessarily a constraint.
> Moreover, this would have a significant impact on the normalized
> bandwidth ratio, k. There should be some discussion of this situation in the
> section, since it would possibly lead to a very inaccurate result, if taken
> literally.
>
> Section 5.8 Enhanced Backpressure
>
> To reiterate Lloyd Wood's comment, a clear definition of the term 'backpressure"
> would be useful and would make the section easier to understand. Moreover, it
> would also be useful if the authors could offer some ideas on how backpressure
> could be implemented to avoid uplink congestion.
>
This is a TCP-STACK implementation decision. Backpressure relates to the
way TCP/IP
processes packets queued for transmission (there's more details in the reference).
Perhaps Hari or Venkat would like to elaborate?
> Rod Ragland
> Hughes Network Systems
-- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:26 EST