Subject: Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-03.txt

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Nov 2011 21:32:45 +0000

Hi John,

Thanks for your comments. I have some responses inline and I've also added the issues you raise to trac (http://trac.tools.ietf.org/wg/conex/trac/report/1).

On Oct 25, 2011, at 4:25 PM, John Leslie wrote:
>> 
> I have several issues which deserve discussion here.
> 
>   concepts-uses still ventures farther into mechanism than I'd wish:
> 
>   - "the ConEx Field" implies mechanism; I suggest "ConEx marking".

Fine with me.

>   - "Network provider (or operator)" doesn't work as a definition:
>     I suggest defining "Network Operator (or Provider), and fixing
>     the various places which use these words ambiguously.

Fine with me.

> 
>   - The "User" definiton hides something a bit counter-intuitive:
>     that the sending user is known in some places, the receiving
>     user in others, and neither is knowable in the middle. While
>     the definiton here is probably as good as we can get, I'm
>     afraid our readers will be confused.

If there are specific instances of "user" that you think might cause confusion, that would be helpful to know. At least in 3.1 (where it probably matters the most), I think it's fairly clear that the network operator will be drawing conclusions about its own users.

> 
>   - "Congestion Policer" is not defined.

The editors had some discussion about whether this is necessary. If most people think it is, we can add it. A suggestion:

Congestion policer (discussed in 3.1): A logical entity that allows a network operator to monitor each user's congestion-volume and enforce congestion-volume limits.

> 
>   - In Section 3.1, the general-case description of policer (the
>     second paragraph) is describing mechanism better left to a
>     different I-D. OTOH, the fourth and fifth paragraph are an
>     example appropriate for this document (especially since it
>     is the case found in our Charter).

I think it's hard to understand the last paragraph without explaining at a high level how a congestion policer might work. Perhaps we can split the difference by making it more clear that the token bucket description is an example (i.e., "one way to implement a congestion policer" instead of "a congestion policer can be implemented").

Thanks,
Alissa

> 
> --
> John Leslie <[email-masked]>
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 1 Nov 2011 22:51:23 +0000

Hi John,

Couple of comments inline --

On Oct 25, 2011, at 4:42 PM, John Leslie wrote:
>> 
>> http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt
> 
>   This I-D defines "Congestion" and "Congestion Volume". While the
> definitions are mostly right IMHO, there are inevitable problems as
> the terms are used later in the document.
> 
>   Inevitably we must use "level of congestion" in a few places.
> Which does it refer to? I'd argue that it's not always one or the
> other. In some places it's clearly bytes-on-the-wire dropped; in
> others it's clearly percentage of packets dropped. I'd recommend
> that we clarify that "level of congestion" may have different
> meanings in different places along the path.

I think there's a simpler solution -- delete "level of" in all the places it appears. In the definition of congestion we say it _usually_ is expressed as a percentage, therefore if we just use the term "congestion" without "level of" I think it leaves open the possibility of expressing it either way in all of those cases where "level of" is currently used.

> 
>   Also, we use "quotas" in a few places. The implementation of
> quotas, IMHO, is unlikely to be the same everywhere. Some quotas
> will count packets regardless of size; others may count bytes,
> but are likely to count bytes differently: I doubt we can expect
> the count to be bytes-on-the-wire consistently.

This may be true but I don't think this document is the place to discuss it.

> 
>   In IPv6, bytes-on-the-wire can differ considerably from bytes
> of payload, and I would expect some users to argue that they
> shouldn't be charged for anything beyond payload. As an ISP, I
> know "winning" such arguments is Pyrrhic.

Same comment as above.

Thanks,
Alissa

> 
>   (This much should suffice for starting the discussion. ;^)
> 
> --
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
>