> -----Original Message-----
> From: Dr G Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: Friday, June 01, 2001 10:03 AM
> To: rragland@hns.com; pilc@grc.nasa.gov
> Subject: Re: I-D ACTION:draft-ietf-pilc-asym-04.txt
>
>
> Thanks for your comments, see in-line responses below...
>
> rragland@hns.com wrote:
...<snip>...
> > 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?
>
As noted in the I-D, the notion of 'backpressure' was suggested in
[KVR98]
in the context of bidirectional transfers. Here is a pointer to the
paper:
ftp://ftp.cse.ucsc.edu/pub/hsnlab/Sigmetrics98.ps.gz
The idea is essentially that outlined in Section 5.8 of the I-D.
A limit is set on how many data packets of upstream transfers can
be enqueued at the upstream bottleneck link. In other words, the
bottleneck link queue exerts 'backpressure' on the TCP (sender) layer.
(The host where backpressure is implemented is assumed to be connected
to be directly connected to the upstream bottleneck link.) Backpressure
ensures that ACKs of downstream connections do not get starved at the
upstream bottleneck, thereby improving performance of the downstream
connections.
-Venkat
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:27 EST