[Tsvwg] draft-floyd-tsvwg-cc-alt - Call for WG adoption

[Gorry Fairhurst <[e-mail]>]

I think this is useful, and support its adoption as a working group item
intended for BCP publication.

It could be worth writing about is the different aspects of this problem
space. These are different, and raise issues with different communities. For
instance we have views:

* traditionally flows need to be controlled, but applications have spanned
multiple flows to "modify" the intended behaviour, for good and bad reasons.
* some think that end-host traffic need need to be controlled (rather than
transport flows) - need to accommodate multi-homed hosts, multi-user systems
...
* it's also possible to control traffic through edge routers, some are more
concerned about mis-behaving "local" routers and end hosts to protect the
service of other local users (e.g. ECN NONCE).


It could also be useful to outline background:

* End-hosts need to implement congestion-control to behave as responsible
systems in the Internet, routers can assist in this role.
* Some congestion-control algorithms introduce incentives for end hosts to
cheat (not respond appropriately) to attempt to gain a larger share of the
capacity along the Internet Path.
* Not all paths are equal (in terms of loss, capacity, delay, delay
variation, etc), and this can result in very different shares, even though
intuitively this may seem unfair or be unexpected by a user.
* The security implications of congestion control algorithms also need to be
considered, and methods found to mitigate the effects of third-party
attacks.
* This problem space is orthogonal to RSVP, DS, etc.

Best wishes,

Gorry

Specific comments follow:

----
Page 3:
    "The second class is algorithms
     that, while promising, are not deemed safe enough for deployment on
     the Internet, but are being specified to facilitate investigations
     via simulation and testbeds."

- "Not deemed safe enough"
- This sounds like it could be right, but I'd prefer a clearer distinction
between the "deemed safe" case, where there is not currently sufficient
understanding for IETF to gain consensus that this is safe.
----
Page 3:

    "describing environments where the protocol
     is not recommended for deployment even though it may not be unsafe
     for use"

- The double negative makes this harder to read:  "may not be unsafe" does
this mean "not necessarily safe"? "not necessarily unsafe"?
---
Page 3: Section 3:
    "As noted above, authors are expected to do a well-rounded
     evaluations"
               ^
- Omit "s"?
----
Page 3: Section 3:
   " should not be used as a
     check-list."

- definitive checklist, i.e., it's fine to check these things, but you may
need to do more.
----
Page 4: Point (3)
        "An assessment of proposed algorithms in difficult environments
         such as paths containing wireless links and paths with
         reverse-path congestion."

- This is not a sentence, perhaps replace the start by: "The proposed
algorithms should be assessed in..."
- I'd prefer to be concrete on the sort of path characteristics to examine,
there is nothing fundamentally dangerous about using "radio" links:-)
- so I suspect readers should look at issues such as "corruption loss,
higher delay, variable delay, varying capacity, and the implications of BoD"
- in short, the sort of things mentioned in RFC3819.
----
Page 5: Point (7)
- In point (7) I found it harder to understand what was envisaged to be
assessed. I'd have preferred to have some clearer guidance on the sort of
things to consider.

* The effect of control packet loss /delay/ordering (in hosts, routers).
* The effect of loss of state (e.g. due to a protocol restart at a router,
or end host).
* Returning control information that does not reflect the actual end host
state, from an end host or router participating in the protocol.
* The transmission of packets designed to trigger an incorrect response by
an end host or router participating in the protocol.

- IMHO, the effects could more usefully be split between on-path (above) and
the other off-path attacks.

* Transmission of packets by third parties (that do not have access to the
network packets belonging to the flow) with the object of changing the
protocol state.
* Denial of service attacks against hosts/routers designed to consume
resources and reduce resources available for this and/or other protocols.
----
Page 5: Point (9)
  "is to be carried out."

- I'm not a fan of the words "carried out" could  "deployed" or something
else be used?
----
Section 5

- Not only should " Alternate congestion control schemes should be mindful
of such pitfalls, as well." - they MUST of course examine potential security
issues that may arise from their use:-)
----
References
- I'm sure you've noted QS is now an RFC:-)
- An informative reference to SCTP and DCCP may be useful.