[e2e] Re: [dccp] Which options are required?

[Michael Welzl]

[this also goes to end2end-interest, where we should probably
 take this discussion]


Hi all,


> TCP-friendly is _not_ defined in terms of Padhye's model. TCP-friendly
> means, basically, "achieves a fair share of bandwidth relative to
> reasonable TCP flows over the same path". The definition still allows for
> improvements to TCP. It's even acceptable to do better than TCP, where TCP
> currently behaves badly, or stupidly -- in the presence of reordering, for
> example.

It allows for improvements to TCP, yes. It is acceptable to do
better than TCP, where TCP currently behaves badly, or stupidly,
no - not by definition. To quote Sally's mail:

>RFC 2914 on "Congestion Control Principles" describes "TCP-compatible"
>as follows:
>
>  Again borrowing from RFC 2309, we use the term "TCP-compatible" for a
>  flow that behaves under congestion like a flow produced by a
>  conformant TCP.

(let us asssume that TCP-compatible is the same as TCP-friendly ...
I think we all agree on that)

>From RFC 2309:

> We introduce the term "TCP-compatible" for a flow that behaves under
> congestion like a flow produced by a conformant TCP.  A TCP-
> compatible flow is responsive to congestion notification, and in
> steady-state it uses no more bandwidth than a conformant TCP running
> under comparable conditions (drop rate, RTT, MTU, etc.)

So this definition changed a little from RFC 2309 to 2914 ("under
congestion"), but this could probably be seen as nitpicking.

The problem is that as soon as you "do better than TCP where
TCP behaves badly, or stupidly" (I assume that this means
to achieve greater throughput, i.e. send at a higher rate):

- you DO use more bandwidth than a conformant TCP would under
  comparable conditions [RFC 2309].
- you DO NOT behave under congestion like a flow produced by
  a conformant TCP [RFC 2914].

Also, I don't like the RFC 2914 definition: TFRC does NOT
behave under congestion like a flow produced by a conformant
TCP - but it satisfies TCP-friendliness according to RFC 2309.
It really depends on how you interpret "behave like"...

I am not criticizing the very idea of TCP-friendliness here,
just the way it is defined, which has the potential of hindering
innovation. To allow for improvements such as the one above
("do better than TCP, ..") while retaining the stability of
the Internet, it should at least be defined with regard to
the impact a flow has on TCP flows that would share the
same connection. An advantage of such a definition would also
be that the notion of "under comparable conditions" could
be removed; the drop rate, for instance, is not just an
environmental condition but under control of the flow in
question (at least to a certain degree, which in turn depends
on the environment). With the current definition, nobody
would ever feel motivated to work on reducing the drop rate.

Also, while I like the fact that the most recent TCP
standard should be taken into account for TCP-friendliness, it
would be nice to make this explicit in the definition.

TCP-friendliness has been around for quite a while now.
Why don't we get together and write a sensible and precise
definition of it?

Best regards,
Michael