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

[S Moonesamy <[e-mail]>]

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