Re: [RPRWG] Fw: RPR Perf: Thoughts on TCP parameters
I would like to second Frank's observations and add the following comments:
- It may be useful to add TCP connections with different round trip delays to account for diversity of
source/destination pairs. Latter do not begin and end on clients to the stations. It may also be useful to
specify a model of what's outside of RPR ring and how it impacts the connections. Note that I am not
suggesting that RPR can do anything about what's outside its domain. However it would help us understand how
best to map other service differentiation frameworks to RPR class of service.
- I also like to know how many TCP connections folks think can simulate in their models. Specially short
lived connections tend to be the mice, but there is a lot of them. I understand that we are focusing on the
elephants to begin with.
Regards, Siamack
"Kastenholz, Frank" wrote:
> 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
begin:vcard
n:Ayandeh;Siamack
tel;fax:781 271 9988
tel;work:781 276 4192
x-mozilla-html:FALSE
url:www.onexco.com
org:Onex Communications Corporation
adr:;;34 Crosby Drive;Bedford;MA;01730;USA
version:2.1
email;internet:sayandeh@xxxxxxxxxx
title:Senior Consulting Engineer
end:vcard