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

[Sally Floyd <[e-mail]>]

Gorry -

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

As always, many thanks for the feedback!

> 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).

I didn't add this, because it seemed to me that it belonged to a 
different
document.

> 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.

I added some of this in pointers to other documents, e.g., RFC 2914, and
the TMRG documents.

...
> 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.

Thanks.  Done.

> ----
> 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"?

Done.

> ---
> Page 3: Section 3:
>     "As noted above, authors are expected to do a well-rounded
>      evaluations"
>                ^
> - Omit "s"?

Done.

> ----
> 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.

Yep, done.

> ----
> 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.

All done.

> ----
> 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.

I didn't add all this, but I did add a discussion of RFC 4782 
(Quick-Start),
as an example.

> ----
> 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?

I left it, but added another sentence for clarity.

> ----
> 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:-)

Yep.  Added.

> ----
> References
> - I'm sure you've noted QS is now an RFC:-)
> - An informative reference to SCTP and DCCP may be useful.

Yep, done.

Again, many many thanks.

- Sally
http://www.icir.org/floyd/