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




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