Re: [re-ECN] Charter Question

[John Leslie <[e-mail]>]

David Harrington <[e-mail]> wrote:
> 
> One of the concerns that has been raised is whether domains will be
> willing to share this potentially-sensitive information across
> domains.

   I could pose that question to NH ISPs -- but I suspect the response
would be, "Huh? Whazzat?"

   And I'm not sure I could answer!

   The only thing which seems to fit "potentially-sensitive" is what
congestion there is within your domain. And that would be downright
hard to extract from ConEx markings.

   ConEx markings will go with end-to-end flows. A sender will signal
expected congestion, which may or may not be experienced _anywhere_
along the path. There is a hope that ConEx-marked packets will get
ECN markings instead of being dropped, but that's wishful thinking.

   The ECN markings are where information on congestion lives. And
they indicate congestion _anywhere_ on the path so far. You'd have
to sample flows _before_ they enter a domain and _after_ they leave
to get useful "potentially-sensitive" information about congestion.
There are easier and better ways to derive this information.

   For the ConEx marking itself, the information it carries is about
the sender's expectations. The sender might or might not be in your
domain. If it is, you're welcome to scrub any ConEx marks you don't
like. If it's not, what could possibly be "potentially-sensitive"?

> As a vendor, if I supported a re-ecn,

   Wait a second... what might it mean for a "vendor" to "support"
ConEx?

   The first example is an Operating-System vendor. An OS "supports"
ConEx by putting ConEx markings in IP packets it originates --
otherwise the markings can't get there. It is likely that an OS
vendor would automate what ConEx markings based upon congestion
feedback, within its TCP/IP stack.

   The next example is a middlebox vendor. A middlebox might perform
accounting and/or policing for congestion-expected packet volume.

   IMHO, a backbone-router vendor is _not_ an example. Backbone
routers either do or don't support ECN marking in place of dropping
packets. (A end-customer-router might well perform middlebox tasks,
but I prefer to group it with other middleboxes.)

> I would think I would be motivated to allow the operator to decide
> not to share the info, and I would implement a scrubbing mechanism
> (allow border routers to clear the conex markers in traffic exiting
> a domain).

   Scrubbing ConEx congestion-expected markings seems pointless.
They show _nothing_ about your domain unless somebody can be bothered
to identify which packets originated in your domain; and even then
they show the varying expectations of your customers, not what
happened to the packets while you were forwarding them.

   Scrubbing ECN markings _might_ hide something about your fabric,
but it seems really far-fetched to hide what little they show. If
you did scrub them, that wouldn't prevent ConEx from working: it
would merely slow down the reaction to congestion, inevitably
leading to _more_ congestion somewhere.

   (Clearly, an OS vendor or a middlebox vendor might have good
reason to program an option to disable, or even scrub, ConEx markings.
But it doesn't look as if that's your concern.)

> The IETF cannot dictate that deployments reveal this sensitive
> information, any more than it could dictate that SNMP traps must be
> allowed cross-domain.

   The IETF cannot "dictate" much of anything; but please explain
what "sensitive information" you're concerned about if I've missed
your point.

> So maybe we should approach the problem in two steps:
> 
> 1) determining how well existing standard protocols can be used to
>    effectively address the intra-domain congestion problem,

   I don't believe ConEx is intended to "address" any "intra-domain
congestion problem". It would produce a tool which might later be
useful for such problems; but that is not the problem we set out
to solve.

>    and whether specific enhancements, such as congestion-specific
>    ipfix IEs, are needed. This would give us forward progress on
>    standard approaches for monitoring congestion that might be
>    deployed fairly quickly.

   This may well be work worth doing, but it is not ConEx-related
work. ConEx does not intend to "monitor" congestion. It means to
encode total-path expected-congestion, allowing ISPs to discern
which end-users are demanding services on congested paths.

> 2) how to share information across domains. Since the major
>    question here seems to be whether domains would be motivated
>    to share, maybe an effort akin to INCH is needed for this piece.

   Again, that may be work worth doing. It doesn't fit well with
the intended ConEx work, though; and I suspect we wouldn't be
happy if you tried to squeeze it into our charter.

> After we solve the first problem, we can try to extend it to
> cross-domain, or use a different mechanism for cross-domain
> reporting.

   I think you need an entirely different BoF for this problem
you are describing.

--
John Leslie <[e-mail]>