Subject: [apps-discuss] AppsDir review of draft-ietf-conex-concepts-uses-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 13:56:27 +0100

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).Please 
resolve these comments along with any other Last Call comments you may 
receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-ietf-conex-concepts-uses-04.txt

Title: ConEx Concepts and Use Cases

Reviewer: Alexey Melnikov

Review Date: 10 April 2012

IETF Last Call Date: 12 April 2012

IESG Telechat Date: 12 April 2012

Review Summary:  This draft is ready for publication as an Informational 
RFC.

Document Summary:  This document provides the entry point to the set of 
documentation about the Congestion Exposure (ConEx) protocol. It 
explains the motivation for including a ConEx marking at the IP layer: 
to expose information about congestion to network nodes. Although such 
information may have a number of uses, this document focuses on how the 
information communicated by the ConEx marking can serve as the basis for 
significantly more efficient and effective traffic management than what 
exists on the Internet today.

I've already reviewed this document as a Gen-Art reviewer and have no 
new issues to report. I don't think the document has Apps Area issues.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Apr 2012 12:50:25 -0700

I read draft-ietf-conex-concepts-uses-04.  Here are some quick comments.

As well-known application protocols such as FTP, SMTP and HTTP run 
over TCP, ConEx deployments shouldn't have a negative impact on them.

As a stylistic nit, the definitions in Section 2.4 could have been 
before Section 2.2 and 2.3.

   "Network operators (or providers):  Operator of a residential,
       commercial, enterprise, campus or other network.

    User:  The contractual entity that represents an individual,
       household, business, or institution that uses the service of a
       network operator.  There is no implication that the contract has
       to be commercial; for instance, the users of a university or
       enterprise network service could be students or employees who do
       not pay for access but may be required to comply with some form of
       contract or acceptable use policy.  There is also no implication
       that every user is an end user.  Where two networks form a
       customer-provider relationship, the term user applies to the
       customer network."

The above from Section 2.4 defines providers and users.  According to 
the definition of User, a provider can also be a User.  It would have 
been easier not to get into a definition of provider (network 
operator) and user to keep the picture simple.

In Section 3.3:

   "They may even penalize users of applications that employ
    scavenger services for the large amount of volume they send, rather
    than rewarding them for carefully avoiding congestion while sending
    it."

What are "scavenger services"?

   "While the volume-based approach described in Comcast's Protocol-
    Agnostic Congestion Management System [RFC6057] aims to overcome the
    over/under-constraining problem by only measuring volume and
    triggering traffic management action during periods of high
    utilization, it still does not provide incentives to use scavenger
    transports because congestion-causing volume cannot be distinguished
    from volume overall."

What are "scavenger transports"?

   "These approaches suffer from being at odds with IPSec and some
    application-layer encryption, and they may raise additional
    policy concerns."

If I am not mistaken, that should be "IPsec".

In Section 5.5:

   "Not-ConEx packets bring no such information.  Therefore the network
    will tend to rate-limit not-ConEx packets conservatively in order
    to manage the unknown risk of congestion."

Another way to look at this is:

   Therefore the network will tend to rate-limit non-TCP packets conservatively
   in order to manage the unknown risk of congestion.

Editorial nit: "On the host side, we have already shown (Figure Figure 1)"

Regards,
S. Moonesamy