Re: [re-ECN] Other transports than TCP in charter

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> wrote:
> At 12:00 13/11/2009, John Leslie wrote:
>>
>> IMHO, how _any_ transport determines what fraction of IP packets
>> "expect" congestion is pretty much out-of-scope for CONEX. Clearly
>> TCP congestion-control algorithms will differ in this, and I believe
>> we're agnostic about which way is right.
> 
> It's definitely not this simple.
> 
> I don't want to start a discussion on this detail 
> now, but I've raised the issue of anti-cheating 
> below to explain an important potential constraint
> on good design of ConEx transport extensions.
> 
> If I can be allowed to talk in terms of re-ECN, I 
> found that if the system allows a flow to 
> under-declare expected congestion relative to 
> actual by even one packet without punishing it, 
> then a sender can cheat a lot (by keep cheating a 
> little then changing to a 'white-washed' flow ID 
> when it knows it will be detected).

   "The system" is not a helpful construct here...

   I'm not even sure "under-declare expected congestion" is...

   And "punishing it" needs explanation.

   I'm left to guess that you mean an ISP that distinguished
individual "customers" "must" punish a new flow that doesn't
start with a "congestion expected" mark. I don't think I agree,
but I do recognize a risk if _every_ new flow is allowed to
do so.

> If the introduction of ECN reduces drop to nearly 
> nothing, it would be a shame for ConEx 
> anti-cheating mechanisms to introduce a low but 
> persistent level of drop due to false negatives.

   If we really keep packet drop below one per thousand, we're
doing well, IMHO. Eventually, of course, we can hope for one
per million, but that's a long ways off...

> If anti-cheating mechanisms are to introduce as 
> little drop as possible for an honest ConEx 
> source, the source has to expose enough expected 
> congestion to cover likely congestion within one 
> round trip.

   Agreed.

> I call this the principle of "Source 
> Responsibility for Delay Allowance". That's 
> fairly easy to do if the source is willing to be 
> conservative, but it's hard if the source wants 
> to avoid 'wasting' excessive amounts of exposed 
> congestion that might not be needed.

   It's _arbitrarily_hard_ if policing isn't pretty close
to the source. I think it's safe to bet that some ISPs will
police loosely and others "ultra-strictly". YMMV...

> It therefore has to introduce just enough credit 
> to be safe. It only has to build up credit once 
> at the start of the flow, but for lots of short 
> flows to different destinations, that can be a 
> burden if the source is unnecessarily conservative.

   AFAICT, your intent is that non-ECN packets will get
dropped "first" by any policer. That would make the issue
whether to ECN-mark begininng packets of each "flow", in
order to not exhaust your allocation. That's a balancing
act which applications may or may not have enough information
to do reasonably...

> Now, we certainly don't have to prescribe how 
> this must be done, but we do have to show that 
> there is at least one way of doing it.

   I think we need to convince ourselves of that: I'm not
sure it's our job (yet) to convince others.

>> Almost as clearly, we'd be fools to _only_ worry about TCP, because
>> the vast majority of TCP connections will depend upon UDP for the DNS
>> lookup; and any "policing" will take into account UDP packets.
> 
> I strongly believe that the source should be 
> allowed to send any packet as non-ConEx. Of 
> course, the ISP is likely to rate-limit non-ConEx 
> traffic, but this should allow the old Internet 
> model and new ConEx-models to coexist. Then DNS 
> packets can be sent non-ConEx. Ditto for any 
> transports that haven't been ConEx'd yet.
> Some transports may never 'do' ConEx.

   Indeed... but DNS UDP clearly stands to lose by not
doing it.

> ===================================================================
> 
> [...] the dropper algorithm [...] must meet the criteria below:
> 
> o Minimal False Hits: It SHOULD introduce minimal false hits for honest 
> flows;

   OK.

> o Minimal False Misses: It SHOULD quickly detect 
> and sanction dishonest flows, preferably at the
> first dishonest packet;

   For some values of "dishonest", I suppose I agree; but
I'm not that hot on judging "honesty".

   (Thus, I doubt I'm willing to judge "dishonesty" on the
basis of one packet.)

> o Transport Oblivious: It MUST NOT be designed 
> around one particular rate response, such as 
> TCP?s, or one particular resource sharing regime 
> such as TCP-friendliness, given an important goal 
> is to give ingress networks the freedom to allow 
> different rate responses and different resource 
> sharing regimes ? unilaterally without coordinating
> with downstream networks;

   In particular, the policer really can't _know_ the RTT...

   Also, as we get farther from the end-user sender, aggregation
simplifies the policer task.

   We _do_ need a good definition of the meaning of a
"congestion-expected" packet mark -- and I don't think we've
reached agreement on that yet.

> o Sufficient Sanction: It MUST introduce 
> sufficient loss in goodput so that sources cannot 
> play off losses at the egress dropper against 
> higher allowed throughput at the ingress policer;

   I can't attach a crisp meaning to that without a better
definition of "egress dropper" and "ingress policer".

> o Manage Memory Exhaustion: It SHOULD be able to 
> counter state exhaustion attacks. For instance, 
> if the dropper uses flow-state, it should not be 
> possible for sources to exhaust its memory 
> capacity by gratuitously sending numerous 
> packets, each with a different flow ID

   I can't imagine why we'd encourage a policer or dropper
to keep state on flows.

> o Identifier Accountability: It MUST NOT be 
> vulnerable to ?identity whitewashing?, where a 
> transport can label a flow with a new ID more 
> cheaply than paying the cost of continuing to
> use its current ID;

   I think I'm missing where "flow ID" fits into re-ECN.

>> Is it clear that we need to define _any_ "protocol extensions"
>> for TCP?
> 
> Yes. It's very likely that there will be a number 
> of aspects of ConEx-TCP needed for 
> interoperability, quite aside from its congestion 
> exposure strategy. I even think it's important to 
> give clear guidelines for protocol designers on 
> best practice for the exposure strategy, 
> including an actual recommended approach to follow.

   I await details of these "protocol extensions"...

> The re-ecn-tcp draft gives a feel for the 
> different things a TCP would have to do if re-ECN 
> were to be the protocol of choice. We may work 
> out ways of not doing some of this, but you will 
> see there's a fair bit of capability negotiation 
> stuff. And we should ensure there's management
> stuff too.

   Alas, I don't volunteer to read every iteration of
"the re-ecn-tcp draft"...

>> I would hope that RTP could work from merely a definition of how
>> to signal "congestion expected".
> 
> Again, there will probably be interoperability 
> aspects to the protocol, not just the exposure 
> algo at the source. This is to do with whether 
> packets that the source marks to expose expected 
> congestion have to also be ECN-capable (due to 
> shortage of codepoints not leaving enough space 
> to have non-ECN-capable ones as well).

   That seems to answer its own question -- for IPv4 anyway.

--
John Leslie <[e-mail]>