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

[<[e-mail]>]

interesting discussion. 
will think more about Ken's suggestion (charter is open about transport protocol, but Milestones are only listed for TCP)
 
John, you made a comment that you see the transport of congestion information from destination to sender as being not the main thing or out of scope. what were you thinking the main transport work item should be? (i'm guessing it's a congestion control algorithm - which i think is out of scope)
 
Bob, you were mentioning other things that Conex-TCP would have to do, like capability negotiation. I wonder if we can avoid this in the initial round of work - ie we assume that the ends are conex-enabled, and perhaps also the case when the destination is legacy TCP (the sender is conex-enabled). so the scenario where the destination is ECN-enabled (but not conex-enabled) would be left until later. 
 
Bob, you talk about the dropper below. The draft charter would see this as part of a Use Case for conex. Use Cases wouldn't be subject to protocol work in the initial charter (the WG would encourage experiments on Use cases and report their results in some fashion). shout if you dont think this is viable.
 
thanks
phil

________________________________

From: [e-mail] on behalf of Bob Briscoe
Sent: Fri 13/11/2009 16:29
To: John Leslie
Cc: [e-mail]
Subject: Re: [re-ECN] Other transports than TCP in charter



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

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