Subject: Re: I-D ACTION:draft-ietf-pilc-asym-04.txt

From: Dr G Fairhurst <[email-masked]>
Date: Fri, 01 Jun 2001 18:03:16 +0100

Thanks for your comments, see in-line responses below...

[email-masked] 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

---

From: "Venkat Padmanabhan" <[email-masked]>
Date: Mon, 4 Jun 2001 17:04:09 -0700

> [email-masked] wrote:

...<snip>...
 
> > Section 5.8 Enhanced Backpressure

Just one other thing: I am not quire sure how the word 'Enhanced'
crept in between versions -03 and -04 of the I-D. It should simply
be 'Backpressure'.