Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters




Yes I'm well aware of the paper. However, with due respect to Van, since his
argument was just a one sentence long without any mathematical analysis or
simulation study, I did not put much bearing on it. Moreover, its not a
complete paper yet.

Pls read this old mesg by the co-inventor of RED, Sally Floyd. I think she
explains it in a more "understandable" and intuitive manner.

http://www-nrg.ee.lbl.gov/floyd/REDaveraging.txt

I presume typical bottleneck is the link (whose resource is measured in
bytes/sec) and typically packets are stored as a linked list of fixed sized
buffers and thus memory resource is measured in terms of buffers. Now if the
control memory which stores the linked list of buffers (packet accounting)
is the bottleneck, then of course, packet resources rather than byte
resources will get exhausted first - in which case pkt accounting is
preferable.

Krishna

-----Original Message-----
From: Sanjay Agrawal [mailto:sanjay@xxxxxxxxxxxx]
Sent: Friday, June 29, 2001 6:46 PM
To: 'Krishna Pattabhiraman'; 'Adisak Mekkittikul'; Reflector RPRWG
Subject: RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters


Please read the Latest RED paper from Van Jcobson (inventor of TCP and RED).
In this paper he argues that bytes and packet sizes don't make a significant
difference.
http://www.gt-er.cg.org.br/sgt-qos/documentos/red_light.pdf 

-Sanjay
-----Original Message-----
From: Krishna Pattabhiraman [mailto:Krishna@xxxxxxxxxxxxxxx]
Sent: Friday, June 29, 2001 3:37 PM
To: 'Adisak Mekkittikul'; Reflector RPRWG
Subject: RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters



If RED decisions and also the buffer accounting are based on packet counts
instead of byte count, its well known to cause unfairness.

Even if you do byte accounting, the traditional RED has been shown (via
simulations) to have bias against flows with large packets. Check out the
innumerable RED-based papers in the last 2-4 infocom an sigcomm confs -
you'll see tons of simulation studies.

I agree with Jie & Adisak that using averages or fixed pdfs in simulations
is not a good idea. Its better to use actual packet traces from networks
(check out CAIDA/NS websites etc).

Krishna

-----Original Message-----
From: Adisak Mekkittikul [mailto:adisak@xxxxxxxxxxxxxx]
Sent: Friday, June 29, 2001 6:17 PM
To: Reflector RPRWG
Subject: RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters





I agree with Jie. In the past we have observed that packet size can affect
how TCP flows 
ramp up. For the same RTT, BW and TCP setting, a TCP flow with smaller size
packet might
rampup faster probably because more ACKs being received. Has anyone come
across any study 
on the effect of packet size on fairness on RED, etc? It would be nice to
look into this 
to better understand it.


Adisak

 



-----Original Message-----
From: Jie Pan [mailto:jie.pan@xxxxxxxx]
Sent: Friday, June 29, 2001 8:19 AM
To: Reflector RPRWG
Subject: RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters



Sanjay and Yiming,

I have no objection to focus on long lived flows for initial simulation,
with the understanding that both types of flows will be used in later
simulations.  However, using the average size packet might lead to
significantly different results.  The price for the simplicity may be just
too high.

From my experience, I don't think that it is too difficult to generate
packet sizes according to the discrete distribution described in your
proposal...

Thanks,

Jie Pan, Ph.D.
Global Access Technology Development, WorldCom
400 International Parkway, Richardson, TX 75081

Enclosure:

"...  Packet Size: Packet sizes are variable on Internet. By packets, 60%
packet are 64bytes, 20% are around 500bytes, and another 20% are 1536 bytes
[1]. Average packet size is 500 bytes [1].  It is hard to generate multiple
distributions in application specified simulations. Thus, we should use the
average size packet for the sake of simplicity...."

-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Khaled Amer
Sent: Friday, June 29, 2001 12:13 AM
To: Reflector RPRWG
Subject: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters

All,

Sanjay Agrawal fulfilled his promise to put together his ideas regarding the
TCP simulation parameters.
We were discussing also if he can help out with scenarios for UDP.
I didn't want to hold on to his document longer (to include UDP also) to
allow for people to get to review it and provide comments on the reflector
(as needed) before the meeting in Portland. We'll include time for
discussions on this in the schedule.

Thanks.

Khaled Amer
President, AmerNet Inc.
Architecture Analysis and Performance Modeling Specialists
Address:     13711 Solitaire Way, Irvine, CA 92620
Phone:        (949)552-1114                      Fax:     (949)552-1116
e-mail:         amer@xxxxxxxxxxx
Web:           www.performancemodeling.com