RE: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters
In addition to TCP or UDP, I think the end-to-end application behavior is
important
-- thus a circuit emulated application will have different traffic params
and reaction
to loss compared to File transfer(NFS, FTP, etc.) or a streaming backup
application
running on TCP. My suggestion is to use traffic profile for typical
applications, as
inputs to the model for comparison.
-Kumar
-----Original Message-----
From: Khaled Amer [mailto:amer@xxxxxxxxxxx]
Sent: Monday, July 02, 2001 1:24 AM
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
>