There is really no precise definition of a PEP (i.e. I think there is a
lot of grey area at the edges). In my opinion, you can consider it a PEP (if
you want) if:
o Its function is not required for traffic to flow, i.e. traffic still
flows even without the box in place (albeit with "less performance");
o The defined purpose of its function is to enhance some aspect of
performance in some way (as opposed to such enhancement occuring more as a
side benefit of its defined purpose).
I think a shaper matches the first point. I can see arguments either way
on the second point...
John
Michele Milani wrote:
>
> > -----Original Message-----
> > From: John Border [mailto:border@hns.com]
> > Sent: luned́ 26 novembre 2001 18:44
> > To: Michele Milani
> > Cc: 'pilc@grc.nasa.gov'
> > Subject: Re: "rwnd control" as a PEP mechanism
> >
> >
> >
> > Could you elaborate in three or four sentences what you
> > mean by "rwnd
> > control"?
>
> Sure, I'm sorry, I'm so involved in this matter that it appears me natural
> to speak about "rwnd control" without clarifying what i mean.
>
> Our study aims to understand how some equipments sold as "shapers" work.
> Packeteer and Allot are the top players in this market. Packeteer declares
> to use an algorithm that changes the value of the receiver advertised window
> (rwnd) field in ACK packets.
>
> Do you think that a shaper can be a kind of PEP? I think so, but maybe I'm
> wrong.
>
> > It looks to me like the post you reference is talking
> > about a change to
> > the TCP sender and not a PEP.
>
> No, shapers are "inside" the network and the sender and the receiver go on
> TCPing without knowing about shapers.
>
> > In any case, RFC 3135 is a "survey" document and, as
> > such, is not intended
> > to capture every single possible "PEP" idea. It is just
> > trying to get across
> > the concepts of the kinds of things that are done by a PEP
> > (and the reasons
> > why they are used and the consequences of using them)...
>
> I understand that and my post was only curious. My intention was not to
> criticize RFC 3135, only to know if, according to you, the modification of
> the value of the receiver advertised window (rwnd) field in ACK packets can
> be an alternative PEP mechanism.
>
> Gorry, I reply to you through the ML as I think all the ML can be
> interested.
>
> > -----Original Message-----
> > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> > Sent: luned́ 26 novembre 2001 18:33
> > To: Michele Milani
> > Subject: Re: "rwnd control" as a PEP mechanism
> >
> >
> > Not entirely sure what you mean, so I thought I would check
> > before I answered.
> >
> > By "rwnd", I presume you mean the receiver advertised window.
>
> You're right.
>
> > If so, do you suggest increasing this to a value larger than
> > the receiver
> > first advertised,
>
> No: in this way I'll lose flow control mechanism and packets will fill
> buffers.
>
> > or reducing to throttle the speed of communication?
>
> Yes: I can implement some QoS with different classes of TCP streams that
> traverse the same link or I can optimize rwnd value to get better overall
> performance.
>
> What do you think about that? Does it make sense?
>
> Cheers,
> Michele
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST