RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters
Khaled,
We did present a few scenarios of UDP and TCP mix at the march meeting. You
might want to see if we can use it as a starting point. If there is enough
interest from the group, we can probably publish the simulation set up (in
OPNET).
The simulation was about whether TCP can interact with RPR flow control
and whether TCP can affect the SLA of UDP and vise versa.
Adisak
-----Original Message-----
From: Khaled Amer [mailto:amer@xxxxxxxxxxx]
Sent: Sunday, July 01, 2001 10:24 PM
To: Kastenholz, Frank; Reflector RPRWG
Subject: Re: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters
Thanks, Frank, for the input.
> UDP should not be an issue here.
One thought comes to my mind here. I guess we will need to at least define a
good unified mix of UDP and TCP traffic so we have well defined scenarios
and a consistent framework for running the simulations.
Any comments?
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
----- Original Message -----
From: "Kastenholz, Frank" <FKastenholz@xxxxxxxxxxxxxxxxxxxxx>
To: "Reflector RPRWG" <stds-802-17@xxxxxxxx>
Sent: Friday, June 29, 2001 5:49 AM
Subject: Re: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters
>
> At 10:13 PM 6/28/01 -0700, Khaled Amer wrote:
> >All,
> >
> >Sanjay Agrawal fulfilled his promise to put together his ideas regarding
the TCP simulation parameters.
>
> I think it's an excellent idea to simulate the interactions
> between TCP and 802.17.
>
> I would inject a word or two of caution, however
> - The TCP community has generally found that having multiple
> controls operating, such as TCP and 802.17, has, in the past,
> resulted in sub-optimal behavior. Generally, one control system
> is seen as the best, having multiples leads to bizarre behavior.
> This bad behavior in the past may have been because the
> interactions were not analyzed ahead of time. If so, perhaps
> the 802.17 work will result in better behavior.
>
> - The Internet as a whole is very large and dynamic. Understanding
> the interactions, and then modelling them, of all the elements
> by which a given flow goes through, and then multiplying that
> by all the different flows (all of which go through different
> sets of elements with different behaviors) may prove to be
> intractable.
>
> - TCP's algorithms are continually evolving. As Sanjay Agrawal's paper
> indicates, there are three variants of TCP (Reno, Tahoe, and Vegas)
> to simulate with. No doubt, there will be more. A design that works
> will with those three may fail miserably with the algorithms that
> someone will invent next year.
>
> - You might want to discuss this work on the end-to-end research group's
> general interest mailing list (subscribe by sending email to
> end2end-interest-request@xxxxxxxxxx). That mailing list is where
> many discussions relating to TCP performance and algorithms
> occur. The Internet/IP folks who really undertand this stuff all
> are on that list. They may have useful insights.
>
>
> >We were discussing also if he can help out with scenarios for UDP.
>
> UDP should not be an issue here. All UDP provides is demultiplexing
> and some error detection. It does not do retransmissions, flow
> control, etc.
>
> You might, though, want to look at RFC2960 -- Stream Control
> Transmission Protocol. It seems to be gaining some "traction"
> as a transport protocol that complements TCP and UDP.
>
> Frank Kastenholz
> Co-Chair
> IETF IP/RPR Working Group
>
>
> Frank Kastenholz
>