So is ToU also going to have slow start in it??? and all other full
blown TCP'isms ??? why not just define a protocol that adds
retransmit of individual udp packets and ack mechanism and
sequencing rather go layer a whole stack on top of another stack...
Just add the features that are needed... Since you are proposing a
new protocol anyway let us keep it as minimalistic as possible
Which features would you propose to remove?
Unless you are content with stop-and-wait congestion control (and
roughly modem data rates), you need either AIMD or rate-based control.
As I mentioned earlier, rate-based control is not all that suitable
for mid-sized transfers, due to the estimation delay, and isn't any
simpler than AIMD.
Currently, ToU has
- "modern" congestion control
- flow control (window-based)
- reliability
- extensions (so that, for example, SACK can be made to work if needed)
It omits
- ports
- checksum
- urgent mode/PSH bit
I suspect we could remove RST handling, but that's a relatively minor
aspect.
The advantage of using TCP algorithms is that it ToU behavior is
relatively easy to validate (you can run "real" TCP and ToU in
parallel on the same simulator, for example, and immediately see if
you screwed up) and lots and lots of implementors understand it, as
it's covered in every intro networking textbook. I don't think winging
our own algorithm is a good idea, given the amount of existing "prior
art".
As we learned from SCTP, getting the first implementations of a
conceptually new protocol right is non-trivial. The goal would be to
have somebody build a library, so that most application writers don't
have to worry about getting RTO estimation right, dealing with window
adjustments and all the other details that any non-toy transport
protocol needs. Thus, generality is an advantage, as it encourages
library building.
We're generally not good at predicting where and how protocols will be
used, and most long-term successful protocols are those that provided
modular functionality, not extremely narrowly-tailored protocols.
Henning
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
