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