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

[Bob Briscoe <[e-mail]>]

John,

I agree with the conclusions on charter this 
thread seems to have come to. I just wanted to go 
back to pick up things John said...

At 12:00 13/11/2009, John Leslie wrote:
>[e-mail] <[e-mail]> wrote:
> >
> > Any WG that is formed as a result of this BoF will have a very
> > difficult balancing act to do - clearly eventually we want every
> > transport that is commonly used on the network to integrate ConEx.
>
>    Hopefully, we can agree on that much...
>
> > However each transport will add significantly to the time it takes
> > the WG to produce usable output.
>
>    Well, that depends...
>
>    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).

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 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. 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 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.

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.


>    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.


>    We _do_ need to specify _how_ any transport _signals_ congestion
>expected, which I expect will be at the IP layer.
>
> > My view is that we therefore need to approach transports in a
> > sensible order. One possible compromise might be as follows:
> >
> > ? Define a clear set of minimal transport requirements since these
> >   will allow people to start working out how to integrate this
> >   into their transport of choice.
>
>    Such as... ?

Let's not start writing text yet, until we have a 
charter and until we have a candidate protocol accepted as WG business.

But transport requirements will probably be the 
complement of constraints on design of any 
anti-cheating device (dropper). Using re-ECN as 
an example, 
draft-briscoe-tsvwg-re-ecn-tcp-motivation S.4.3. 
lists those below (actually slightly modified 
text that was intended for the next revision).

I've managed to design a strategy for TCP that 
leads to hardly any false positives against a 
dropper conforming to these rules (but through 
corridor discussions here in Japan, Mirja pointed 
out more work is needed). Whatever, it's not easy at all.

===================================================================

[...] the dropper algorithm [...] must meet the criteria below:

o Minimal False Hits: It SHOULD introduce minimal false hits for honest flows;

o Minimal False Misses: It SHOULD quickly detect 
and sanction dishonest flows, preferably at the first dishonest 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;

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;

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

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;

> > ? Fully define the protocol extensions for TCP since this is still
> >   the transport of choice for both the majority of bits and the
> >   majority of flows.
>
>    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.

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.


> > ? Then follow Ingemar's suggestion of adding this to RTP (and
> >   related real-time protocols) since these are becoming ever more
> >   significant as real-time media really starts to take off.
>
>    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).


> > ? Then move onto transports such as SCTP and DCCP once we have
> >   evidence of how the TCP implementation is going.
>
>    I can agree that worrying about "protocol extensions" for transports
>other than TCP and UDP shouldn't be "critical path" to getting TCP
>experiments going.

Cool


Bob


>--
>John Leslie <[e-mail]>
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design